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 os aplicativos atuais e executá-los no Kubernetes. Neste codelab, você vai migrar um web app 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 usando uma instância do Compute Engine
- Como implantar seu 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 uma, crie uma.
2. Etapas da configuração
Este codelab pode ser executado completamente 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 na nuvem 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, junto com as regras de firewall que nos permitirão ver 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 vai criar uma instância do Google Cloud na zona us-central1-a, enquanto a segunda metade vai criar uma regra de firewall chamada "default-allow-http" que vai permitir o tráfego http na nossa rede.
Quando a instância for criada, uma tabela com os detalhes dela vai aparecer. Anote o IP externo. Vamos precisar dele para verificar se o servidor da Web está em execução mais tarde.
Depois que a instância estiver funcionando, podemos usar o SSH para acessar a instância do Cloud Shell, 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
Saia da sessão ssh com o comando logout
Para verificar se o servidor da Web está em execução, insira o IP externo da instância no navegador. A tela de boas-vindas padrão do nginx vai aparecer:
Esse servidor da Web vai servir como o app 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 o comando seja concluído. Depois que o cluster for criado, você vai receber uma saída com os detalhes dele:
Em seguida, navegue até 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 está implantado no nosso cluster do Kubernetes. Quando a implantação terminar, o status "OK" vai aparecer na página de 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 nossa instância de computação em um cluster do Kubernetes, vamos desligar a instância do Compute Engine para que possamos criar 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á parada, podemos criar snapshots dos discos com segurança executando o seguinte script. Insira seu ID do projeto e seu 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, o clone_vm_disks.py vai:
- Verificar se a instância do GCE está desativada
- Crie um snapshot de cada disco da instância
- Crie um novo disco com base em cada snapshot
- Excluir os snapshots criados
- Gere um arquivo YAML no diretório de trabalho atual para implantar um conjunto stateful que vai hospedar seu servidor da Web.
O arquivo YAML gerado vai provisionar um conjunto stateful no cluster do Kubernetes, além das declarações de volume permanente 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 mostre "Pods pendentes" 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
Neste ponto, nosso 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 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 digitarmos 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 geração de registros e monitoramento com o Stackdriver. Vamos conferir algumas das métricas que o Stackdriver captura automaticamente.
Clique no link do Monitoring no menu de produtos. O primeiro acesso ao projeto pode levar alguns minutos enquanto o espaço de trabalho é configurado.
Depois de carregado, passe o cursor sobre "Recursos" no painel à esquerda e selecione "Kubernetes Engine NEW" no menu.
Cada linha no painel apresentado aqui representa um recurso do Kubernetes. É possível alternar entre as visualizações de infraestrutura, cargas de trabalho ou serviços com os links acima do painel.
Na visualização "Cargas de trabalho", expanda "my-gke-cluster" e detalhe até default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset. Clique no contêiner do conjunto stateful do webserver. Aqui, você encontra algumas métricas prontas para uso capturadas pelo Stackdriver, incluindo uso de memória e uso da CPU.
Os gráficos mostrados neste painel são os que vamos usar para criar um painel personalizado.
Painéis personalizados
Com o Stackdriver, é possível criar painéis personalizados para organizar gráficos e tabelas de qualquer dado de métrica disponível. Vamos criar um painel personalizado para fornecer uma visão geral de algumas das métricas do nosso servidor da Web.
No painel à esquerda, passe o cursor sobre "Painéis" e clique em "Criar painel".
Agora que temos nosso painel vazio, podemos adicionar as métricas que queremos monitorar. Vamos dar ao painel sem título um nome útil, como "Meus contêineres de 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", digite "Utilização da CPU". Na caixa "Encontrar tipo de recurso e métrica", digite request_utilization e selecione "Utilização de solicitação da 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 na lista filtrada e escolha seu projeto no campo "Valor". Também precisamos filtrar por container_name. Na caixa "Filtro", digite container_name, selecione na lista filtrada e escolha "webserver-statefulset" no campo "Valor". Clique em "Salvar".
Agora temos um painel com nosso primeiro gráfico.
7. Política de alertas e verificação de tempo de atividade
Com o Stackdriver, podemos configurar alertas para receber notificações quando qualquer métrica atingir os valores 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 prolongado, 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 à esquerda, 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. Clique no botão Adicionar verificação de tempo de atividade na parte superior direita da página.
No formulário a seguir, 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 crie uma política de alertas:
Clique em Criar política de alertas.
Vamos nomear como "Política de tempo de atividade do endpoint". Na seção Configuração, defina "Condição acionada se" como "Qualquer violação de série temporal" e clique em Salvar.
Ainda não terminamos. Em seguida, vamos especificar um canal de notificação para que possamos ser avisados quando nossa política de alertas for violada. No menu suspenso "Tipo de canal de notificação", selecione "E-mail" e digite 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 como "Tempo de atividade do app da Web" e clique em "Salvar".
Para ver como um alerta vai aparecer, abra o Cloud Shell novamente no console do Cloud. 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 alerta por e-mail sobre a interrupção do serviç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:
8. Limpeza
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, siga 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 Migrate for Anthos, conjunto com estado e serviço de balanceador de carga)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Discos
Nosso conjunto stateful usou um disco que criamos. Use o seguinte para recuperar o nome:
gcloud compute disks list --filter=webserver
Usando o nome do seu disco em vez do meu, exclua-o com:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Tudo limpo!
9. Parabéns!
Parabéns! Você migrou seu 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 saber quando nosso servidor da Web fica inativo.