El uso de Packer para crear imágenes terminadas (o casi terminadas) reduce drásticamente el tiempo que lleva implementar nuevas instancias y también le permite usar grupos de ajuste de escala automático.

Si tiene Terraform ejecutando un aprovisionador como Chef o Ansible en cada creación de instancias EC2, agrega un período de tiempo para que el aprovisionador se ejecute en el momento en que necesita implementar nuevas instancias. En mi opinión, es mucho mejor hacer la configuración por adelantado usando Packer para incorporar todo lo posible en la AMI y luego usar secuencias de comandos/herramientas de datos de usuario como Consul-Template para proporcionar diferencias específicas del entorno.

Packer ciertamente puede construir sobre imágenes y, de hecho, requiere que se especifique un source_ami . Recomiendo enfáticamente etiquetar sus AMI de una manera que le permita usar source_ami_filter en la fuente de aws_ami aws_ami de Packer y Terraform, de modo que cuando realice cambios en sus AMI, Packer y Terraform los extraerán automáticamente para construirlos o implementarlos en el Próxima oportunidad.

Personalmente, preparo una AMI "Base" razonablemente liviana que hace un refuerzo básico y configura el monitoreo y el registro que quiero para todas las instancias que se implementan y también se asegura de que Packer cifre el volumen raíz de la AMI. Todas las demás imágenes se crean a partir de la última AMI "Base" y no tiene que preocuparse por asegurarse de que esas cosas estén instaladas/configuradas o preocuparse por cifrar el volumen raíz.

Al integrar su configuración en la AMI, también puede avanzar hacia el modelo de infraestructura inmutable que tiene algunos beneficios importantes, ya que sabe que siempre puede desechar una instancia que tiene problemas y reemplazarla muy rápidamente por una nueva. Dependiendo de su nivel de madurez, incluso podría eliminar el acceso a las instancias para que ya no sea posible cambiar nada en la instancia una vez que se haya implementado, lo que, según mi experiencia, es un factor importante en los problemas operativos.

Muy ocasionalmente puede encontrarse con algo que dificulta mucho la creación de una AMI y, en esos casos, puede optar por ejecutar sus scripts de aprovisionamiento en un aprovisionador de Terraform cuando se está creando. A veces, simplemente es más fácil mover un proceso existente para usar aprovisionadores con Terraform que hornear las AMI, pero presionaría para mover las cosas a Packer cuando sea posible.

Me he encontrado con la misma situación. Según mi entendimiento

• Si abre sus instancias EC2 con mucha frecuencia, digamos 2 o 3 veces al día, cree una AMI personalizada con Packer y luego llame a la AMI a través de terraform.
• Si su imagen base (AMI creada por Packer) cambia con frecuencia según sus requisitos, entonces es bueno usar Packer. Pero para mí, ejecutar scripts de un empaquetador consume mucho tiempo.
• También puedes hacer lo mismo con Packer. Puede escribir sus requisitos en un script y llamarlo en terraform. Tener todo incorporado en un script de terraformación reduciría algo de tiempo

Finalmente, es su decisión y su frecuencia de abrir instancias EC2.