Infraestrutura como código: Terraform e Kubernetes

Iniciando o projeto - Apresentação

Olá, eu sou Leonardo Sartorello e serei seu instrutor neste curso de infraestrutura como código. A seguir, vamos dar uma olhada no que aprenderemos.

Neste treinamento, vamos estudar EKS, Elastic Kubernetes Service, o serviço de Kubernetes da AWS (Amazon Web Services). O interessante de conhecer o Kubernetes é que se trata de uma tecnologia padronizada, então grande parte do que abordaremos no curso poderá ser aplicado para outros provedores, como a Amazon ou a Azure.

Também trabalharemos com multi-provedores, que será um novo desafio para dominarmos! Por que aprender sobre eles? Sempre usamos a AWS como única provedora, porém como o Kubernetes é padronizado, ele também é cadastrado como um provedor dentro do Terraform. Logo, vamos encarar esse desafio de multi-provedores!

Outro tópico importante do curso são os módulos. Eles funcionam como se fossem bibliotecas em linguagens de programação e permitem que desenvolvamos mais rapidamente, escrevendo menos código.

E quais ferramentas vamos utilizar? O Kubernetes e o Terraform. O primeiro será responsável por cuidar da nossa aplicação, enquanto o segundo montará o cluster e configurará o Kubernetes. O cluster é onde colocaremos as máquinas que serão gerenciadas pelo Kubernetes, para serem executadas. Todo esse projeto será montado na AWS, que hoje é uma das maiores provedoras de cloud disponíveis.

E para quem é destinado esse curso? O foco são pessoas que já estão estudando IaC (Infrastructure as Code, em português, infraestrutura como código) e que já completaram os cursos que são pré-requisitos deste.

Fazendo esse curso, seremos capazes de colocar aplicações Docker dentro do Kubernetes para serem executadas, trabalharemos com módulos que dão maior velocidade de desenvolvimento, criaremos um load balancer (dessa vez, gerido pelo Kubernetes e não pela AWS) e, por fim, faremos o deploy da aplicação dentro do cluster do Kubernetes.

Então, não é empolgante? Vamos lá?

Iniciando o projeto - Entendendo o projeto

A start-up da Ana, onde estamos trabalhando, tem como principal produto uma API que ela desenvolveu durante seu TCC. Anteriormente, colocamos essa API no ar usando o Beanstalk e o ECS (Elastic Container Service), porém a Ana gostaria de utilizar uma tecnologia mais comum entre os provedores. Assim, não precisaremos nos preocupar com tecnologias proprietárias.

Uma tecnologia que aceita contêineres e não é proprietária de nenhum provedor é o Kubernetes. Afinal, tudo que vamos utilizar dos provedores são as máquinas para montar o cluster em que usaremos as instâncias do Kubernetes, então não temos nenhuma tecnologia exclusiva para nossa aplicação.

Com essa motivação, vamos pensar em uma solução junto com a Ana? Vamos criar um plano para trocar a nossa aplicação, atualmente no ECS, para o EKS (Elastic Kubernetes Service).

A princípio, vamos entender melhor o nosso projeto. Atualmente, ele está rodando no Elastic Container Service (ECS) e nosso objetivo é passá-lo para o Elastic Kubernetes Service (EKS). Com essa alteração, no entanto, permanecemos na Amazon — há um motivo para essa escolha?

É por mera conveniência: já usamos a Amazon hoje em dia e vamos manter nela. Como Kubernetes não é uma tecnologia proprietária, também poderíamos utilizar o Kubernetes fornecido pela Google (GKE — Google Kubernetes Engine) ou o fornecido pela Azure (AKS — Azure Kubernetes Service). Por ora, permaneceremos com a Amazon.

Além da vantagem de não ser uma tecnologia proprietária, o Kubernetes nos proporciona algumas outras vantagens, como a simplicidade de migração entre provedores. Em outras palavras, é fácil mudar de um provedor para outro de maneira descomplicada, já que estamos utilizando apenas as instâncias desse provedor. Então não é necessária nenhuma tecnologia estranha, que precisemos aprender do zero.

