Criação de imagens de máquina com Packer: builders, provisioners, validate e build

Objetivo

Escrever, validar e executar o build de um template do Packer que produz uma imagem de máquina sem embutir credenciais no próprio arquivo do template.

Pré-requisitos

A CLI packer instalada na máquina ou no runner de CI que vai executar o build; credenciais da plataforma de destino (chaves de API de nuvem, acesso ao hipervisor) disponíveis como variáveis de ambiente ou em um gerenciador de segredos, e não como valores literais no template.

Passos

1. Entenda os dois blocos fundamentais antes de escrever qualquer coisa. A referência de terminologia da HashiCorp descreve os builders como componentes "que são capazes de criar uma imagem de máquina para uma única plataforma", que leem a configuração e produzem o artefato, enquanto os provisioners "instalam e configuram software dentro de uma máquina em execução antes de ela ser transformada em um artefato estático". Scripts shell e ferramentas de configuração de terceiros são citados como exemplos de provisioners.
2. Declare credenciais e outros valores específicos do ambiente como variáveis de entrada, em vez de literais: um bloco variable "api_token" com type = string e sensitive = true em linhas separadas (o HCL não aceita argumentos separados por vírgula dentro de um bloco). Templates HCL aceitam o argumento sensitive em um bloco de variável, o que faz com que "os valores string dessa variável sejam ofuscados na saída do Packer" em logs e no console.
3. Forneça o valor real do segredo no momento do build, a partir do ambiente (PKR_VAR_api_token) ou de um argumento -var / -var-file alimentado por um gerenciador de segredos, nunca versionado no repositório do template.
4. Instale os plugins declarados no bloco packer { required_plugins { ... } } do template: packer init . (somente para templates HCL2; desde o Packer 1.10, os plugins oficiais não vêm mais incluídos). Depois execute packer validate . (ou aponte para um único arquivo .pkr.hcl). O comando "é usado para validar a sintaxe e a configuração de um template" e termina com código diferente de zero em caso de falha; execute-o no CI a cada alteração. A opção -syntax-only pula a verificação de configuração.
5. Execute o build: packer build .. O comando "recebe um template e executa todos os builds nele contidos" para gerar artefatos, em paralelo, a menos que seja limitado com -parallel-builds=N; -only= e -except= selecionam quais builds executar.
6. Armazene o identificador do artefato resultante (ID da AMI, nome da imagem etc.) como saída do build para a próxima etapa do pipeline e evite executar novamente os provisioners sobre um artefato já construído: trate cada build como a produção de uma imagem imutável.

Resultado esperado

O packer validate termina com código 0 e sem erros de template antes de se tentar um build real; o packer build produz um artefato de imagem versionado, sem nenhum valor de credencial visível na própria saída do console ou nos logs.

Limites e base de verificação

Marcar uma variável como sensitive impede que o Packer imprima o seu valor; isso não criptografa o valor na memória, em um arquivo de estado/cache que alguns plugins possam gravar, nem na saída do script de um provisioner, caso o próprio script exiba o valor. Os scripts dos provisioners precisam tratar segredos com cuidado por conta própria. O packer validate detecta erros de sintaxe e de configuração no nível do esquema, mas não falhas em tempo de execução, como uma plataforma de builder inacessível ou um script de provisioner que falha no SO de destino; só o packer build exercita esses casos. Se um provisioner falhar, o padrão -on-error=cleanup apaga a máquina temporária e os arquivos. Já -on-error=abort (ou escolher abort no prompt de ask) os mantém para depuração, e depois é preciso removê-los manualmente, inclusive instâncias de nuvem que continuam sendo cobradas. Em uma execução com vários builds, os que tiveram sucesso ainda produzem artefatos, portanto verifique quais existem.