Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infraestrutura como C\u00f3digo (IaC)<\/h2>\n
<\/p>\n
Breve descri\u00e7\u00e3o da tecnologia<\/h3>\n
\n E aqui chegamos \u00e0 \u00faltima se\u00e7\u00e3o. Normalmente, essa tecnologia e as tarefas relacionadas n\u00e3o est\u00e3o sob a responsabilidade dos engenheiros de automa\u00e7\u00e3o. E h\u00e1 raz\u00f5es para isso. Primeiro, em muitas organiza\u00e7\u00f5es, quest\u00f5es de infraestrutura est\u00e3o sob o controle do departamento de DevOps e a equipe de desenvolvimento n\u00e3o se preocupa muito com o que faz o pipeline funcionar e como manter tudo o que est\u00e1 relacionado a isso. Em segundo lugar, sejamos honestos, a pr\u00e1tica \"Infraestrutura como C\u00f3digo (IaC)\" ainda n\u00e3o \u00e9 aplicada em muitas empresas. Mas definitivamente isso se tornou uma tend\u00eancia popular e \u00e9 importante tentar estar envolvido nos processos, abordagens e ferramentas relacionadas. Ou, pelo menos, estar ciente dos eventos.<\/p>\n
Comecemos pela motiva\u00e7\u00e3o para usar essa abordagem. J\u00e1 discutimos que, para executar testes no GitlabCI, precisaremos, no m\u00ednimo, de recursos para iniciar o Gitlab Runner. E para executar cont\u00eaineres com navegadores\/emuladores, precisamos reservar uma VM ou um cluster. Al\u00e9m dos recursos para testes, tamb\u00e9m precisamos de uma quantidade significativa de capacidade para manter os ambientes de desenvolvimento, staging e produ\u00e7\u00e3o, o que inclui bancos de dados, cronogramas autom\u00e1ticos, configura\u00e7\u00f5es de rede, balanceadores de carga, permiss\u00f5es de usu\u00e1rios e assim por diante. O problema chave reside nos esfor\u00e7os necess\u00e1rios para manter tudo isso. Existem v\u00e1rias maneiras de como podemos fazer mudan\u00e7as e implantar atualiza\u00e7\u00f5es. Por exemplo, no contexto do GCP, podemos usar o console UI no navegador e realizar todas as a\u00e7\u00f5es clicando em bot\u00f5es. Uma alternativa pode ser usar chamadas de API para interagir com entidades na nuvem ou aplicar a ferramenta de linha de comando gcloud para realizar as manipula\u00e7\u00f5es necess\u00e1rias. Mas, com uma quantidade realmente grande de diferentes entidades e elementos de infraestrutura, torna-se dif\u00edcil ou at\u00e9 imposs\u00edvel realizar todas as opera\u00e7\u00f5es manualmente. Al\u00e9m disso, todas essas a\u00e7\u00f5es manuais s\u00e3o incontrol\u00e1veis. N\u00e3o podemos envi\u00e1-las para revis\u00e3o antes de executar, usar um sistema de controle de vers\u00f5es e reverter rapidamente altera\u00e7\u00f5es que levaram a um incidente. Para resolver tais problemas, engenheiros criaram e ainda criam scripts autom\u00e1ticos em bash\/shell, que n\u00e3o s\u00e3o muito melhores do que os m\u00e9todos anteriores, pois n\u00e3o s\u00e3o t\u00e3o f\u00e1ceis de ler, entender, manter e modificar rapidamente em um estilo procedural.<\/p>\n
Neste artigo e guia pr\u00e1tico, utilizo 2 ferramentas relacionadas \u00e0 pr\u00e1tica de IaC. S\u00e3o elas Terraform e Ansible. Alguns acreditam que n\u00e3o faz sentido usar ambas ao mesmo tempo, pois suas funcionalidades s\u00e3o semelhantes e elas s\u00e3o intercambi\u00e1veis. No entanto, o fato \u00e9 que, inicialmente, elas s\u00e3o projetadas para tarefas completamente diferentes. E o fato de que essas ferramentas devem se complementar foi confirmado em uma apresenta\u00e7\u00e3o conjunta pelos desenvolvedores das empresas HashiCorp e RedHat. A diferen\u00e7a conceitual \u00e9 que o Terraform \u00e9 uma ferramenta de provisionamento para gerenciar os pr\u00f3prios servidores, enquanto o Ansible \u00e9 uma ferramenta de gerenciamento de configura\u00e7\u00f5es, cuja tarefa \u00e9 instalar, configurar e gerenciar o software nesses servidores.<\/p>\n
Outra caracter\u00edstica distintiva importante dessas ferramentas \u00e9 o estilo de escrita do c\u00f3digo. Ao contr\u00e1rio do bash e do Ansible, o Terraform utiliza um estilo declarativo, baseado na descri\u00e7\u00e3o do estado final desejado a ser alcan\u00e7ado como resultado da execu\u00e7\u00e3o. Por exemplo, se quisermos criar 10 VMs e aplicar as mudan\u00e7as atrav\u00e9s do Terraform, obteremos 10 VMs. Se executarmos o script novamente, nada acontecer\u00e1, pois j\u00e1 temos 10 VMs, e o Terraform sabe disso, uma vez que ele armazena o estado atual da infraestrutura em um arquivo de estado. J\u00e1 o Ansible utiliza uma abordagem procedural e, se pedirmos para criar 10 VMs, na primeira execu\u00e7\u00e3o obteremos 10 VMs, semelhante ao Terraform. Por\u00e9m, ap\u00f3s a segunda execu\u00e7\u00e3o, teremos 20 VMs. Essa \u00e9 a importante diferen\u00e7a. No estilo procedural, n\u00e3o armazenamos o estado atual e apenas descrevemos a sequ\u00eancia de etapas que devem ser executadas. Naturalmente, podemos lidar com v\u00e1rias situa\u00e7\u00f5es, adicionar algumas verifica\u00e7\u00f5es sobre a exist\u00eancia de recursos e o estado atual, mas n\u00e3o faz sentido desperdi\u00e7ar nosso tempo e esfor\u00e7o controlando essa l\u00f3gica. Al\u00e9m disso, isso aumenta o risco de cometer erros.\u00a0<\/p>\n
Resumindo tudo o que foi dito acima, podemos concluir que, para o provisionamento de servidores, a ferramenta mais adequada \u00e9 o Terraform e a nota\u00e7\u00e3o declarativa. J\u00e1 o trabalho de gerenciamento de configura\u00e7\u00f5es \u00e9 melhor delegado ao Ansible. Com isso esclarecido, vamos ver exemplos de uso no contexto da automa\u00e7\u00e3o.<\/p>\n
Valor para a infraestrutura de automa\u00e7\u00e3o<\/h3>\n
\n Aqui, \u00e9 importante entender que a infraestrutura de automa\u00e7\u00e3o de testes deve ser considerada como parte de toda a infraestrutura da empresa. Isso significa que todas as pr\u00e1ticas de IaC devem ser aplicadas globalmente aos recursos de toda a organiza\u00e7\u00e3o. Quem \u00e9 respons\u00e1vel por isso depende de seus processos. A equipe de DevOps tem mais experi\u00eancia nesses assuntos, pois ela v\u00ea o quadro geral. No entanto, os engenheiros de QA est\u00e3o mais envolvidos no processo de constru\u00e7\u00e3o da automa\u00e7\u00e3o e na estrutura do pipeline, o que lhes permite perceber melhor todas as mudan\u00e7as necess\u00e1rias e oportunidades de melhoria. A melhor op\u00e7\u00e3o \u00e9 trabalhar em conjunto, trocando conhecimentos e ideias para alcan\u00e7ar o resultado esperado.\u00a0<\/p>\n
Vou dar alguns exemplos de uso do Terraform e Ansible no contexto de automa\u00e7\u00e3o de testes e das ferramentas que discutimos anteriormente:<\/p>\n
1. Descrever, atrav\u00e9s do Terraform, as caracter\u00edsticas e par\u00e2metros necess\u00e1rios para VMs e clusters.<\/p>\n
2. Instalar, com o Ansible, as ferramentas necess\u00e1rias para testes: docker, Selenoid, Selenium Grid e baixar as vers\u00f5es necess\u00e1rias de navegadores\/emuladores.<\/p>\n
3. Descrever, atrav\u00e9s do Terraform, as caracter\u00edsticas da VM onde o GitLab Runner ser\u00e1 executado.<\/p>\n
4. Instalar, com o Ansible, o GitLab Runner e as ferramentas auxiliares necess\u00e1rias, definindo as configura\u00e7\u00f5es e ajustes.<\/p>\n
Ilustra\u00e7\u00e3o do estado atual da infraestrutura<\/h3>\n
\n![\"Ferramentas](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Links para estudo:<\/h3>\n
<\/p>\n