O Kubernetes também dispõe de maior resistência a falhas, dado que é possível ter instâncias em vários locais distintos, de modo que podemos ter nossa aplicação rodando em lugares diferentes trabalhando como se fosse um único elemento, graças ao cluster do Kubernetes.

Outra vantagem é a facilidade de organização dos serviços dentro dos pods. O Kubernetes não trabalha exatamente com contêineres, ele trabalha com pods, que são como caixas em volta do contêiner — e podemos colocar vários contêineres dentro de uma caixa.

Por exemplo, se nossa aplicação for composta por três contêineres (um para a aplicação em si, outro para métricas e mais outro para logs), conseguimos manter os três contêineres unidos dentro de um pod. Então, sempre que subirmos a aplicação no Kubernetes, estaremos subindo a aplicação com tudo que ela precisa para funcionar corretamente. Ou seja, não precisamos nos preocupar com que tipo de serviço está ativo, se estamos mantendo os logs da aplicação etc. O gerenciamento da aplicação é mais fácil e podemos manter várias delas rodando em um único cluster.

Além desses fatores, também há a possibilidade de interligações entre provedores. Por exemplo, podemos ter um cluster na Amazon e outro na Google de modo que trabalhem com se fossem apenas um. Caso a Amazon inteira fique fora do ar por um período, a nossa aplicação não cairá, porque ela continua rodando no cluster da Google. Talvez a aplicação fique mais lenta, já que pode sobrecarregar esse cluster, porém ela se mantém no ar.

A seguir, vamos identificar o que temos atualmente e do que precisamos para mudar para o EKS. Em nosso projeto, temos a região. Dentro dela, há as zonas de disponibilidades. E, dentro de cada uma delas, temos a rede pública e a rede privada, esta última rodando com instância do ECS. Na rede pública, temos o load balancer e o NAT Gateway para termos acessos às nossas instâncias da rede privada, que têm o ECS e as máquinas rodando essas instâncias do ECS.

O que precisamos fazer? Vamos tirar as instâncias do ECS e, no lugar, colocaremos as instâncias do EKS, do Kubernetes. Para iniciarmos nosso trabalho, esse é um bom começo. Depois, faremos mais alterações interessantes, como tirar o load balancer — hoje manejado pela Amazon — e passá-lo a um serviço do Kubernetes. Dessa forma, se decidirmos mudar de provedor ou usar mais de um simultaneamente, é mais simples de levar esse load balancer, sem a necessidade de muitas configurações, visto que será manejado pelo próprio Kubernetes.

Então, não é empolgante? Vamos lá?

Iniciando o projeto - Iniciando o projeto

Agora que dispomos de um plano de ação, podemos começar a alterar, de fato, a nossa infraestrutura para colocar nossos contêineres no EKS.

Para tanto, precisamos do código que representa a infraestrutura pronta que temos hoje para, então, modificar as partes necessárias. Faremos uma cópia dessa infraestrutura por meio da página do GitHub onde estão os códigos usados no último curso.

O link desse repostório está disponível na plataforma. Ele será necessário para algumas atividades. Você pode dar uma olhada nos arquivos para se familiarizar com o projeto.

Nesta página, clicaremos no botão verde "Code", copiaremos o link do repositório e, no Visual Studio Code (VS Code), vamos cloná-lo com o comando git clone seguido da URL que copiamos há pouco. Na barra lateral, à esquerda, podemos observar os arquivos clonados, na pasta iac-curso5. Vamos explorá-los a seguir.

Dentro de environments (env), temos nosso ambiente de produção (prod), que contém Backend.tf e Main.tf. Já no diretório infra, temos Provider.tf, Variaveis.tf e ECR.tf. Faltam ainda alguns elementos, precisamos dos arquivos do ECS, do load balancer e dos grupos de segurança.

Voltando ao GitHub, vamos à página da branch "Aula_6". Na pasta infra, encontraremos os arquivos desejados.

