¿Cómo manejan las personas que utilizan infraestructura inmutable los cambios de configuración entre sus diferentes entornos? No puedo encontrar una manera agradable de crear una AMI por rol y usarla en todos los entornos.
Lo que quiero decir es cómo construyo una única ami que pueda implementar en desarrollo, puesta en escena y producción, pero que apunte al ELB correcto, etc. para ese entorno. Por el momento, las únicas opciones que se me ocurren son:
- Cree una AMI por entorno por función (servidor web de producción, servidor de aplicaciones de producción, servidor web de prueba,...). Esto parece anular el propósito de II de enviar la misma imagen a todos los entornos.
- Cree una AMI casi completa y realice la configuración final después de iniciarla pero antes de agregarla al ELB. Esto parece estar cerca pero siento que falta algo.
¿Existe alguna forma de pasar un conjunto de parámetros a una AMI cuando se crea o algo más? ¿Cómo utilizan otros la infraestructura inmutable?
Gracias.
Respuesta1
EnCaja de fusiblesVivimos y respiramos una infraestructura inmutable. Recomendamos una combinación de los dos enfoques siguientes:
- Cree tanta configuración como sea posible para todos los entornos directamente en la AMI (y seleccione automáticamente el conjunto correcto en tiempo de ejecución)
- Pasar las configuraciones restantes como una instanciadatos del usuarioscript de shell (cloud-init) que exporta entornos con los valores que necesita para esa máquina/entorno