🥇Acelerando o Ansible

Não é nenhum segredo que com as configurações padrão o Ansible não consegue fazer seu trabalho muito rapidamente. No artigo apontarei vários motivos para isso e oferecerei um mínimo útil de configurações que, muito possivelmente, irão realmente aumentar a velocidade do seu projeto.

Aqui e abaixo discutimos o Ansible 2.9.x, que foi instalado em um virtualenv recém-criado da sua maneira favorita.

Após a instalação, crie um arquivo “ansible.cfg” próximo ao seu playbook - este local permitirá que você transfira essas configurações junto com o projeto, além de serem carregadas automaticamente.

Pipeline

Alguns já devem ter ouvido falar da necessidade de usar pipelining, ou seja, não copiar módulos para o sistema de arquivos do sistema de destino, mas transferir um arquivo zip envolto em Base64 diretamente para o stdin do interpretador Python, mas outros não, mas o fato permanece um fato: esta configuração ainda permanece subestimado. Infelizmente, algumas das distribuições populares do Linux usadas para configurar o sudo não são muito boas por padrão - de modo que este comando exigia um tty (terminal), então o Ansible deixou essa configuração muito útil desabilitada por padrão.

pipelining = True

Reunindo fatos

Você sabia que com as configurações padrão, o Ansible para cada jogada inicia a coleta de fatos para todos os hosts que dela participam? Em geral, se você não sabia, agora você sabe. Para evitar que isso aconteça, você precisa habilitar o modo de solicitação explícita para coleta de fatos (explícito) ou o modo inteligente. Nele, serão coletados fatos apenas daqueles anfitriões que não foram encontrados em jogadas anteriores.
Atualização. Ao copiar, você terá que selecionar uma dessas configurações.

gathering = smart|explicit

Reutilizando conexões ssh

Se você já executou o Ansible no modo de depuração (a opção “v”, repetida de uma a nove vezes), deve ter notado que conexões ssh são constantemente feitas e interrompidas. Portanto, há algumas sutilezas aqui também.

Você pode evitar a etapa de restabelecer uma conexão ssh em dois níveis ao mesmo tempo: diretamente no cliente ssh e ao transferir arquivos do gerenciador para o host gerenciado.
Para reutilizar uma conexão SSH aberta, basta passar as chaves necessárias para o cliente SSH. Em seguida, ele começará a fazer o seguinte: ao estabelecer uma conexão ssh pela primeira vez, criará adicionalmente um chamado soquete de controle, nas instalações subsequentes verificará a existência deste mesmo soquete e, se tiver sucesso, reutilizará o conexão ssh existente. E para que tudo isso faça sentido, vamos definir o tempo para manter a conexão quando inativa. Você pode ler mais em documentação ssh, e no contexto do Ansible simplesmente usamos “encaminhar” as 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 um host gerenciado, basta especificar outra configuração desconhecida, ssh_tranfer_method. A documentação sobre este assunto é extremamente caro e enganoso, porque esta opção funciona muito bem! Mas lendo Código fonte permite que você entenda exatamente o que acontecerá: o comando dd será lançado no host gerenciado, trabalhando diretamente com o arquivo desejado.

transfer_method = piped

Aliás, no ramo “desenvolver” essa configuração também existe não foi a lugar nenhum.

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

Outra configuração útil são os garfos. Ele determina o número de processos de trabalho que se conectarão simultaneamente aos hosts e executarão tarefas. Devido às peculiaridades do Python como linguagem, são usados processos, não threads, porque o Ansible ainda suporta Python 2.7 - nada de assíncrono para você, não faz sentido introduzir comportamento assíncrono aqui! Por padrão, o Ansible é executado cinco trabalhadores, mas se solicitado corretamente, lançará mais:

forks = 20

Apenas aviso desde já que aqui pode haver algumas dificuldades relacionadas à quantidade de memória disponível na máquina de controle. Em outras palavras, é claro que você pode definir forks=100500, mas quem disse que funcionaria?

Juntando tudo

Como resultado, para ansible.cfg (formato ini), as configurações necessárias podem ser 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 ocultar tudo em um inventário YaML normal de uma pessoa saudável, pode ser mais ou menos assim:

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

Infelizmente, isso não funcionará com as configurações “gathering = smart/explicit” e “forks = 20”: seus equivalentes em YaML não existem. Ou nós os definimos em ansible.cfg ou os passamos pelas variáveis de ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

Sobre Mitógeno
- Onde está isso sobre Mitógeno? - você tem o direito de perguntar, caro leitor. Em nenhum lugar deste artigo. Mas se você estiver realmente pronto para ler seu código e descobrir por que seu manual trava com o Mitogen, mas funciona bem com o vanilla Ansible, ou por que o mesmo manual estava funcionando bem antes, mas depois de uma atualização começou a fazer coisas estranhas - bem, Mitogen poderia ser potencialmente sua ferramenta. Aplique, entenda, escreva artigos - lerei com interesse.

Por que eu não uso pessoalmente o Mitogen? Porque gladíolo só funciona desde que as tarefas sejam realmente simples e esteja tudo bem. Porém, se você virar um pouco para a esquerda ou para a direita - é isso, chegamos: em resposta, um punhado de exceções indistintas voam até você e, para completar o quadro, só falta a frase comum “obrigado a todos , todos são livres.” Em geral, só não quero perder tempo descobrindo os motivos da próxima “batida subterrânea”.

Algumas dessas configurações foram descobertas durante o processo de leitura Código fonte plugin de conexão com o nome autoexplicativo “ssh.py”. Compartilho os resultados da leitura na esperança de que inspire outra pessoa a olhar as fontes, lê-las, verificar a implementação, comparar com a documentação - afinal, mais cedo ou mais tarde tudo isso lhe trará resultados positivos. Boa sorte!

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Quais das seguintes configurações do Ansible você usa para acelerar seus projetos?

69,6%pipeline=true32
34,8%reunião = inteligente/explícito16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%método_de_transferência = canalizado8
63,0%garfos = XXX29
6,5%Nada disso, apenas Mitogen3
8,7%Mitogen + anotarei qual dessas configurações4

46 usuários votaram. 21 usuário se absteve.

Quer mais informações sobre o Ansible?

78,3%sim, claro54
21,7%sim, eu só quero mais coisas hardcore!15
0,0%não, e não é necessário para nada0
0,0%não, é complicado!!!0

69 usuários votaram. 7 usuários se abstiveram.

Fonte: habr.com

Acelere o Ansible