¿Cuáles son las preguntas correctas para decidir al usar Chef o Puppet?

Estoy a punto de comenzar un nuevo proyecto que, en parte, requerirá la implementación de muchos nodos idénticos de aproximadamente tres clases diferentes:

• Nodos de datos , que ejecutarán instancias fragmentadas de MongoDB.
• Nodos de aplicación , que ejecutarán instancias de una aplicación Ruby on Rails y una aplicación ASP.NET MVC anterior.
• Procesando nodos , que ejecutarán trabajos solicitados por los nodos de la aplicación.

Todos los nodos se ejecutarán en instancias de Ubuntu 10.04, aunque tendrán diferentes paquetes instalados.

Tengo cierta familiaridad con Chef de proyectos anteriores, aunque no me considero un experto. En un esfuerzo por hacer la debida diligencia, he estado investigando posibilidades alternativas. Tenemos varias personas internas que son usuarios de Puppet desde hace mucho tiempo, y me han animado a echar un vistazo.

Sin embargo, tengo problemas para evaluar ambas opciones. Chef y Puppet comparten la misma terminología de dominio: paquetes , recursos , atributos , etc., y tienen una historia común que se deriva de adoptar diferentes enfoques para el mismo problema. Entonces, en cierto sentido, son muy similares. Pero gran parte de la información de comparación que he encontrado, como este artículo , está un poco desactualizada.

Si comenzaras este proyecto hoy, ¿qué preguntas te harías para decidir si deberías usar Chef o Puppet para la gestión de la configuración? (Nota: no quiero responder a la pregunta "¿Debo usar Chef o Puppet?")

Tanto Puppet como Chef pueden hacer lo que quieras bien. Lo mejor será comenzar a hacer lo que está tratando de hacer y decidir qué herramienta le gusta más. Creo que las grandes preguntas que debes hacer es:

¿Quieres un DSL? - Las recetas del chef están escritas en rubí, la marioneta tiene un DSL. Si una DSL es buena o una mala elección es una de las mayores diferencias entre chef y títere. El enlace que publicó en la comparación de bitfield consulting tiene algunos buenos comentarios sobre esto que debería leer si aún no lo ha hecho. También encontré esta publicación de blog útil, asegúrese de leer los comentarios también.

¿Sabes Ruby? - Si no conoce Ruby, comenzar a trabajar con el chef puede ser más difícil o requerir una mayor inversión de tiempo ya que necesita aprender un nuevo idioma. Puppet tiene su propio idioma con el que es fácil comenzar. Comenzando con la marioneta 2.6, los manifiestos también se pueden escribir en rubí .

En el Open Source Bridge en 2009, tuvieron un panel de autores y representantes de chef, puppet, bcfg2, cfengine, y automateit que puede ver en bliptv, que tiene 1.75 horas de discusión sobre las utilidades de administración de configuración.

Opscode / Chef también habla sobre la diferencia entre él y el títere en sus preguntas frecuentes .

Creo que no saber las preguntas correctas que puede hacer puede deberse a que no tiene demasiada experiencia trabajando con ninguno de ellos, una vez que comience a usarlos, comenzará a ver las diferencias entre ellos. Sugeriría venir con algunos problemas de la vida real que resolverá con un chef o títere, luego comience a tratar de resolverlos y vea lo que le gusta / disgusta de ellos. Con Opscode / Chef, ofrecen una solución alojada que puede configurar 5 nodos de forma gratuita para comenzar.

Déjame decirte primero, si no estás usando Puppet o Chef; No hay una respuesta incorrecta. Cualquiera será mucho mejor de lo que estás haciendo ahora.

Como líder del equipo, elegí Puppet para mi equipo. Si fuera un equipo de mí mismo, habría elegido Chef en su lugar. Este es el por qué:

Si bien mi experiencia es ciertamente en administración de sistemas, mi experiencia es en programación. Para eso fui a la escuela, y no soy ajeno a escribir solicitudes completas (no solo guiones). Si bien no conocía a Ruby, quiero saberlo, y Chef habría sido una gran excusa para aprender ambos.

