¿Por qué la gente usa Puppet / Chef con Amazon Cloud Formation en lugar de solo usar CloudInit?

Estamos planeando utilizar instancias AMI EC2 que no están "prefabricadas". Es decir, cuando se activan, son instalaciones simples de AWS Linux. Nuestro proceso de arranque extraerá las diversas instalaciones que necesitamos, por ejemplo, python, tomcat. Tendremos un mínimo de 3 instancias y un máximo de 8.

Dados estos requisitos, ¿sería útil usar Puppet / Chef en lugar de usar Amazon Cloud Formation (CloudInit)?

Lo mejor que puedo ver es que si usáramos Puppet, tendríamos programación declarativa que es más fácil de auditar para ver qué está sucediendo en comparación con un script. Además, CloudInit tiene un límite de tamaño de script de 16k con el que podemos o no encontrarnos.

¿Alguien se ha movido de CloudInit a Puppet o Chef por una razón específica que pueda proporcionar aquí en respuesta a mi pregunta?

¿Existe alguna ventaja sobre CloudInit? ¡Sí, absolutamente, muchos de ellos!

Claro, puede escribir de arriba a abajo ejecutar una vez los scripts de CloudInit para aprovisionar un servidor. Pero, ¿qué sucede cuando necesita cambiar un archivo de configuración, agregar un usuario, actualizar un paquete o instalar un nuevo paquete? Terminará iniciando sesión en servidores o escribiendo scripts para hacerlo, e inevitablemente un estado incongruente de los servidores.

CloudInit no es gestión de configuración. Si opta por comenzar a usar el software de administración de configuración, use el inicio en la nube para una sola tarea: arrancar el Puppet / Chef / otro agente.

Puppet no solo lo ayuda a automatizar la instalación de paquetes, configurar claves ssh o ajustar su montón de Tomcat. Asegura el estado de las cosas. Cuando un desarrollador está solucionando un problema de una aplicación Java a las 3 am y cambia su configuración de Tomcat, Puppet la volverá a cambiar. Puede cambiar rápidamente la versión de Python para todos o grupos de nodos, y si alguien instala una versión diferente, Puppet la volverá a cambiar.

Cuando su pila de aplicaciones cambia y comienza a usar, digamos RabbitMQ, Jetty o un nuevo RDBMS, puede probar e implementar fácilmente los cambios en decenas o miles de servidores.

Hay muchas otras razones para utilizar software de gestión de la configuración, como informes de back-end, auditoría y cumplimiento de la seguridad.

El objetivo de la gestión de la configuración es poner en marcha las máquinas de forma predecible y coherente. CloudFormation y cloudinit son excelentes cuando está limitado exclusivamente a AWS (aunque depurar las plantillas de CloudFormation es una experiencia miserable ), pero ¿qué pasa con las aplicaciones que usan tanto recursos del centro de datos como AWS, o entornos de prueba locales o máquinas de desarrollo?

Si existe exclusivamente en AWS, supongo que podría salirse con la suya con cloudinit y nada más, pero no estoy convencido de que sea realista para aplicaciones de cualquier escala (Netflix, por ejemplo, hornea previamente sus AMI utilizando tecnologías OSS que han escrito y lanzado al mundo; considere este video para más detalles). Las aplicaciones de alta disponibilidad son transregionales, a menudo basadas en VPC, tienden a realizar copias de seguridad en centros de datos a través de VPN, y esto ni siquiera afecta a los entornos de demostración, preparación, prueba o desarrollo. Como alguien encargado de aprovisionar máquinas, lo último que quiero hacer es repetir el trabajo o quedarme atascado en la depuración de varios métodos de aprovisionamiento.

De ahí Chef o Puppet. Funcionan tan bien para AWS como para mi centro de datos, y tanto para mi máquina de desarrollo que ejecuta Vagrant como para los entornos de demostración que ocasionalmente necesito sobre la marcha. Prefiero lanzar Chef o Puppet desde cloudinit que mantener tanto cloudinit como Chef o Puppet.

Para los servidores desechables, digamos que se ejecuta detrás de un grupo de autoescalado, yo diría que cloudinit es probablemente suficiente. Las secuencias de comandos de shell de Linux o las secuencias de comandos de Windows PowerShell deberían funcionar.

Si es un servidor de larga duración que planea administrar, tal vez un chef, un títere o un estibador podrían brindarle una ventaja como se menciona en la respuesta aceptada. Si no puede ver la ventaja después de usarlos, probablemente no necesite la herramienta.

En mi experiencia, hay cosas simples que se pueden hacer fácilmente con las herramientas GUI listas para usar que ofrece AWS, pero a medida que se adentra en cosas más complejas, comienza a descubrir que existen limitaciones en lo que puede hacer con solo sus herramientas.

En ese punto, puede detenerse o puede encontrar otras herramientas (como Chef o Puppet) que pueden ayudarlo a lograr esos objetivos más complejos, así como a hacer las cosas más simples.

Tu elección.