APRENDER. PRATICAR. EVOLUIR.1. Definir a observação necessária à decisão
Um playbook fictício escolhe um caminho de deployment com base numa versão guardada no cache. O valor existe e é um texto válido, mas isso não demonstra que corresponde ao software instalado agora. Distingue valor declarado, observação recolhida e requisito pretendido. Para decidir uma mudança, regista o host, o método de recolha, o instante e a versão de configuração relevante. A variável pode continuar correta ou ter ficado desatualizada após uma intervenção manual. Não resolvas a dúvida substituindo silenciosamente a ausência por um valor que permite avançar. Define quando é necessário recolher evidência nova, quando uma observação anterior é aceitável e que condições invalidam essa aceitação. O laboratório usa marcadores de release sintéticos para tornar estas diferenças visíveis.
2. Observar as duas cópias de set_fact
O exercício atribui retained_value com cacheable: true. Na execução em que o valor é definido, observa-se tanto a variável do host como a entrada em ansible_facts. Depois atribui release-8 e executa clear_facts. O relatório ainda encontra release-8 pela variável do host, mas já não encontra a entrada em ansible_facts. Este resultado não significa que a limpeza falhou: foram observadas duas representações com comportamento diferente. Também não autoriza dizer que todos os segredos desapareceram da memória. Usa nomes e acessos explícitos ao diagnosticar o resultado, e evita criar condições que assumem que limpar facts remove qualquer variável com o mesmo nome. No handover, mostra a comparação entre as duas referências e explica em que execução cada uma foi observada.
3. Demonstrar persistência entre processos
Uma variável lida numa tarefa posterior do mesmo playbook não prova persistência para a próxima execução. O laboratório termina o processo que escreveu os valores e inicia outro processo para os ler. Com jsonfile configurado numa diretoria temporária, o segundo processo encontra release-7 sem o definir de novo. Depois da limpeza, um novo processo observa ausência. Um ensaio separado usa o plugin memory: cacheable continua presente na tarefa, mas o processo seguinte não recupera o valor. Assim, a experiência compara uma configuração concreta de cache, sem assumir que o parâmetro ativa sozinho armazenamento persistente. Regista o plugin e a sua configuração efetiva. Uma política de cache da plataforma pode diferir da configuração local usada na preparação do playbook.
4. Relacionar validade, âmbito e exposição
Um TTL controla quando uma entrada deixa de ser elegível para utilização pelo cache; não transforma uma observação antiga numa medição atual. Uma mudança de endereço, versão ou pertença a um cluster pode ocorrer antes do fim desse intervalo. Para operações críticas, escolhe uma recolha ou validação adequada à decisão e não apenas um TTL maior. A disponibilidade de hostvars também não prova que os facts desse host foram recolhidos. Distingue variáveis de inventário dos dados obtidos por recolha ou cache. Ao guardar resultados, minimiza informação sensível, controla acesso e define retenção. O exemplo só guarda marcadores sintéticos; não demonstra proteção de credenciais nem deve ser adaptado para colocar passwords num ficheiro de cache sem um desenho próprio de segurança.
5. Preparar um diagnóstico reproduzível
Quando duas execuções divergem, conserva uma descrição suficiente para reproduzir o contexto: versão de Ansible, inventário selecionado, configuração, extra vars relevantes e fontes dos valores. No laboratório, cada processo deixa um código de saída, recap e hash da saída, além dos resultados que sustentam cada asserção. Não se publicam credenciais ou dados de negócio. Para investigar um valor inesperado, começa por localizar a representação consultada e a ordem em que foi escrita, limpa ou sobrescrita. Repete a recolha necessária numa cópia autorizada do ambiente e confirma a condição final antes de retomar. Um teste local em macOS demonstra o comportamento exercitado de Ansible 2.16.14; não valida ligação SSH, privilégios, reboot, serviços RHEL ou um ambiente AAP real.
# Local teaching example. Run: ansible-playbook facts.yml
# This snippet observes same-run copies, not cross-process persistence.
---
- hosts: localhost
connection: local
gather_facts: false
tasks:
- name: Create two representations
ansible.builtin.set_fact:
retained_value: release-8
cacheable: true
- name: Observe before clearing
ansible.builtin.debug:
msg:
host_value: "{{ retained_value }}"
fact_value: "{{ ansible_facts.retained_value }}"
- name: Clear facts
ansible.builtin.meta: clear_facts
- name: Observe the remaining host variable
ansible.builtin.debug:
msg:
host_value: "{{ retained_value }}"
fact_exists: "{{ 'retained_value' in ansible_facts }}"
# Expected: host_value remains release-8; fact_exists is false.
# The full lab compares jsonfile and memory in separate playbook processes.
Depois de clear_facts, a variável do host conserva release-8 na mesma execução; o processo seguinte já não encontra o valor no cache limpo.
Armadilhas comuns
Variável existente como observação recente; cacheable como persistência automática; clear_facts como remoção de todas as variáveis; TTL como prova de validade.
Tópicos relacionados: Delegação, lotes e efeitos partilhados
Explica de onde veio o valor, a quem pertence e até quando sustenta a decisão pretendida.
Referência: set_fact copies and cacheable behavior · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned