Vagrant provisioning shell vs puppet vs chef

Question

Vagrant provisioning shell vs puppet vs chef

Tengo la siguiente configuración:

Muchos proyectos diferentes que son repositorios git separados, pero todos tienen en su mayoría la misma configuración de servidor
Cada proyecto a su vez depende de muchos otros proyectos y usamos el administrador de dependencias de composer para reunirlos (lenguaje PHP aquí).

Quiero usar Vagrant e incluir un archivo Vagrant en cada repositorio, para que los miembros de mi equipo puedan clonar un repositorio, ejecutar vagrant up y estar listos para comenzar.

Mi pregunta es ahora dirigido hacia el aprovisionamiento. Necesito instalar varias herramientas y paquetes como apache, git, mysql y varios paquetes php, luego descargar algunos archivos (como un volcado de base de datos de desarrollo reciente), configurar todo en /var/www y ejecutar el comando composer install.

Así que una opción para hacer esto es usar un administrador usando recetas como chef o puppet. La alternativa sería escribir un archivo bash y usar el aprovisionamiento de shell.

No tengo mucha experiencia con chef / puppet, así que naturalmente, parece más fácil usar la opción shell, pero quiero entender si esta no es una opción buena / viable a largo plazo.

Por qué me parece un mal enfoque ir con puppet / chef:

Entiendo que tendré que usar varias recetas diferentes y casi siempre usaré las mismas recetas para mis diferentes repositorios, por lo que tendría que incluirlas todas en todos los repositorios. Considere tener 20 repos y necesitar 10 recetas, eso significa que necesitaré agregue 200 recetas como un submódulo git o similar (también cada miembro del equipo necesita clonar el repositorio, luego clonar 10 repositorios de recetas y solo entonces ejecutar vagrant para cada proyecto). En contraste, solo necesitaría tener un pequeño repositorio con mi script de shell y clonarlo 20 veces.

Probablemente me falta algo, así que por favor aconseje si debo optar por chef / puppet y por qué tiene sentido incluso si mis repositorios tienen una configuración de servidor muy similar.

37

shell provisioning vagrant chef puppet

Author: mpaepper, 2013-11-09

Source

2 answers

Actualizado en 2016

Para aquellos que encontraron esto a través de Google, parece un grupo de desarrolladores se están moviendo hacia Ansible por la simplicidad. De post:

"Ansible es la herramienta de implementación para personas a las que no les gustan las herramientas de implementación. Está cerca de scripting, no contamina sus servidores con agentes o servidores centralizados, y simplemente tiene sentido inmediato."

Lo implementamos recientemente en nuestra arquitectura de microservicios y ha sido impresionante.

Super simple
Tomó alrededor de un día para recoger
Realmente no necesitas pensar en ello una vez que estés listo{[16]]}

Puppet/chef siempre tienen un lugar en mi corazón / pila, pero Ansible es simplemente más fácil.

2

Author: the_red_baron,
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
2016-11-23 17:47:37

score 25 · Accepted Answer

El siguiente artículo se refiere a otra herramienta de CM (ansible), pero creo que el autor hace un excelente trabajo al explicar los beneficios de la transición fuera de los scripts de shell.

Http://devopsu.com/blog/ansible-vs-shell-scripts /

Cita 1:

Lo que realmente me sorprendió fue la respuesta de algunos de estos desarrolladores más famosos. Básicamente dijeron, " Esto es realmente genial, pero probablemente no lo leeré desde mi manual-install / shell-script el flujo de trabajo está bien por ahora."

Estaba un poco sorprendido, pero una vez que pensé en ello durante unos minutos, me di cuenta de que su elección era perfectamente sana y racional dado lo que sabían sobre las herramientas CM.

Cita 2:

Para ellos, usar una herramienta de CM significaba semanas de esfuerzo aprendiendo conceptos complejos, luchando con un proceso de instalación complejo y manteniendo ese sistema complejo a lo largo del tiempo. Eran algo conscientes de los beneficios, pero los costos de usar un CM la herramienta parecía demasiado alta para que valiera la pena el esfuerzo.

Los beneficios sobre los scripts de shell se resumen al final y creo que se aplican a todas las herramientas de CM, puppet, chef, salt, ansible...

¿Qué método es más probable que termine en el control de fuentes?
¿Qué método se puede ejecutar varias veces con seguridad y confianza?
¿Qué método se puede ejecutar fácilmente contra varios servidores?
¿Qué método realmente verifica (prueba) su servidor para corrección?
¿Qué método puede apuntar a ciertos servidores fácilmente (web, db, etc.)?
¿Qué método soporta fácilmente plantillas de sus archivos de configuración?
¿Qué método crecerá para soportar fácilmente toda tu pila?

Espero que esto ayude.