Como IaC está revolucionando a infra da Stone — Parte I

Infraestrutura como Código (IaC) já é uma realidade na tecnologia dos maiores players do mercado. Usá-la para automatizar sua infra é uma jornada árdua, mas frutífera.

Na Stone, alguns de nossos produtos ainda rodam em nossos Data Centers on-premises. Esses produtos ficam sob uma infra clássica com VMWare, F5-BigIP e Firewalls tradicionais, o que traz diversos desafios e problemas para a operação diária.

Antes de utilizarmos IaC, a operação desses ambientes clássicos era basicamente manual, assim o provisionamento de novos recursos demorava bastante. Além disso, as ações manuais eram extremamente propensas a erros, tornando o tratamento de incidentes ainda mais difícil. Para completar a documentação da infra dos produtos hospedados nesses ambientes era pobre, muitos detalhes importantes estavam apenas na memória dos colaboradores.

IaC e o nosso objetivo

Para nós, usar IaC foi uma combinação perfeita. Queríamos ter uma especificação completa e executável do que roda nessa infra clássica, mas não só isso, queríamos poder descrever exatamente os recursos necessários por um produto. Com isso em mãos gostaríamos de ter um fluxo completamente automatizado para fazer alterações da forma mais simples possível.

Ter uma especificação completa e executável dos recursos de infraestrutura que cada produto nosso precisa, e um fluxo automatizado, seguro e rastreável de gerência de mudanças destes recursos, ganhando agilidade na gestão da infra on-premises.

IaC nos entrega tudo isso! Descrevendo a especificação da nossa infra como código temos uma documentação completamente executável e que pode ser reproduzida quantas vezes desejarmos. Ganhamos também consistência entre nossos ambientes, já que tudo é provisionado como código. E, por fim, um fluxo para a execução dessa especificação nos dá rastreabilidade e permite a revisão de outras pessoas entendedoras antes da execução.

Arquitetamos um fluxo de deploy de infra como código que nos permite rastrear todos os passos, além de nos dizer quem foram os aprovadores de cada mudança. Para o mercado financeiro, garantir esses itens já é meio caminho andado em direção à aprovação anual nas principais certificações. Nesse fluxo utilizamos algumas das ferramentas mais populares do mercado como Github, Azure DevOps e Ansible.

Uma representação do fluxo de deploy de infra como código

Tudo começa com um Pull Request no repositório Git que define a infra de algum de nossos produtos. Imediatamente o Azure DevOps faz um check estático na branch que contém as mudanças validando o código sem executá-lo. Enquanto isso, os aprovadores técnicos de cada tipo de especificação revisam o código submetido. Quando existe uma aprovação de todos e o merge na branch master é feito, imediatamente inicia-se uma release pelo Azure DevOps, que inicia Jobs no AWX via Tower-cli. Por último, esses jobs executam o código escrito em Ansible para aplicar as mudanças propostas.

Por que Ansible?

Essa é uma pergunta que todo desenvolvedor de software, em algum momento, acha fácil e em outros acha difícil. Muitas vezes essa pergunta se torna difícil quando o problema possui diversas soluções. Nesse momento nos perguntamos em qual ferramenta/linguagem/framework conseguiremos resolver mais rapidamente e gerar pouco trabalho para manter o produto vivo. Outras vezes a resposta à pergunta se torna fácil quando boa parte do time envolvido possui alguma habilidade em comum. Esse foi o nosso caso para decidir qual ferramenta de automação usaríamos para resolver nossos problemas. Grande parte do nosso time de infraestrutura possuía boas skills com Ansible, além disso, também já tínhamos uma boa base de código pronta para ser usada.

Além da nossa familiaridade, o Ansible nos permite seguir num caminho de descentralização do trabalho com infraestrutura. De forma que qualquer colaborador pode aprender por si só e usar a ferramenta para automatizar sua infra. Isso quer dizer que deixamos de lado as outras ferramentas do cardápio do mundo DevOps? Claro que não! O Ansible faz a orquestração com maestria, mas precisávamos garantir a configuração de um recurso mesmo depois de um playbook criá-lo. Usamos o Puppet para finalizar o provisionamento e garantir a gerência das configurações base dos nossos serviços.

Uma base de código Ansible

Nessa jornada conseguimos construir uma enorme base de código de roles Ansible. Costumamos nos basear nas roles publicadas no Ansible Galaxy para fazer as nossas e aplicar nossas próprias políticas. Além disso, cada um dos nossos produtos possui um repositório de playbooks (que não tem muitas diferenças do sugerido na própria documentação do Ansible) para definir a infra necessária. Isso contribuiu para produzirmos uma gama imensa de repositórios. Hoje, temos diversos exemplos de aplicações das nossas roles e setups de infra espalhados em nosso GitHub. Inclusive, algumas são públicas: ansible-mongodb, ansible-rabbitmq entre outras.

Quase tudo as code

Mesmo tendo uma grande base de código em Ansible, sabíamos que ficar presos a apenas uma ferramenta seria um tiro no pé. Com isso, todas as definições de recursos de nossa infra são definidas como arquivos YAML, dessa forma podemos usá-las com outras ferramentas como Terraform. Um exemplo muito simples do que estamos falando é a definição de máquinas virtuais, algo muito presente no nosso ambiente clássico.

Com essa definição podemos dizer para nossa automação que um serviço precisa de 3 máquinas virtuais Linux com 2 CPUs e 4GB de memória. Ainda podemos dizer os hostnames e o quanto de disco elas precisarão, além de definir em qual rede interna elas estarão conectadas. Isso nos dá muito poder sobre nossa infra, pois temos exatamente o queríamos lá no início: uma documentação executável e atualizada.

Fomos um pouco mais além disso e passamos a definir balanceamento usando arquivos YML.

Com isso temos uma definição simples e completa da configuração de balanceamento que um serviço precisa. Podemos dizer quais os nós estarão servindo aquele serviço, para quais estaremos roteando tráfego e quais as portas internas e externas estão abertas para novas conexões.

Essas e outras definições feitas via arquivo são hoje consumidas por roles Ansible, mas podem ser lidas por módulos Terraform ou alguma outra ferramenta que saiba interpretá-las. Além disso, um dos maiores ganhos está no encapsulamento que essas roles provêm. O(A) SRE que gerencia algum produto não precisa conhecer a fundo sobre VMWare ou BigIP para descrever os recursos de que precisa. Apenas é necessário produzir arquivos simples de definição e a automação toma conta de todo o trabalho que antes era manual.

Na parte II desta série, mostraremos um pouco mais do fluxo de deploy de infra na prática e a execução das roles.