¿Por qué las personas usan Puppet/Chef con Amazon Cloud Formation en lugar de solo usar CloudInit?
Estamos planeando usar instancias AMI EC2 que no estén "pre-horneadas". Es decir, cuando se giran, son instalaciones simples de AWS linux. Nuestro proceso de bootstrap 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 usamos Puppet, entonces tendríamos programación declarativa que es más fácil de auditar para ver lo que está sucediendo frente a un script. También 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 puedan proporcionar aquí en respuesta a mi pregunta?
4 answers
¿Hay alguna ventaja sobre CloudInit? Sí, absolutamente, muchos de ellos!
Claro, se puede escribir de arriba a abajo ejecutar una vez CloudInit scripts 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 servidores.
CloudInit no es gestión de configuración. Si opta por comenzar a usar la configuración software de gestión, utilice cloud init para una sola tarea:para arrancar el agente Puppet / Chef / other.
Puppet no solo le 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á resolviendo problemas con una aplicación Java a las 3 am y cambia la configuración de Tomcat, Puppet la cambiará de nuevo. 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 cambiará volver.
Cuando su pila de aplicaciones cambia y comienza a usar, por ejemplo, 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 usar software de gestión de configuración, como informes de back-end, auditoría y cumplimiento de seguridad.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-17 01:54:20
El objetivo de la gestión de la configuración es hacer girar las máquinas de manera predecible y consistente. CloudFormation y cloudinit son excelentes cuando se limita exclusivamente a AWS (aunque depurar plantillas de CloudFormation es una experiencia miserable), pero ¿qué pasa con las aplicaciones que usan recursos de centros de datos y AWS, o entornos de prueba locales o máquinas de desarrollo?
Si existes puramente en AWS, supongo que podrías salirte con la tuya con cloudinit y nada más, pero no estoy convencido de que sea realista para aplicaciones de cualquier escala (Netflix, por ejemplo, pre-hornea 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, ensayo, prueba o desarrollo. Como alguien que está encargado de aprovisionar máquinas las últimas cosas que quiero hacer es repetir el trabajo o quedar atascado depurar varios métodos de aprovisionamiento.
De ahí Chef o Títere. Funcionan tan bien para AWS como lo hacen para mi centro de datos, y tan bien para mi máquina de desarrollo que se ejecuta Vagrant como lo hacen 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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 11:47:05
Para los servidores desechados, digamos que correr detrás de un grupo de autoscaling Yo diría que cloudinit es probablemente suficiente. los scripts de shell de Linux o los scripts de Windows powershell deberían hacer el truco.
Si es un servidor de larga duración que planea administrar, tal vez chef, puppet o docker podría darle una ventaja como se menciona en la respuesta aceptada. Si no puede ver la ventaja después de usarlos, entonces probablemente no necesite la herramienta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-02-04 20:09:24
En mi experiencia, hay cosas simples que se hacen fácilmente con las herramientas GUI listas para usar que AWS proporciona, pero a medida que entra en cosas más complejas, comienza a descubrir que hay limitaciones en lo que puede hacer solo con 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 hacer las cosas más simples.
Su elección.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-04-22 22:45:53