Creación de imágenes de máquina con Packer: builders, provisioners, validate y build

Objetivo

Escribir, validar y ejecutar una plantilla de Packer que genere una imagen de máquina sin incrustar credenciales en el propio archivo de la plantilla.

Requisitos previos

La CLI packer instalada en la máquina o en el runner de CI que ejecutará la compilación; credenciales de la plataforma de destino (claves de API de la nube, acceso al hipervisor) disponibles como variables de entorno o en un gestor de secretos, no como valores literales en la plantilla.

Pasos

1. Antes de escribir nada, conviene entender los dos bloques fundamentales. La referencia de terminología de HashiCorp describe los builders como componentes "that are able to create a machine image for a single platform" (capaces de crear una imagen de máquina para una única plataforma), que leen la configuración y producen el artefacto, mientras que los provisioners "install and configure software within a running machine prior to that machine being turned into a static artifact" (instalan y configuran software dentro de una máquina en ejecución antes de convertirla en un artefacto estático). Como ejemplos de provisioners se mencionan los scripts de shell y las herramientas de configuración de terceros.
2. Declara las credenciales y otros valores que dependen del entorno como variables de entrada, en lugar de literales: un bloque variable "api_token" con type = string y sensitive = true en líneas separadas (HCL no admite argumentos separados por comas dentro de un bloque). Las plantillas HCL admiten el argumento sensitive en un bloque de variable, lo que hace que "string-values from that variable to be obfuscated from Packer's output" (los valores de cadena de esa variable se oculten en la salida de Packer) en los logs y en la consola.
3. Proporciona el valor real del secreto en el momento de la compilación, a partir del entorno (PKR_VAR_api_token) o mediante un argumento -var / -var-file respaldado por un gestor de secretos, y nunca lo incluyas en el repositorio de la plantilla.
4. Instala los plugins declarados en el bloque packer { required_plugins { ... } } de la plantilla con packer init . (solo para plantillas HCL2; desde Packer 1.10 los plugins oficiales ya no vienen incluidos). Después ejecuta packer validate . (o sobre un único archivo .pkr.hcl). El comando "is used to validate the syntax and configuration of a template" (sirve para validar la sintaxis y la configuración de una plantilla) y termina con un código distinto de cero si falla; ejecútalo en CI con cada cambio. -syntax-only omite la comprobación de la configuración.
5. Ejecuta la compilación: packer build .. El comando "takes a template and runs all the builds within it" (toma una plantilla y ejecuta todas las compilaciones que contiene) para generar artefactos, en paralelo salvo que se limite con -parallel-builds=N; -only= y -except= permiten seleccionar compilaciones.
6. Guarda el identificador del artefacto resultante (ID de AMI, nombre de la imagen, etc.) como salida de la compilación para la siguiente etapa del pipeline, y evita volver a ejecutar los provisioners sobre un artefacto ya construido: trata cada compilación como si produjera una imagen inmutable.

Resultado esperado

packer validate termina con código 0 y sin errores de plantilla antes de intentar una compilación real; packer build produce un artefacto de imagen versionado sin que ningún valor de credencial sea visible en su propia salida de consola ni en sus logs.

Límites y base de verificación

Marcar una variable como sensitive impide que Packer imprima su valor, pero no lo cifra en memoria, ni en un archivo de estado o de cache que algunos plugins puedan escribir, ni en la salida del script de un provisioner si ese script muestra el valor por sí mismo; los scripts de los provisioners deben manejar los secretos con cuidado por su cuenta. packer validate detecta errores de sintaxis y de configuración a nivel de esquema, pero no fallos en tiempo de ejecución, como una plataforma de builder inaccesible o un script de provisioner que falla en el sistema operativo de destino; solo packer build pone a prueba esos casos. Si un provisioner falla, el valor predeterminado -on-error=cleanup elimina la máquina y los archivos temporales. -on-error=abort (o elegir abort en el prompt de ask) los conserva para depuración, y después tendrás que eliminarlos tú mismo, incluidas las instancias en la nube que se sigan facturando. En una ejecución con varias compilaciones, las que terminaron correctamente siguen produciendo artefactos, así que comprueba cuáles existen.