🥇Acelerando o Ansible

Não é segredo para ninguém que com as configurações padrão o Ansible pode não fazer seu trabalho tão rapidamente. Neste artigo, apontarei algumas razões para isso e oferecerei um conjunto mínimo de configurações que, possivelmente, podem realmente aumentar a velocidade do seu projeto.

Discutimos aqui e adiante o Ansible 2.9.x, que foi instalado em um virtualenv recém-criado da sua maneira preferida.

Após a instalação, criamos ao lado do seu playbook o arquivo "ansible.cfg" — essa localização permitirá que as configurações sejam transferidas junto com o projeto, além de serem carregadas automaticamente.

Pipelining

Sobre a necessidade de usar pipelining, ou seja, não copiar módulos para o sistema de arquivos do sistema alvo, mas sim transmitir um arquivo zip encapsulado em Base64 diretamente para o stdin do interpretador Python, algumas pessoas já podem ter ouvido, enquanto outras não, mas o fato é que: essa configuração ainda é subestimada. Infelizmente, alguma das distribuições Linux populares configurava o sudo anteriormente de uma forma não muito adequada — de modo que esse comando exigia a presença de um tty (terminal), e portanto, o Ansible deixou essa configuração muito útil desativada por padrão.

pipelining = True

Coleta de Fatos

Você sabia que, com as configurações padrão, o Ansible inicia a coleta de fatos para cada play em todos os hosts envolvidos? Em resumo, se você não sabia, agora sabe. Para evitar que isso ocorra, é necessário ativar o modo de solicitação explícita para coleta de fatos (explicit) ou o modo inteligente. Neste modo, os fatos serão coletados apenas dos hosts que não foram encontrados em plays anteriores.
UPD. Ao copiar, você precisará escolher uma dessas configurações.

gathering = smart|explicit

Reutilização de Conexões SSH

Se você já executou o Ansible no modo de saída de depuração (opção "v", repetida de uma a nove vezes), pode ter notado que as conexões SSH são constantemente estabelecidas e desconectadas. Pois bem, aqui também existem algumas sutilezas.

Evitar a etapa de reinstalação da conexão SSH pode ser feito em dois níveis simultaneamente: tanto diretamente no cliente SSH quanto ao transferir arquivos para o host gerenciado a partir do controlador.
Para reutilizar uma conexão SSH aberta, basta passar as chaves necessárias para o cliente SSH. Ele começará a fazer o seguinte: na primeira instalação da conexão SSH, criará um chamado control socket; nas conexões subsequentes, verificará a existência desse socket e, se for bem-sucedido, reutilizará a conexão SSH existente. E para que tudo isso faça sentido, vamos definir um tempo de manutenção da conexão em caso de inatividade. Você pode ler mais em a documentação do SSH, e no contexto do Ansible, utilizamos simplesmente o "encaminhamento" das opções necessárias para o cliente SSH.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

Para reutilizar uma conexão SSH já aberta ao transferir arquivos para o host gerenciado, basta indicar mais uma configuração desconhecida ssh_transfer_method. A documentação sobre isso é extremamente escassa e pode ser confusa, pois essa opção é totalmente funcional! Mas a leitura do código-fonte permite entender o que realmente acontecerá: no host gerenciado, o comando dd será executado, trabalhando diretamente com o arquivo necessário.

transfer_method = piped

Por sinal, na branch "develop" essa configuração também existe e não foi removida.

Não tenha medo da faca, tenha medo do garfo

Outra configuração útil é forks. Ela determina o número de processos de trabalho que se conectarão simultaneamente aos hosts e executarão as tarefas. Devido às características do Python como linguagem de programação, são usados processos e não threads, porque o Ansible ainda suporta Python 2.7 — nada de asyncio, não há necessidade de trazer assíncronas aqui! Por padrão, o Ansible inicia cinco trabalhadores, mas se solicitado corretamente, pode iniciar mais:

forks = 20

Apenas aviso que podem surgir algumas dificuldades relacionadas à quantidade de memória disponível na máquina controladora. Em outras palavras, definir forks=100500 é, claro, possível, mas quem disse que funcionará?

Vamos juntar tudo

No final, para o ansible.cfg (formato ini), as configurações necessárias podem ficar assim:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

E se você quiser esconder tudo em um inventory YAML saudável, ele pode se parecer com isso:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Infelizmente, com as configurações «gathering = smart/explicit» e «forks = 20», isso não vai funcionar: não existem equivalentes em YaML. Ou as definimos em ansible.cfg, ou as passamos através das variáveis de ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

Sobre o Mitogen
— E onde está escrito sobre o Mitogen? — você pode perguntar, prezado leitor. Neste artigo — em lugar algum. Mas se você realmente está disposto a ler seu código e entender por que seu playbook falha com Mitogen, enquanto funciona normalmente com o Ansible padrão, ou por que esse mesmo playbook funcionava até agora e, após a atualização, começou a apresentar comportamentos estranhos — bem, o Mitogen pode ser potencialmente sua ferramenta. Aplique, investigue, escreva artigos — vou ler com interesse.

Por que eu pessoalmente não utilizo o Mitogen? Porque ele funciona somente enquanto as tarefas são realmente simples e tudo corre bem. No entanto, assim que você desvia um pouco à esquerda ou à direita — acabou: em resposta, você recebe uma enxurrada de exceções confusas, e para completar a cena, só falta a frase clichê «obrigado a todos, estão liberados». Em suma, eu simplesmente não quero perder tempo tentando descobrir a causa de mais um «estrondo subterrâneo».

Parte dessas configurações foram descobertas durante a leitura código-fonte do plugin de conexão chamado «ssh.py». Compartilho os resultados da leitura na esperança de que isso inspire mais alguém a olhar para o código-fonte, lê-lo, verificar a implementação, comparar com a documentação — pois tudo isso, mais cedo ou mais tarde, trará seus resultados positivos. Boa sorte!

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.