Reproduções recuperáveis Ansible [por exemplo com site.retry]?

Question

O uso do ansible geralmente depende de uma propriedade chamada "idempotência". Se você aplicar uma função pela segunda vez, espera-se que tenha o mesmo resultado. Por exemplo. ele não adicionará uma segunda cópia da mesma linha em um arquivo de configuração.

Existe outra propriedade que você pode chamar de "resumable". No caso de uma partição de rede entre o controlador e o alvo, uma reprodução interrompida pode ser executada novamente quando a partição for resolvida?

Ansible sugestões para essa propriedade, listando os destinos com falha & permitindo que eles sejam revividos.

No entanto, se você analisar os exemplos práticos, eles não parecem manter essa propriedade. Sugira uma abordagem que garanta que reconheço quaisquer falhas de minhas apostilas para retomar corretamente.

- name: Create Mysql configuration file
  template: src=my.cnf.j2 dest=/etc/my.cnf
  notify:
  - restart mysql

- name: Start Mysql Service
  service: name=mysqld state=started enabled=yes

Por exemplo o trecho acima dos ansible-examples, não consegue a propriedade "resumable". O manipulador "restart mysql" nunca será acionado, se a reprodução for interrompida após a criação do arquivo de configuração, mas antes de executar o manipulador "restart mysql".

    

Answer 1

Os documentos ansible mencionam isso, mas apenas de passagem. "Certos erros ainda podem impedir que o manipulador seja executado, como um host se tornando inacessível." Não há sugestões sobre o que fazer neste caso.

Ele menciona --force-handlers . Há alguma confusão aqui. O problema # 4777 solicita uma opção --force-handlers que executaria todos os manipuladores, independentemente de terem sido notificados, para permitir recuperação nesta situação. Esta questão foi encerrada com o comentário "isto está agora implementado". Narrador: não foi implementado. Eu abri um novo problema para solicitar esse recurso.

Infelizmente, acredito que este comentário tenha feito alguns sugerirem --force-handlers como a solução para esse problema em stackexchange ou em outro lugar, quando não é.

Uma solução completa pode ser modificada para gravar um banco de dados de manipuladores pendentes. (O manipulador seria registrado imediatamente quando uma tarefa detectar uma mudança prestes a ser feita).

Além disso, você gostaria de evitar essas interrupções. Porque você precisaria revisar cuidadosamente ambos os manipuladores e todas as tarefas condicionais em |changed e certificar-se de executar todas elas nos destinos repetidos.

Moral: pode ser útil usar manipuladores e evitar a aspersão de |changed em todo o manual.

Uma solução menos elegante, mas igualmente correta, envolve a modificação do ansible com uma opção para forçar a execução de todos os manipuladores. Ou talvez para tratar todas as tarefas não ignoradas, conforme alterado. Se a execução original precisou reiniciar o serviço, não é completamente irracional agendar uma segunda execução que reinicia o serviço. A desvantagem é que a execução original só precisava reiniciar alguns serviços.

Você também pode evitar jogadas interrompidas usando o ansible "pull mode". Ou, se a principal preocupação é porque o ansible é executado remotamente, você pode executar ansible em um servidor no mesmo site, usando uma sessão persistente com screen / tmux .

    

Answer 2

Em princípio, as execuções recuperáveis podem ser implementadas tocando em um arquivo de registro de data e hora após a reinicialização do serviço. Em seguida, a condição para reiniciar o serviço é se o carimbo de data / hora de reinicialização é anterior à hora de modificação do arquivo de configuração. (Inspirado por make ).

No caso de arquivos de configuração, isso também é possível usando módulos ansible nativos:

- name: Create Mysql configuration file
  template: src=my.cnf.j2 dest=/etc/my.cnf

- name: query  | mysql has been restarted with new config file
  template: src=my.cnf.j2 dest=/ansible-managed/mysql/restarted/my.cnf
  check_mode: yes
  register: mysql_restarted

- name: ensure | mysql has been restarted with new config file
  service: name=mysqld state=restarted
  when: mysql_restarted|changed    

- name: record | mysql has been restarted with new config file
  template: src=my.cnf.j2 dest=/ansible-managed/mysql/restarted/my.cnf

(ou por exemplo,

- name: query  | mysql has been restarted with new config file
  copy: remote_src=yes src=/etc/my.cnf dest=/ansible-managed/mysql/restarted/my.cnf
  check_mode: yes
  register: mysql_restarted

embora remote_src apenas funcione com arquivos de configuração individuais, não com diretórios