Para acessá-los, teremos que trocar de "Aula_1" para "Aula_6". No VS Code, primeiramente vamos entrar na pasta iac-curso5, com cd iac-curso5/. Em seguida, executaremos o comando git checkout Aula_6. Dessa forma, no painel à esquerda teremos todos os arquivos da branch "Aula_6".

Enquanto digitamos um comando no console, é possível pressionar a tecla "Tab" para consultar sugestões de preenchimento automático.

Vamos rodar o comando cd .. para sair de iac-curso5.

No momento, nossos arquivos estão dentro de uma pasta chamada iac-curso5 que está dentro de outra pasta de nome IaC. Para organizar o projeto, vamos mover tudo para IaC, esvaziando iac-curso5. Uma vez vazia, podemos apagá-la — basta clicar sobre a pasta com o botão direito do mouse e selecionar "Excluir permanentemente".

Para confirmar que todos os arquivos estão no diretório IaC, rodaremos o comando ls e como retorno veremos README.md, env e infra — o mesmo arranjo do painel à esquerda. Note que o .gitignore começa com um ponto, o que significa que é um arquivo oculto. Para enxergá-lo na estrutura, podemos usar o comando ls -lha, que exibe também os itens ocultos, entre outros detalhes, como o tamanho.

Com os arquivos organizados, partiremos para as modificações. Primeiro, é preciso desligar nossa infraestrutura: podemos ir em "env > prod", executar terraform init seguido de terraform destroy para finalizar toda a infraestrutura existente e começar do zero. No caso, já fiz isso, minha infraestrutura não está mais em execução.

No entanto, nem sempre é possível realizar esse desligamento, pois em um cenário real a nossa aplicação estaria em produção e nossos clientes poderiam depender dela. Nesses casos em que não é possível parar a aplicação completamente, é interessante subirmos uma infraestrutura completa, separada, e depois fazer uma migração dessa infraestrutura já pronta, já testada e com a nossa aplicação para os nossos clientes. Assim, teremos um tempo mínimo fora do ar, o menor período possível de downtime. No nosso contexto de estudos, já estamos com ela parada, então não há problemas.

Em seguida, vamos remover as partes que não precisaremos. No caso, os arquivos do ECS são desnecessários, já que pretendemos deslocar para o EKS. Então, vamos excluir ECS.tf permanentemente.

Além disso, não precisaremos criar um load balancer pela Amazon, pois vamos defini-lo dentro do Kubernetes, logo, podemos deletar o arquivo ALB.tf (Application Load Balancer).

Quanto ao permissionamento, no caso do EKS não será necessária nenhuma permissão especial, então temos a liberdade de apagar o arquivo IAM.tf, que contém informações de cargos e políticas de acesso. Assim, removemos todos os arquivos desnecessários.

Vale lembrar que, caso surja a necessidade de realizar ações com um banco de dados (por exemplo, o DynamoDB, fornecido pela Amazon), vamos precisar de permissionamento para acessar esse banco. Para o nosso cenário atual, não precisamos, mas em outros contextos é possível que sejam necessárias permissões, mesmo para o EKS.

Um ponto importante é que, sempre que removemos arquivos do Terraform, temos duas opções: ou usamos terraform destroy antes de apagar os arquivos, ou terraform apply logo após deletá-los. Dessa forma, mantemos essa infraestrutura planejada o mais parecida possível com o que temos atualmente rodando na nuvem.

Agora que limpamos nossa infraestrutura e removemos tudo que não era necessário, podemos nos concentrar no EKS.

Sobre o curso Infraestrutura como código: Terraform e Kubernetes

O curso Infraestrutura como código: Terraform e Kubernetes possui 105 minutos de vídeos, em um total de 44 atividades. Gostou? Conheça nossos outros cursos de Infraestrutura como Código em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Iniciando o projeto
• Módulo do EKS
• Configurando outro provedor
• Preparando a aplicação
• Load Balancer