Usando Chef para operaciones de múltiples nodos

7

Tengo una aplicación que me gustaría configurar con Chef que abarca varios nodos. Digamos que el proceso de hacerlo consiste en

  1. Hacer algo en el nodo A capturando la salida
  2. Haga otra cosa en el nodo B con esa salida
  3. Volver al nodo A ahora para alguna operación
  4. Ahora en el nodo B nuevamente
  5. ...

Una forma de hacerlo sería escribir una receta que almacenara la etapa en la que se encontraba en cada nodo y simplemente seguir ejecutándola en ambos nodos repetidamente hasta que finalmente tenga la oportunidad de realizar todas las operaciones en todos los nodos. Pero esto es torpe y no se escalará si hay un nodo C, D, etc. Obviamente, sé sobre notificar a las dependencias de secuencia dentro de un solo nodo, pero eso no funcionará en varios nodos. No puedo ser la única persona que necesita esto, entonces, ¿hay un mecanismo o un patrón de diseño / mejores prácticas / TTP para este estilo de actividad?

chef Gayo
fuente

Respuestas:

6

En resumen, Chef puede no ser la herramienta para usar aquí.

Chef es un modelo convergente, por lo que debe escribir sus recetas de forma idempotente, como después de algunas ejecuciones, estará en el estado deseado de acuerdo con los otros nodos.

Su enfoque sobre el almacenamiento del estado parece el camino a seguir, y tendrá que usar un orquestador externo para programar las ejecuciones del chef-cliente alternativamente en A y B.
Si tiene un servidor de chef, los trabajos de inserción podrían ser el camino para seguir pegado en el ecosistema de chef, la principal ventaja que veo con respecto a otros orquestadores es un modelo de extracción que no necesita un puerto administrativo entrante ni ssh en los nodos de destino.

Tensibai
fuente
3

Este es un ejemplo de libro de texto de orquestación de servidores y es algo que Chef inherentemente no tiene la intención de hacer. Como señaló Tensibai, un servidor que ejecuta Chef es un sistema convergente que logra su propio estado deseado en función de los ajustes de configuración establecidos por recetas, atributos, bolsas de datos, etc. Sin entrar en detalles específicos sobre su infraestructura, algunos enfoques que podría poder tomar son:

Crear operaciones idempotentes independientes

Como indicó en su pregunta, crear un estado de operación en el que sus nodos puedan ejecutarse repetidamente hasta que se hayan completado todas las tareas no escala bien. Sin embargo, puede ser posible rediseñar sus nodos para que no importe. Si los nodos a y b ejecutan tareas para generar sus registros en paralelo, yb completa antes de a, podría ejecutar la tarea que normalmente ejecutaría el nodo a y viceversa.

Use un orquestador externo para la delegación

El uso de un nodo delegador definitivamente se escalará mucho mejor si pretende tener muchos nodos para orquestar. Sin embargo, esto podría crear conflictos con las ejecuciones de su cliente chef en los nodos que administra el delegador. Sería muy difícil verificar que las configuraciones de su nodo y las tareas del nodo delegador no entren en conflicto entre sí. Una forma inteligente de gestionar esto podría ser incorporar las tareas en la configuración de cada nodo y hacer que el delegador establezca un valor en una bolsa de datos o un atributo del servidor para indicar cómo debe configurarse (es decir, qué tareas debe realizar) )

Combina tu infraestructura

Si cada nodo ejecuta sus tareas en serie dependiendo de los otros nodos, y no tiene costos / dependencias técnicas en la ejecución de tareas en diferentes nodos, puede considerar combinar sus configuraciones de nodo en un solo nodo. Esto eliminaría cualquier conflicto de configuración que tenga entre cualquiera de sus nodos. Me imagino que hay intenciones claras para ejecutar sus tareas en diferentes nodos, pero esta es definitivamente una opción a considerar (tal vez incluso a costa del tiempo para reescribir tareas para diferentes nodos).

PrestonM
fuente
Tal vez. Tiendo a pensar en la orquestación como más sobre ejecutar cosas que realizar la configuración inicial de ellas.
Cayo