IaC – Infraestrutura como Código

Sempre que desenvolvemos uma aplicação, o time de desenvolvimento necessita da criação de ambientes de desenvolvimento, homologação e QA para realizar os testes de suas aplicações.

Historicamente a criação destes ambientes é um longo processo desgastante que pode levar dias, semanas ou meses e com pouca efetividade, regado de intervenções manuais que raramente garante que os ambientes sejam idênticos.

Com a evolução da tecnologia, com o objetivo de criar ambientes idênticos e em um tempo consideravelmente menor, que pode chegar há dias ou horas dependendo de como o processo foi estruturado, surgem os profissionais que trabalham com IaC.

IaC (Infrastructure as Code / Infraestrutura como Código) é o termo utilizado por profissionais que tratam a infraestrutura como software, ou seja ao invés de realizar uma série de configurações manualmente, toda a infra é criada através de código.

Adotar essa prática permite a times de infraestrutura implementarem as mesmas praticas que times de desenvolvimento como code review, pair programming ou até mesmo construir testes automatizados que validem toda a configuração da infraestrutura.

Além de criar recursos, existem muitas tecnologias que implementam as práticas de IaC que também destróem os recursos, possibilitando os times de infraestrutura uma melhor eficiência financeira, por exemplo em ambientes cloud onde o modelo de cobrança é por hora, podemos destruir todos os ambientes que não sejam produtivos durante a noite e cria-los novamente pela manhã.

Passos para o sucesso

Vamos supor que toda a infraestrutura da minha companhia roda na AWS e vários dos meus micro serviços, precisam de uma fila no SQS. Para configurar essa fila, foi criado um código com Terraform e disponibilizado em um servidor GIT, este artefato sabe como criar uma fila, mas não conhece suas configurações básicas, sempre que executado, é preciso informar os seguintes parâmetros:

Nome da Fila
Delay em segundos
Tamanho máximo de cada mensagem
Segundos de retenção das mensagens
Tempo de espera em segundos
Se a fila é do tipo FIFO ou não

CI – Integração Contínua

Como qualquer tipo de código, precisamos de um processo que agregue todo código feito pelo engenheiro de infraestrutura e o passe por um fluxo maduro de integração contínua.

Como qualquer fluxo de integração contínua, não existe uma receita única para o sucesso, esse fluxo pode variar muito conforme a tecnologia utilizada e o contexto de cada companhia. Pensando em uma estrutura base para a maioria dos cenários, podemos pensar na seguinte estrutura:

O Checkout é um passo fundamental para o sucesso na integração contínua, ele se baseia no uso de um controlador de versão distribuído baseado em GIT, onde o engenheiro de infraestrutura disponibiliza todo o código do artefato e inicializa automaticamente a integração contínua.

Quando utilizamos Terraform, os Testes Unitários podem validar se o Remote State do artefato existe e se a sintaxe do código foi escrita com sucesso.

Ja no passo build, é realizado a compilação e criação do artefato, o tornando imutável e o disponibilizando em algum tipo de registry privado como o ACR (Aws Container Registry). Vale ressaltar que nesse momento vamos liberar 2 imagens no registry, em uma imagem estará o artefato com os comandos que criam a infraestrutura e na outra o artefato com os comandos que destroem a infraestrutura.

CD – Entrega Contínua

Como qualquer processo do ciclo de desenvolvimento de software, um fluxo de CD de um artefato de infraestrutura, deve ser planejado desde o momento da construção do código de negócio, pensando não somente na construção da infraestrutura, mas em como os dados sensíveis serão entregues para a aplicação.

No primeiro fluxo, onde estamos publicando a fila na AWS, podemos pensar na seguinte estrutura:

O passo pré-validação verifica se todas as variáveis necessárias para executar o artefato de publicação da fila, foram preenchidas corretamente, exibindo mensagens direcionadas em caso de erros de preenchimento. Cada aplicação deve ter seus parâmetros personalizados, é neste momento que eles são definidos.

A Publicação é o passo que recupera a imagem que destrói uma fila na AWS, no registry privado e passa os parâmetros para criação da fila na AWS.

Ja o Cofre de Senhas é o passo que irá salvar os dados sensíveis da fila em um cofre de senhas, para que a aplicação consuma quando for publicada.

Já no segundo fluxo, onde estamos destruindo a fila na AWS, podemos pensar na seguinte estrutura:

O passo pré-validação verifica se todas as variáveis necessárias para executar o artefato de destruição da fila, foram preenchidas corretamente, exibindo mensagens direcionadas em caso de erros de preenchimento.

A Destruição é o passo que recupera a imagem que destrói uma fila na AWS, no registry privado e passa os mesmos parâmetros que foram passados no momento da publicação.

Ja o Cofre de Senhas é o passo que irá remover os dados sensíveis da fila no cofre de senhas.

Conclusão

Como vimos acima, utilizar práticas IaC no dia a dia se torna algo objetivo e estratégico para uma empresa, alem de ganhos intangíveis como ambientes de teste idênticos ao ambiente produtivo, temos ganhos tangíveis como a redução do tempo de disponibilização de ambientes e a destruição de ambientes não produtivos fora do horário comercial.

O exemplo acima foi totalmente direcionado a publicação de uma fila em um ambiente SQS da AWS, mas ele é facilmente adaptável a diversos componentes do ecossistema de uma aplicação e em diferentes provedores Cloud.

Por Willian da Silva, Arquiteto de soluções no Grupo FCamara

Quer saber mais? Veja todos os artigos que escrevemos dessa série sobre DevOps:
https://blog.fcamara.com.br/categorias/devops/