Sin embargo, mi equipo está lleno de administradores de sistemas con poca o ninguna experiencia en programación, aparte del ocasional script de shell. Para ellos, escribir un módulo de títeres es muy parecido a escribir un archivo de configuración. Es declarativo, no hay iteradores, y en general es más amigable para el administrador.

Los equipos llenos de desarrolladores que realizan actividades de administrador de sistemas tienden a preferir Chef. Dado que el DSL de Puppet es declarativo, el orden (incluso dentro de los archivos individuales) no importa, y eso frustra a muchos acostumbrados a un lenguaje de programación más típico.

También he escuchado que muchas veces se dice que Chef es mucho más amigable con la nube que Puppet, pero Puppet lo ha enfocado con su producto Puppet Enterprise en el último año. No puedo hablar por experiencia sobre las capacidades en la nube de ninguno de los productos.

Debido a esas cualidades anteriores, el estereotipo (y a menudo es correcto) es que encontrará que Puppet es más dominante en la empresa en máquinas físicas, donde Chef gobierna las startups en la nube. Hay excepciones, por supuesto, pero lo que he visto ciertamente respalda el estereotipo.

Si se trata de un equipo de una sola persona, evalúe ambos y elija cuál le gusta. Sin embargo, si como yo tienes un equipo de personas, asegúrate de mantener las necesidades de tu equipo priorizadas sobre cualquier preferencia personal, te ahorrará más tarde cuando intentes y obtengas la aceptación.

Revelación completa, no utilizamos ninguno de estos, aunque los evaluamos internamente al intentar decidir sobre un sistema de gestión de configuración. Por lo tanto, no me consideres un experto en ninguno de estos, después de todo.

• ¿Qué tan fácil es obtener una configuración de instancia?
• ¿Qué configuración se requiere en el cliente para que se comunique con el servidor?

Y así. Pero usted mismo puede responder estas preguntas muy fácilmente: ¡configúrelas! Obtener una muestra en funcionamiento es unas pocas horas de su tiempo para cada producto, y teniendo en cuenta que lo que sea que use para esto probablemente se usará durante mucho tiempo, el tiempo bien vale la pena. No solo puede tener una idea de cómo manejan las cosas específicas de la plataforma (es decir, basadas en Debian y apt, basadas en RPM y yum), sino que definitivamente lo ayudará a tener una idea de las aplicaciones.

Tenga en cuenta también que todas las características del mundo no compensarán una interfaz difícil, además, puede exponer problemas específicos de su infraestructura, es decir, qué sucede si los archivos de configuración se actualizan en un orden diferente ¿que lo esperado?

Entonces ese es mi consejo; Chef y Puppet no son tan difíciles de obtener para la configuración de un servidor y uno o dos clientes, y le brindarán experiencia de primera mano en ambos. Además, si comienza a configurarlo y se da cuenta de que es un gran dolor, ya tendrá el conocimiento antes de comprometerse.

Si hay personas en su proyecto que ya tienen experiencia con Puppet, le sugiero que use Puppet.

Chef y Puppet son bastante similares, y ambos proyectos son igualmente de alta calidad. Si tiene acceso a personas que ya tienen experiencia de Puppet, simplemente use Puppet.

Lo anterior es definitivamente una buena guía, también me gusta hacer estas preguntas generales cada vez que estoy considerando una nueva dependencia de terceros.

• ¿Cuál es la edad del proyecto?
• ¿Qué tan activa es la comunidad (listas de correo, errores, irc, etc.)?
• ¿Se proporciona buena documentación sólida con prácticas estándar?

Estos son buenos indicadores del éxito general del proyecto y pueden predecir algo la vida útil.

Trate de encontrar personas que hayan estado usando Chef o Puppet durante más de un par de meses y pregúnteles sobre sus experiencias.

Para mí, está estrechamente relacionado con la tradición de una comunidad específica. Históricamente, Chef estaba más cerca de los chicos de RubyOnRails. También gran parte de la popularidad del Chef en la comunidad ROR porque Engineyard construyó su infraestructura sobre el Chef.