Recuperação e resultado da mudança | RHCE in Ansible: automação e operação

Recuperar não é aprovar

Numa janela noturna, o novo worker arranca mas produz um resultado de reconciliação incompatível com o critério de aceitação. A equipa consegue voltar à configuração anterior. Há agora duas conclusões: a recuperação pode ter sido bem-sucedida e a release continua rejeitada. Se a recuperação terminar num rescue bem-sucedido sem outro sinal, um consumidor que olha apenas para o código de saída pode interpretar a execução como mudança aceite. Define antecipadamente o contrato com o pipeline e com o gestor do incidente. Neste laboratório, uma tarefa fail após o restauro mantém o resultado global de rejeição.

Ler, alterar, falhar e restaurar

recovery.yml lê os bytes antigos com slurp, escreve uma configuração sintética diferente e injeta uma falha de aceitação. O rescue usa o conteúdo guardado para repor o ficheiro com modo 0600. A tarefa seguinte mantém o erro de release. O always grava que o caminho de recuperação foi visitado. O runner exige código de saída 2, compara os bytes finais com os iniciais e procura esse registo nos dois workers. Este conjunto de verificações evita chamar sucesso à simples presença de uma mensagem de rollback.

O que o mecanismo não resolve

Uma máquina inacessível não é equivalente a uma tarefa que devolve failed. Um erro de definição do playbook também pode impedir o fluxo esperado. Por isso, não uses always como promessa de registo em qualquer circunstância. Planeia evidência externa de execução e escalonamento quando o nó deixa de responder. O conteúdo guardado por slurp existe apenas nesta execução; para recuperação depois da perda do controlador, seriam necessários artefactos e procedimentos persistentes apropriados. Se o restauro falhar, a mensagem final deve manter essa incerteza, sem anunciar que o serviço está saudável.

Critério para devolver à operação

No exemplo, os hashes iguais provam a reposição dos ficheiros sintéticos. Não provam que um processo releu a configuração, que as filas foram reconciliadas ou que uma transação externa foi revertida. Numa aplicação real, acrescenta sondas específicas e um responsável pela decisão de reabrir tráfego. Regista versão antes e depois, falha inicial, ações executadas e riscos residuais. Um relatório útil permite distinguir mudança rejeitada com serviço recuperado, mudança rejeitada com recuperação parcial e estado desconhecido. Estas distinções ajudam APS e gestão de projeto a comunicar o mesmo resultado.

- name: Restore a local configuration but reject the release
  hosts: workers
  gather_facts: false
  vars:
    node_dir: "{{ lab_root }}/{{ inventory_hostname }}"
  tasks:
    - name: Read known previous bytes
      ansible.builtin.slurp:
        src: "{{ node_dir }}/worker.conf"
      register: previous
    - name: Exercise an unsuccessful rollout
      block:
        - name: Simulate accepted syntax but failed business behavior
          ansible.builtin.copy:
            content: "worker={{ inventory_hostname }}\nport=9443\n"
            dest: "{{ node_dir }}/worker.conf"
            mode: '0600'
        - name: Inject a synthetic acceptance failure
          ansible.builtin.fail:
            msg: Synthetic batch acceptance failed
      rescue:
        - name: Restore the previous configuration bytes
          ansible.builtin.copy:
            content: "{{ previous.content | b64decode }}"
            dest: "{{ node_dir }}/worker.conf"
            mode: '0600'
        - name: Keep the release gate failed after recovery
          ansible.builtin.fail:
            msg: Configuration restored; release still rejected
      always:
        - name: Record that recovery was attempted
          ansible.builtin.copy:
            content: "recovery-path-visited\n"
            dest: "{{ node_dir }}/recovery.log"
            mode: '0600'

NA PRÁTICA

O ficheiro volta a 8443 e a execução termina com erro: recuperação do ficheiro e rejeição da release são resultados compatíveis.

Armadilhas comuns

Rescue como aceitação; always como garantia universal; hash de configuração como sonda de negócio.

Tópicos relacionados: Ensaio executável: âmbito, estado e limites · Configuração validada e ativação observável · Arquivos, ficheiros residuais e marcadores

Leva esta ideia contigo

Mede a recuperação e preserva o resultado da mudança no contrato de execução.

Criar conta

Referência: Block error handling · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned