Gerenciamento de configuração versus image baking: onde idempotência e drift decidem

O que é

Ferramentas de gerenciamento de configuração como Puppet, Salt e Ansible descrevem de forma declarativa o estado desejado de um sistema e, a cada execução, fazem o sistema real convergir para esse estado. A documentação do Puppet nomeia essa propriedade diretamente: "A key feature of Puppet is idempotency — the ability to repeatedly apply code to guarantee a desired state on a system, with the assurance that you will get the same result every time." (Uma característica essencial do Puppet é a idempotência: a capacidade de aplicar o código repetidamente para garantir um estado desejado no sistema, com a certeza de obter sempre o mesmo resultado.) O glossário do Salt define uma ação idempotente da mesma forma: aquela que "ensures the system is in a well-known state regardless of the system's state before the action is applied" (garante que o sistema fique em um estado bem conhecido, independentemente do estado em que estava antes da ação), de modo que "applying the action multiple times results in no changes to the system" (aplicar a ação várias vezes não resulta em nenhuma mudança no sistema) quando ele já convergiu. A documentação do Ansible observa que suas tarefas "achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state." (alcançam uma forma de idempotência ao verificar o estado atual antes de começar e não fazer nada, a menos que o estado atual seja diferente do estado final especificado.)

Image baking (Packer e ferramentas semelhantes) adota uma abordagem diferente: software e configuração são instalados uma única vez, no momento do build, e o resultado é capturado como um artefato imutável. Uma instância iniciada a partir dessa imagem não executa de novo a lógica de configuração; ela simplesmente é o estado que foi embutido na imagem.

Por que importa

O gerenciamento de configuração idempotente pode rodar continuamente (em um agendamento ou a cada boot) e corrigir o drift, como um arquivo modificado fora do fluxo previsto ou um serviço que foi desativado, reaplicando a mesma declaração. O image baking não consegue corrigir de forma alguma o drift depois do boot: quando uma instância se afasta da sua imagem (por uma alteração manual ou um conserto improvisado), nada a traz de volta, a não ser substituí-la por uma instância nova criada a partir da imagem. O baking troca a capacidade de autocorreção por um boot mais rápido e previsível (sem necessidade de executar configuração) e por uma janela menor em que uma configuração incorreta ou um passo idempotente que falhou pode deixar um host parcialmente convergido.

Como aplicar

• Embuta na imagem o que raramente muda e precisa estar presente desde o primeiro segundo do boot: o sistema operacional base, as correções de segurança vigentes no momento do build e os agentes que já precisam estar em execução.
• Configure no boot (ou continuamente) o que muda por ambiente ou por instância: hostnames, segredos obtidos de um vault, feature flags, ou seja, tudo o que precisa refletir o estado desejado atual, e não o estado do último build da imagem.
• Combine as duas abordagens de forma deliberada: uma "golden image" que ainda executa uma ferramenta de gerenciamento de configuração no primeiro boot para a última etapa, específica do ambiente, com um registro explícito de qual camada é responsável por cada configuração.
• Trate passos não idempotentes (um recurso do tipo exec, um provisioner de shell puro) como um risco em qualquer das abordagens, e torne-os idempotentes de forma explícita (verificando antes um marcador) em vez de presumir que uma única execução é segura.

Armadilhas

• Tomar "funcionou da última vez" como prova de idempotência; um recurso pode parecer idempotente nos testes e ainda assim alterar um sistema que parte de um estado inicial diferente.
• Refazer o baking da imagem a cada deploy, e não apenas quando o conteúdo embutido realmente muda, o que transforma uma estratégia de boot rápido em uma lenta, sem o benefício de correção de drift que qualquer das abordagens deveria oferecer.
• Misturar a responsabilidade de build e a de boot sobre a mesma configuração, de modo que dois sistemas disputem esse valor a cada execução de convergência.