¿Es razonable ejecutar procesos con herramientas de CI?

En mi empresa, tenemos un atolladero de trabajos cron dispares (en múltiples sistemas) y arrancamos manualmente los procesos que mantienen nuestro negocio en funcionamiento que es el resultado de años de desarrollo oportuno y posterior negligencia.

Algún día, tendremos que encontrar una solución más centralizada por razones obvias.

Un pensamiento que hemos estado dando vueltas es usar nuestro software de Integración Continua (Jenkins) para ejecutar estos procesos, lo que parece lógico.

Mi pregunta es: ¿están haciendo esto otras compañías? ¿Es esta una práctica generalmente aceptada? ¿No entra esto en conflicto con la definición de una herramienta de CI implícita en su nombre? ¿Hay más opciones?

Nota: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins afirma que se centra en "Supervisar las ejecuciones de trabajos ejecutados externamente, como trabajos cron y trabajos procmail". No estoy seguro de si esto es exactamente de lo que estoy hablando.

Hemos estado usando a Jenkins como un cronista desde hace un par de años, y aquí hay algunos pros y contras:

Pros

• Si está administrando una gran cantidad de procesos en docenas de servidores y múltiples entornos, esto facilita mucho las cosas. Obtiene alertas de correo electrónico listas para usar, un panel de control común para todo, una interfaz web para registros y una manera fácil de configurar nodos adicionales para ejecutar trabajos. Los equipos de soporte aprecian especialmente tener esta ubicación central para verificar problemas y volver a ejecutar trabajos.

• El ecosistema de complementos de Jenkins es muy activo y proporciona una gran cantidad de funcionalidades adicionales ... Creo que esta es realmente la característica 'asesina' de Jenkins, ya que si Jenkins no proporciona lo que está buscando (a menudo el caso), más A menudo hay un complemento que lo hace. Algunos de mis favoritos: Cron Column, Rebuild, NodeLabel Parameter, Log Parser y Email-ext.

• Programación avanzada / soporte de activación: la sintaxis de programación básicamente es cron, por lo que tiene la misma flexibilidad allí, pero esto se complementa con Triggers, la API REST y la API Groovy / Java

Contras

• Punto central de falla: Debido a que todos los trabajos son iniciados por un servidor, si ese cuadro se cae y nadie se da cuenta, Gran Problema. Por lo tanto, es mejor que tenga una buena supervisión para detectar interrupciones de inmediato, así como todas sus configuraciones guardadas en el control de origen. Incluso si no puede volver a hacer una copia de seguridad del servidor original, siempre que tenga las configuraciones de su trabajo, es trivial configurarlas en otro lugar. Si el tiempo para la resolución es una preocupación, tener un modo de espera preconfigurado en algún lugar probablemente también sea una buena idea.

• Si tiene varios entornos (Dev, UAT, Prod), normalmente tiene versiones ligeramente diferentes de un trabajo que se ejecuta en cada entorno. Tener todos estos trabajos en una Jenkins puede volverse difícil de manejar, y configurarlos manualmente puede ser un gran dolor. En nuestro caso, ejecutamos una instancia separada de Jenkins 'Cron' para cada entorno. Las instancias se instalan y configuran automáticamente mediante una herramienta de implementación interna. Es posible que no tenga algo así, pero hay herramientas de código abierto que hacen cosas similares (generan configuraciones usando plantillas). Si puede resolver el problema de generación de configuración, esto hace que la configuración e implementación de Jenkins sea mucho más fácil, y también hace que sea más fácil mantener todas sus cosas en el control de origen.

• La actualización de Jenkins a veces rompe la funcionalidad, especialmente con complementos. No actualice su instancia de Jenkins de misión crítica hasta que haya probado la nueva versión en otro lugar primero. Aquí es donde tener un entorno Dev de espejo con su propia instancia de Jenkins es realmente útil.

Una cosa a destacar quizás: de hecho, también utilizamos Jenkins para CI, pero esta es una instancia separada ... las instancias 'cron' están dedicadas a la gestión de trabajos, y la instancia 'CI' está dedicada a CI. Separar las preocupaciones parece hacer las cosas más limpias.

Como nota al margen, uso Jenkins en lugar de cron en mi caja de Linux en casa :)

Por cierto, este es en realidad un caso de uso bastante común de Jenkins. Por ejemplo, Sandia National Lab utiliza Jenkins de esta manera: https://software.sandia.gov/trac/fast/wiki/Hudson

Y hay numerosas publicaciones de blog y tutoriales que describen esto. Aquí hay un par de ejemplos: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/1108

También debo agregar que esto realmente solo pertenece a Jenkins, y no a todas las herramientas de CI en general. El hecho de que Jenkins esté bien preparado para hacer esto no significa que otros (TeamCity, buildbot, etc.) estén ...

Habría dicho que no está utilizando la herramienta adecuada para el trabajo aquí, ya que el punto principal de las herramientas de CI es que supervisan algo, su código fuente normalmente, y cuando hay un cambio, inician una compilación / implementación / lo que sea .

Sin embargo, estas herramientas pueden ejecutar trabajos programados (TeamCity, por ejemplo), por lo que puede implementar un sitio web (por ejemplo) cuando no hay nadie cerca. Por lo tanto, tener una lista central única de todas las tareas que ejecuta es una buena idea. Las herramientas también deberían permitirle decidir cuándo y con qué frecuencia se ejecutan estos trabajos.

Otro beneficio es que incluso puede monitorear el sistema de forma remota (si lo desea).

Entonces, a fin de cuentas, diría que fue algo sensato.

Parece que cron ya es una herramienta adecuada para sus necesidades. Le recomiendo que comience documentando mejor su sistema. Audite los diversos sistemas y elabore una lista completa de los procesos que se ejecutan en qué máquinas.

Luego considere designar una máquina dedicada para ejecutar todos estos procesos cron. Asegúrese de documentar qué máquina es esta y asigne los privilegios de administrador adecuados para controlarla. Ponga todos los cronjobs en esa máquina, y luego tendrá un punto central de control para sus diversos procesos automatizados.

Mi reacción intestinal es la misma, que está utilizando una herramienta que tiene un concepto de programación, para hacer el trabajo de un programador de trabajos.

No ha mencionado cuáles son sus trabajos, pero su mención de CRON me hace suponer que son scripts de shell, etc. Existen paquetes de programación de trabajos de código abierto y comerciales. A veces se les conoce como programadores por lotes. Algunos simplemente terminarán CRON y lo harán más amigable. Algunos, como el planificador Quartz, realizan una gestión eficaz de los trabajos, pero requieren que se implementen como clases Java. Potencialmente, podría usar eso y concluir las llamadas en tiempo de ejecución a sus diversos scripts utilizando un contenedor java. Creo que encontrarás muchas opciones si buscas más.

No utilice CI para ejecutar tareas periódicas que no estén relacionadas con la compilación.

También evite cron para tareas que no están relacionadas con el mantenimiento del sistema.

Utiliza las herramientas adecuadas. Para las necesidades de la aplicación, intente utilizar soluciones basadas en AMQP.

PD Ya veo, ese cron se ajusta a tu caso. Por otro lado, tienes muchas tareas, así que intenta escribir una aplicación de supervisor para ellas.

Debe utilizar un bus de servicio empresarial (ESB) para este tipo de tarea.

Ahora mi fondo está en windows / BizTalk, pero estoy seguro de que también existen todos los equivalentes en el lado de Unix. Lo que normalmente haríamos es configurar procesos en el cuadro de BizTalk que se encargarían de iniciar las cosas en el otro cuadro, monitorear el progreso / errores y reportar el estado al portal de SharePoint (o web), o enviar correos electrónicos y tal si necesita atención.

Los beneficios de este enfoque es que toda la configuración y administración de sus diversos procesos de negocios están ubicados de manera centralizada, para que sepa dónde comenzar a buscar. El software ya existe que le permite abstraer la parte de codificación de la configuración física (en BizTalk puede programar contra un 'puerto' lógico como un servidor sql, y luego en prod, si un cuadro sql cambia de ubicación o se actualiza o lo que sea, usted puede cambiar el puerto físico configurado usando su herramienta de administración, de nuevo, estoy seguro de que existen equivalentes en el lado de Unix).

Los beneficios sobre el uso de herramientas de CI serían cosas como, si su proceso de error se puede, automáticamente, reenviar físicamente los mensajes y puede configurar un entorno de conmutación por error agrupado, con un sistema de registro y registro más adecuado; Además, una vez que tenga el sistema en su lugar, le permitirá comenzar a diseñar su organización para usar, o mejor, utilizar SOA. La desventaja es que, dependiendo del tamaño de su organización, el esfuerzo de desarrollo puede ser alto y los costos de licencia pueden ser prohibitivos.

Teóricamente tiene sentido que tenga una única ubicación para controlar todos los trabajos dispares, sin embargo, en base a la experiencia de la industria que es como el "Santo Grial", necesitará trabajos cron aquí, scripts de bash allí y scripts de cli aquí.

También hay un mantra "Si no está roto, no lo arregles", así que mientras avanzan lentamente, concéntrate inicialmente en documentar qué scripts tienes, qué hacen y qué sistemas tocan para que "sepas "cómo se gestiona su negocio.

Luego, a medida que una estrategia a largo plazo configura un sistema centralizado para ejecutar los trabajos, elija su solución sabiamente porque tendrá que vivir con ella. Luego, para cada solicitud de cambio, mejora, actualización, corrección de errores o nueva solución que agregue dentro de la arquitectura de su negocio, asegúrese de que sus tareas programadas y automatizadas se agreguen a su "solución de control empresarial".

De esta forma, migrará gradualmente de un lote de scripts a un entorno más amigable para la empresa.

En los sistemas empresariales grandes con los que trabajé, tienden a usar una herramienta diseñada para la programación. El más popular que he usado es CA7. Le permite centralizar toda la programación de todos sus sistemas.

Cron se usa generalmente para la única máquina, aunque puede "hackearlo" haciendo llamadas remotas ssh. Sin embargo, no tendrá el concepto de dependencias y otras cosas. Cuando se trata de equipos de operaciones donde su alcance es aún más limitado, es mejor utilizar una herramienta.