¿Cómo “coexiste” Juju con Chef, llevando el proceso de automatización “un paso más allá”?

Está claro de esta publicación que Juju se encuentra en una capa diferente que Chef Server. Juju se sienta en la capa de orquestación o servicio , mientras que Chef se sienta más en el servidor individual o en la capa de configuración .

En una de las páginas principales de Canonical en Juju , afirma que Juju está diseñado para "coexistir" con herramientas como Chef y Puppet, llevando el proceso "un paso más allá". He buscado en Internet las últimas semanas sobre este tema y no puedo encontrar una buena explicación de cómo , sin embargo, una herramienta como Chef coexistirá con Juju.

Entonces, para desglosar la pregunta general en el título: (interés particular en que Juju trabaje junto con un Chef Server)

• ¿Cuál es un ejemplo de un encanto "escrito en Chef"? ¿Es simplemente un amuleto escrito en bash que luego llama al chef-solocomando? Si es así, ¿puede un encantamiento llamar al chef-clientcomando para trabajar en concierto con un Chef Server?
• ¿Dónde está la superposición entre Juju y Chef? Por ejemplo, el encanto de apache2 tiene su config-changedgancho donde realiza cambios de configuración que, en el mundo del Chef, tendrían lugar en una receta mediante la aplicación de un archivo de plantilla. Si un amuleto de Juju funcionara junto con un libro de cocina Chef para implementar un servicio apache2 (clúster), casi parecería que tendría que escribirse un amuleto "apache2-chef" para poder separar las tareas. En este caso, el encanto de apache2 en la tienda de encanto sería menos que útil.
• Si tiene roles de Chef aplicados a los nodos (unidades de servicio) que Juju implementa / administra y su administrador de sistemas decide cambiar las reglas del firewall para un rol de servidor en particular y, en el rol de Chef, ¿Juju sobrescribirá esos cambios?
• Más simplemente, ¿puede Juju ser un envoltorio de Chef Server, como Ironfan ?

Veo Chef Server como el cómo, mientras que Juju puede hacer el cómo , pero también trae qué a la mesa. Lo que significa que se puede consultar y actuar sobre el estado actual real de los servicios y las máquinas. No puedes hacer esto en Chef Server. Mi objetivo es llevar la capacidad de orquestación de servicios y conciencia de Juju a una infraestructura administrada por Chef Server.

Casi parece que habría que escribir un conjunto completo de encantos donde se omiten todas las tareas administradas por Chef / información de configuración.

Me encantaría escuchar los pesajes de alguien en Canonical (como Jorge Castro) y de Opscode (como A. Jacob o J. Timberman).

preguntas increíbles!

el tl; dr

Me gustaría desglosar sus preguntas en un par de comentarios ... En primer lugar, aquí hay un par de enfoques generales para integrar chef y juju:

• Los ganchos de encantos pueden usar recetas de chef existentes que funcionan solo en unidades de servicio (recomendado)

• las unidades de servicio de juju se registran con un servidor de chef existente utilizando un servicio subordinado de nodo de chef

Estas ideas aún no se han implementado / probado para el chef, pero existen los equivalentes de títeres.

la ... respuesta no tan corta

Aquí hay un poco más de un desglose de dos enfoques para integrar chef y juju:

Juju como top-dog

Aquí juju dirige el espectáculo. El mayor valor que proporciona juju es la coordinación de eventos durante la gestión de la configuración distribuida ... de ahí el apodo de "orquestación de servicios". Los encantos de Juju consisten en ganchos que juju llama "en el momento adecuado" al coordinar la gestión del servicio. La implementación de estos ganchos es bastante abierta. Son scripts de shell, código fuente, manifiestos de marionetas o ... recetas de chef.

Juju divide partes de cualquier configuración de servicio en:

• "instalación" ... los bits que son específicos para instalar un servicio particular en un nodo

• "relación" ... los bits de configuración necesarios para relacionar ese servicio con algún otro servicio

La clave para usar recetas de chef como implementaciones de gancho es exactamente esto ... debe asegurarse de que las recetas que está usando respetan esta separación de preocupaciones. De lo contrario, no hay nada que impida el uso de libros de cocina listos para usar. Puede aprovechar las recetas existentes que ha gastado tiempo / dinero para desarrollar ... Solo necesita asegurarse de que puede llamar a las cosas específicas de la relación por separado de las cosas específicas de la instalación.

Necesitamos algunos ejemplos de esto, pero creo que será popular porque b / c chef tiene una gran dsl, una gran herramienta de plantillas, y es mucho más agradable de usar que bash al escribir configuraciones complejas. Para una configuración simple, las recetas de chef son un poco exageradas en la OMI, por lo que este método de integración es prácticamente el mejor de ambos mundos ... y tiene grandes piernas en el futuro.

Chef como top-dog

La idea aquí es integrar los servicios de juju en una infraestructura administrada por chef-servidor existente. Para hacer esto, necesitaría escribir un encanto subordinado de nodo de chef. Este servicio subordinado se adjuntaría a los servicios primarios de juju y registraría efectivamente estos servicios como nodos (en roles particulares) con el servidor chef. Los subs se pueden adjuntar durante el inicio del servicio juju o en cualquier momento posterior durante el ciclo de vida de cada servicio.

Estoy pensando que esto sería bastante similar a la sub-puppet-node. Todas las claves, roles, etc. necesarios se especificarían a través de la configuración del encanto subordinado del nodo de chef. Yo comenzaría por allí. Un enfoque más sofisticado sería que el sub chef-nodo interrogara tanto al servicio primario al que está conectado como a su chef-servidor para determinar dinámicamente los roles, pero eso sería un poco más difícil que solo especificarlos en la configuración del sub.

Opiniones

Definitivamente recomendaría el método 1 anterior, si es posible. Tiene la capa de la coordinación en la parte superior de las herramientas de configuración probablemente va a funcionar bien a largo plazo. Huelga decir que las infraestructuras del mundo real podrían ser una combinación o variación de ambos enfoques por un período de tiempo ... especialmente durante la migración. La coexistencia planificada usando el método 2 probablemente solo funcionaría si los componentes administrados por ambas herramientas fueran algo ortogonales entre sí. No estoy seguro exactamente de cómo se vería eso. ¿Quizás juju y chef manejan servicios separados relativamente desacoplados? Sospecho que podría funcionar bien dejar que juju administre los servicios primarios y que el chef administre más aspectos de infraestructura. No sé. Sin embargo, esa es una discusión un poco más larga :)

Nota al margen ... también puede usar juju para administrar el servidor de chef en sí mismo ... incluso grandes instalaciones complejas de varios niveles de servidor de chef. No he mirado el encanto del chef-servidor últimamente, pero si actualmente no maneja la división en niveles y la separación de servicios, entonces ciertamente se puede hacer.

Me encantaría ver más ejemplos de los dos tipos de integración de chef mencionados anteriormente ... ha estado en mi lista de deseos / tareas pendientes por un tiempo, pero aún tiene una prioridad lo suficientemente alta como para hacerlo ... por favor ayuda si ¡estás interesado!

ok, esa es una buena cantidad de divagaciones:) ... comencemos allí, luego podemos entrar en más detalles en los bloques de comentarios posteriores.