APRENDER. PRATICAR. EVOLUIR.Extração não é espelhamento
Uma release de um worker contém payload.txt. A diretoria de destino também contém obsolete.txt de uma versão anterior. Depois de extrair o ZIP, o ficheiro extra continua presente. O objetivo de unarchive é extrair; não se deve concluir que a diretoria corresponde exatamente ao conjunto aprovado. Este detalhe torna-se operacionalmente importante se a aplicação carregar automaticamente plugins ou scripts de uma pasta. Define se o contrato permite ficheiros adicionais. Se exigir um conjunto exato, planeia uma diretoria de release nova e valida o manifesto antes da troca controlada do apontador.
Executar o caso e observar resíduos
O runner cria um ZIP local com release-one e prepara obsolete.txt nos dois destinos. archive.yml cria explicitamente a diretoria, porque a extração depende dela. remote_src: true refere-se ao ZIP já presente na máquina onde o módulo executa. Como ambos os aliases são locais, o caminho do ZIP é acessível aos dois; em SSH, isso teria de ser garantido em cada nó. Depois da extração, o runner confirma tanto o payload novo como a permanência do ficheiro residual. A repetição do mesmo ZIP mede o comportamento real da ferramenta disponível neste ambiente.
O marcador que oculta uma atualização
O segundo ensaio cria ready, altera o ZIP para release-two e ativa creates. A tarefa é suprimida pela presença do marcador e o payload continua em release-one. Não há contradição: o marcador exprime uma condição de existência, não o hash da versão desejada. Um marcador útil deve estar associado à versão e só surgir depois da aceitação que representa. Mesmo assim, é necessário decidir como detetar drift posterior. Neste exercício, desativar o marcador permite instalar release-two, mas não apaga obsolete.txt. Resolver uma condição não resolve automaticamente a outra.
Do exemplo à mudança operacional
Para um artefacto obtido fora do laboratório, regista a proveniência e o digest aprovado por uma fonte confiável. Comparar dois hashes obtidos do mesmo canal comprometido só confirma consistência entre esses valores. Confirma a integridade antes de extrair e inspeciona o conjunto esperado depois. No plano de mudança, distingue o rollback do apontador da reversão de dados persistentes: um worker antigo pode não entender dados já migrados. O laboratório usa apenas texto sintético e não demonstra download autenticado, assinatura, migração de dados nem troca de tráfego.
- name: Inspect archive extraction semantics
hosts: workers
gather_facts: false
vars:
target_dir: "{{ lab_root }}/{{ inventory_hostname }}/release"
tasks:
- name: Create extraction directory explicitly
ansible.builtin.file:
path: "{{ target_dir }}"
state: directory
mode: '0700'
- name: Extract supplied local zip fixture
ansible.builtin.unarchive:
src: "{{ bundle_path }}"
dest: "{{ target_dir }}"
remote_src: true
creates: "{{ (target_dir ~ '/ready') if use_marker else omit }}"
ready existe e o ZIP mudou; creates conserva release-one. Retirar o bloqueio instala release-two, mantendo obsolete.txt.
Armadilhas comuns
Tratar extração como limpeza; marcador sem versão; remote_src como prova de distribuição.
Tópicos relacionados: Ensaio executável: âmbito, estado e limites · Configuração validada e ativação observável · Recuperação e resultado da mudança
Valida a versão, o conjunto de ficheiros e o resultado funcional separadamente.
Referência: Unarchive module · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned