🥇Ansible: Migração da configuração de 120 VMs do CoreOS para o CentOS em 18 meses

Esta é a transcrição da apresentação em DevopsConf 2019-10-01 e SPbLUG 2019-09-25.

Esta é a história de um projeto que utilizou um sistema de gerenciamento de configurações feito sob medida e porque a migração para o Ansible levou 18 meses.

Dia nº -XXX: Antes do começo

Inicialmente, a infraestrutura consistia em vários hosts independentes gerenciados pelo Hyper-V. Criar uma máquina virtual exigia várias ações: colocar os discos no lugar certo, configurar o DNS, reservar o DHCP, colocar a configuração da VM no repositório git. Este processo foi parcialmente mecanizado, mas, por exemplo, as VMs eram distribuídas entre os hosts manualmente. No entanto, os desenvolvedores podiam corrigir a configuração da VM no git e aplicá-la reiniciando a VM.

Solução Personalizada de Gerenciamento de Configuração

A ideia inicial, suspeito, foi pensada como IaC: várias VMs stateless que, ao reiniciar, zeravam seu estado. Como era o gerenciamento de configurações das VMs? Em termos esquemáticos, parecia simples:

Para as VMs, um MAC estático era atribuído.
Conectava-se uma ISO com o CoreOS e um disco de boot.
O CoreOS executa um script de customização, baixando-o do servidor WEB com base em seu IP.
O script baixa a configuração da VM via SCP, baseando-se no endereço IP.
Uma série de arquivos de unidade do systemd e uma série de scripts bash são executados.

Essa solução apresentava vários problemas óbvios:

A ISO no CoreOS estava obsoleta.
Muitas ações complexas e mágicas durante a migração/criação das VMs.
Dificuldade com as atualizações e quando um determinado software é necessário. Isso se tornava ainda mais complicado com os módulos do kernel.
As VMs não estavam tão desprovidas de dados assim, ou seja, surgiram VMs que montavam um disco adicional com dados do usuário.
Constantemente alguém cometia erros com dependências do systemd e, ao reiniciar, o CoreOS travava. Era problemático identificar isso com os recursos disponíveis no CoreOS.
Gerenciamento de segredos.
Praticamente não havia CM. Havia bash e arquivos de configuração YML do CoreOS.

Para aplicar a configuração da VM, era necessário reiniciá-la, mas ela poderia não reiniciar. Uma aparente problema óbvio, mas sem discos persistentes — não havia para onde salvar logs. Bem, vamos tentar adicionar opções de kernel para que os logs sejam enviados. Mas não, tudo isso era muito complicado.

Dia nº 0: Reconhecimento do problema

Essa era uma infraestrutura de desenvolvimento comum: jenkins, ambientes de teste, monitoramentos, registry. O CoreOS foi projetado para hospedar clusters k8s, ou seja, o problema estava em como o CoreOS era utilizado. O primeiro passo foi a escolha da pilha. Nós optamos por:

CentOS como a distribuição base, pois esta é a distribuição mais próxima de ambientes de produção.
Ansible para gerenciamento de configurações, pois havia uma ampla expertise nessa área.
Jenkins como framework de automação de processos existentes, pois já estava sendo utilizado ativamente nos processos de desenvolvimento.
Hyper-V como plataforma de virtualização. Existem várias razões, além do que foi contado, mas resumindo — não podemos usar nuvens, devemos usar nosso próprio hardware.

Dia nº 30: Documentando acordos existentes — Agreements as Code

Quando a pilha foi definida, a preparação para a migração começou. A codificação dos acordos existentes como código (Agreements as Code!). A transição trabalho manual -> mecanização -> automação.

1. Configurar VMs

O Ansible lida muito bem com essa tarefa. Com o mínimo de esforço, podemos gerenciar as configurações das VMs:

Criamos um repositório git.
Colocamos a lista de VMs no inventário, as configurações nos playbooks e papéis.
Configuramos um slave jenkins especial do qual será possível executar o ansible.
Criamos um job, configuramos o Jenkins.

O primeiro processo está pronto. Os acordos foram documentados.

2. Criar nova VM

Aqui tudo estava um pouco complicado. A partir do Linux, não é muito fácil criar VMs no Hyper-V. Uma das tentativas de automatizar esse processo foi:

Ansible se conecta ao host Windows via WinRM.
Ansible executa um script PowerShell.
O script PowerShell cria uma nova VM.
Com ferramentas Hyper-V/ScVMM, ao criar a VM, o hostname é configurado no sistema operacional convidado.
A VM, ao renovar o lease DHCP, envia seu hostname.
A integração padrão ddns & dhcp no lado do Controller de Domínio configura o registro DNS.
É possível adicionar VMs ao inventário e configurá-las com Ansible.

3. Criar template de VM

Aqui não inventamos nada — usamos o packer.

No repositório git, colocamos a configuração do packer, kickstart.
Configuramos um slave jenkins especial com hyper-v e Packer.
Criamos um job, configuramos o Jenkins.

Como funciona essa combinação:

O Packer cria uma VM vazia e anexa o ISO.
A VM é inicializada, o Packer informa ao carregador para usar nosso arquivo kickstart a partir do disquete ou http.
O anaconda é iniciado com nossa configuração, efetuando a configuração inicial do sistema operacional.
O Packer aguarda a disponibilidade da VM.
O Packer dentro da VM executa o ansible em modo local.
O Ansible utiliza exatamente os mesmos papéis que no passo nº 1.
O Packer exporta o modelo de VM.

Dia nº 75: Refatorando acordos sem quebrar = Teste ansible + Testkitchen

Fixar acordos no código pode não ser suficiente. Afinal, se no fundo do processo você quiser mudar algo, pode acabar quebrando alguma coisa. Portanto, em infraestrutura, surge a necessidade de testar essa própria infraestrutura. Para sincronizar o conhecimento dentro da equipe, começamos a testar os papéis do Ansible. Não vou me aprofundar, pois há um artigo que descreve os eventos daquele momento. Teste-me se puder ou será que os programadores YML sonham em testar ansible?(spoiler: essa não foi a versão final e depois tudo ficou mais complicado. Como começar a testar Ansible, refatorar o projeto em um ano e não perder a cabeça.).

Dia nº 130: E se CentOS+ansible não for necessário? E se for openshift?

É importante entender que o processo de implementação da infraestrutura não foi o único, e houve subprojetos colaterais. Por exemplo, recebemos um pedido para rodar nosso aplicativo no openshift e isso se transformou em uma pesquisa que levou mais de uma semana. Estamos rodando o aplicativo no Openshift e comparando as ferramentas existentes. O que atrasou o processo de migração. O resultado foi que o openshift não atende todas as necessidades, é necessário ter hardware real ou, pelo menos, a possibilidade de brincar com o núcleo.

Dia nº 170: Openshift não é adequado, vamos arriscar com o Windows Azure Pack?

Hyper-V não é muito amigável, SCVMM não melhora muito a situação. Mas existe o Windows Azure Pack, que é uma camada sobre o SCVMM e imita o Azure. No entanto, na realidade, o produto parece abandonado: documentação com links quebrados e bastante escassa. Mas, no âmbito da pesquisa por opções de simplificar a vida de nossa nuvem, também o analisamos.

Dia nº 250: Windows Azure Pack não é muito bom. Permanecemos no SCVMM.

O Windows Azure Pack parecia promissor, mas decidimos não introduzir o WAP com suas complexidades no sistema apenas por recursos desnecessários e ficamos com o SCVMM.

Dia nº 360: Comendo um elefante por partes.

Somente após um ano a plataforma estava pronta para a migração e o processo de mudança começou. Para isso, definimos uma tarefa S.M.A.R.T. Listamos todas as VMs e começamos a resolver uma por uma a configuração, descrevendo-a no Ansible e cobrindo-a com testes.

Dia nº 450: Que sistema obtivemos?

O processo em si não é interessante. Ele é rotineiro e pode-se notar que a maioria das configurações era relativamente simples ou isomórficas, seguindo o princípio de Pareto, onde 80% das configurações no WM exigiram 20% do tempo. Da mesma forma, 80% do tempo foi dedicado à preparação da mudança, e apenas 20% à própria mudança.