1. Visão geral
Nem sempre é possível ou viável reescrever ou reestruturar aplicativos atuais para trabalhar no Kubernetes manualmente. O Migrate for Anthos pode ajudar a modernizar seus aplicativos atuais e executá-los no Kubernetes. Neste codelab, você vai migrar um aplicativo da Web hospedado no Compute Engine para o Kubernetes Engine usando o Migrate for Anthos.
O que você vai aprender
- Como implantar o Migrate for Anthos em um cluster do Kubernetes
- Como criar um contêiner em um conjunto com estado de uma instância do Compute Engine
- Como implantar o contêiner no Kubernetes e configurá-lo com um balanceador de carga
O que é necessário
- Um projeto na nuvem do Google Cloud com o faturamento configurado. Se você não tiver um, terá que criar um.
2. Etapas da configuração
Este codelab pode ser executado totalmente no Google Cloud Platform sem instalação ou configuração local.
Ativar APIs
Antes de começar, ative as APIs necessárias no seu projeto do Google Cloud:
Criar um servidor da Web de instância do Compute
Vamos criar uma instância de computação que será usada para hospedar nosso servidor da Web nginx inicial, além das regras de firewall que vão permitir que você veja a página de destino padrão do servidor da Web. Há algumas maneiras de fazer isso, mas, para facilitar o uso, vamos usar o Cloud Shell.
No Cloud Shell, execute este comando:
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
A primeira metade desse comando cria uma instância do Google Cloud na zona us-central1-a, enquanto a segunda metade cria uma regra de firewall chamada "default-allow-http" que permite o tráfego http na nossa rede.
Quando a instância for criada, ela vai mostrar uma tabela com os detalhes dela. Anote o IP externo , que será necessário para verificar se o servidor da Web está em execução mais tarde.
Depois que a instância estiver em execução, podemos fazer SSH nela no Cloud Shell para instalar o nginx e iniciar o servidor da Web:
gcloud compute ssh --zone us-central1-a webserver
Depois de fazer login na instância de computação, instale o nginx:
sudo apt install nginx
Faça logout da sessão SSH com o comando logout.
Vamos verificar se o servidor da Web está em execução inserindo o IP externo da instância no navegador. Você vai ver a tela de boas-vindas padrão do nginx:
Esse servidor da Web vai servir como o aplicativo da Web legado que vamos migrar para o Kubernetes usando o Migrate for Anthos.
3. Cluster do Kubernetes com o Migrate for Anthos
Em seguida, vamos criar um cluster do GKE, que é onde vamos migrar o servidor da Web do Compute Engine. No console do Cloud, execute o seguinte:
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
Aguarde alguns minutos para que esse comando seja concluído. Depois que o cluster for criado, você vai receber uma saída com os detalhes dele:
Em seguida, acesse o GCP Marketplace para implantar o Migrate for Anthos:
Na página do Marketplace do Migrate for Anthos, clique em "Configurar" e, se solicitado, selecione seu projeto na lista. A página seguinte vai apresentar um formulário com alguns valores padrão inseridos. Verifique se o cluster selecionado é o que acabamos de criar e clique em Implantar:
O Migrate for Anthos agora será implantado no cluster do Kubernetes. Quando a implantação terminar, você vai ver o status "OK" na página Aplicativos do Kubernetes Engine:
4. Da instância de computação ao conjunto com estado
Temos um cluster do Kubernetes executando o Migrate for Anthos. Agora podemos iniciar o processo de migração. Para implantar a instância de computação em um cluster do Kubernetes, vamos desligar a instância do Compute Engine para que possamos fazer snapshots dos discos. Antes de continuar, anote o ID da instância, que será necessário mais tarde:
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Vamos desligar a instância de computação:
gcloud compute instances stop webserver --zone us-central1-a
Agora que a instância está interrompida, podemos fazer snapshots dos discos com segurança executando o script a seguir. Insira o ID do projeto e o ID da instância:
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
Com essas flags, clone_vm_disks.py vai:
- Verificar se a instância do GCE está desativada
- Criar um snapshot de cada um dos discos da instância
- Criar um novo disco de cada snapshot
- Excluir os snapshots criados
- Gerar um arquivo YAML no diretório de trabalho atual para implantar um conjunto com estado que vai hospedar o servidor da Web
O arquivo YAML gerado vai provisionar um conjunto com estado no cluster do Kubernetes, além das declarações de volume persistente necessárias para montar os discos copiados no contêiner do servidor da Web. Podemos aplicar essas mudanças com kubectl:
kubectl apply -f containerized-webserver.yaml
Verifique o status do webserver-statefulset na página "Cargas de trabalho":
É normal que o status seja "Pods are pending" por alguns minutos após a execução de kubectl apply. Continue quando o status for "OK".
5. Expor o cluster ao balanceador de carga
Nesse momento, o cluster do Kubernetes deve estar executando o servidor da Web como um conjunto com estado, mas também precisamos expor o contêiner a um balanceador de carga para acessar o servidor da Web por um endereço IP externo. No Cloud Shell, crie um arquivo chamado loadbalancer.yaml com o seguinte conteúdo:
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
Agora, aplique-o com kubectl:
kubectl apply -f loadbalancer.yaml
Podemos usar o kubectl para recuperar o endereço IP externo do serviço webserver-container:
kubectl get services
Se inserirmos o endereço IP externo no navegador, vamos receber a mesma tela de boas-vindas padrão do nginx de antes:
Conseguimos! Nosso servidor da Web do GCE agora está hospedado no Kubernetes. Legal!
6. Stackdriver Monitoring
Métricas
Como um serviço gerenciado do Kubernetes, o Kubernetes Engine é instrumentado automaticamente para registro e monitoramento com o Stackdriver. Vamos conferir algumas das métricas que o Stackdriver captura automaticamente.
Clique no link "Monitoring" no menu de produtos. O primeiro acesso ao seu projeto pode levar alguns minutos enquanto ele configura o espaço de trabalho.
Depois de carregado, passe o cursor sobre "Recursos" no painel esquerdo e selecione "Kubernetes Engine NOVO" no menu.
Cada linha no painel apresentado aqui representa um recurso do Kubernetes. Você pode alternar entre a infraestrutura, as cargas de trabalho ou a visualização de serviços com os links acima do painel.
Na visualização "Cargas de trabalho", expanda "my-gke-cluster" e detalhe para "padrão" > "webserver-statefulset" > "webserver-statefulset-0" > "webserver-statefulset". Clique no contêiner do conjunto com estado do servidor da Web. Aqui, você vai encontrar algumas métricas prontas para uso capturadas pelo Stackdriver, incluindo a utilização de memória e CPU.
Os gráficos mostrados neste painel são aqueles que podemos usar para criar um painel personalizado.
Painéis personalizados
O Stackdriver permite criar painéis personalizados que podem ser usados para organizar gráficos de dados de métricas disponíveis. Vamos criar um painel personalizado para fornecer uma visão geral de algumas das métricas do servidor da Web.
No painel esquerdo, passe o cursor sobre "Painéis" e clique em "Criar painel".
Agora que temos nosso painel vazio, podemos adicionar métricas que queremos monitorar. Vamos dar ao painel sem título um nome útil, como "Meus contêineres do servidor da Web", e clicar em "Adicionar gráfico" no canto superior direito:
Lembra das métricas prontas para uso? Vamos adicionar um gráfico para a utilização da CPU do contêiner. No campo "Título do gráfico", insira "Utilização da CPU". Na caixa "Encontrar tipo de recurso e métrica", digite request_utilization e selecione "Utilização de solicitação de CPU" na lista filtrada. Essa seleção vai preencher os campos "Tipo de recurso" e "Métrica".
Em seguida, vamos filtrar por project_id (se tivermos vários projetos) e container_name. Na caixa "Filtro", digite project_id, selecione-o na lista filtrada e selecione seu projeto no campo "Valor". Também precisamos filtrar por container_name. Na caixa "Filtro", digite container_name, selecione-o na lista filtrada e selecione "webserver-statefulset" no campo "Valor". Clique em "Salvar".
Agora temos um painel com nosso primeiro gráfico.
7. Verificação de tempo de atividade e política de alertas
Com o Stackdriver, podemos configurar alertas para notificar quando qualquer métrica atingir os valores de limite especificados. Por exemplo, podemos fazer com que o Stackdriver nos envie um e-mail quando a utilização da CPU da última etapa estiver acima de um determinado limite por um período de tempo sustentado, o que pode indicar um problema com nosso app. Para demonstrar como esses alertas são, vamos configurar uma verificação de tempo de atividade e simular uma interrupção.
No painel esquerdo, selecione "Verificações de tempo de atividade" e "Visão geral das verificações de tempo de atividade":
Como a página "Verificações de tempo de atividade" sugere, vamos configurar nossa primeira verificação de tempo de atividade. Clique no botão Adicionar verificação de tempo de atividade no canto superior direito da página.
No formulário seguinte, insira "Tempo de atividade do endpoint" como título e o endereço IP externo do balanceador de carga como nome do host.
Clique em Salvar e você vai receber uma solicitação para criar uma política de alertas complementar:
Clique em Criar política de alertas.
Vamos nomear isso como "Política de tempo de atividade do endpoint". Na seção Configuração, defina "Condição acionada se" como "Qualquer série temporal viola" e clique em Salvar.
Ainda não terminamos. Em seguida, vamos especificar um canal de notificação para que sejamos notificados quando nossa política de alertas for violada. Na lista suspensa "Tipo de canal de notificação", selecione "E-mail" e insira um endereço de e-mail válido.
Clique em Adicionar canal de notificação. Por fim, na parte de baixo do formulário, nomeie a política "Tempo de atividade do app da Web" e clique em "Salvar".
Para ver como um alerta será, no console do Cloud, abra o Cloud Shell novamente. O comando a seguir vai interromper o serviço nginx em execução no pod do servidor da Web:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
Depois de alguns minutos, você vai receber um e-mail alertando sobre a interrupção:
Vamos desfazer isso. De volta ao Cloud Shell, vamos reiniciar o nginx:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Depois de alguns minutos , você vai receber outro e-mail do Stackdriver, desta vez com notícias melhores do que antes:
8. Revisão dos dados
Agora que migramos do GCE para o GKE com o Migrate for Anthos, vamos limpar nosso projeto de todos os recursos que criamos.
Excluir o projeto
Se preferir, exclua todo o projeto. No console do GCP, acesse a página Cloud Resource Manager:
Na lista de projetos, selecione o projeto em que estamos trabalhando e clique em Excluir. Você precisará digitar o ID do projeto. Depois de fazer isso, clique em Desligar.
Se preferir excluir os diferentes componentes um por um, continue para a próxima seção.
Stackdriver
Painel
Na página do painel, clique no ícone de configurações 
na parte de cima da página e selecione Excluir painel.
Política de alertas
Na página Políticas, selecione Excluir no menu "Ações" 
à direita de cada política criada.
Verificação de tempo de atividade
Na página "Verificações de tempo de atividade", selecione Excluir no menu "Ações" à direita de cada verificação criada.
GCE e Kubernetes
Instância do Google Compute Engine
gcloud compute instances delete webserver --zone=us-central1-a
Cluster do Kubernetes (inclui o Migrate for Anthos, o conjunto com estado e o serviço de balanceador de carga)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Discos
Nosso conjunto com estado usou um disco que criamos. Use o seguinte para recuperar o nome:
gcloud compute disks list --filter=webserver
Usando o nome do disco em vez do meu, exclua-o com:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Tudo limpo!
9. Parabéns!
Muito bem! Você migrou o servidor da Web de uma instância do GCE para um cluster do Kubernetes usando o Migrate for Anthos.
O que vimos
- Migramos um servidor da Web do GCE para um cluster do Kubernetes usando o Migrate for Anthos.
- Abrimos nosso servidor da Web de conjunto com estado para o mundo expondo-o por um serviço de balanceador de carga do Kubernetes.
- Ativamos o Stackdriver e criamos um painel personalizado.
- Configuramos uma verificação de tempo de atividade com uma política de alertas para nos informar quando o servidor da Web ficar inativo.