¿Es razonable ejecutar procesos con herramientas de CI?

29

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.

smp7d
fuente
2
¿Puede aclarar la naturaleza de las diversas tareas y procesos que tiene en mente?
Stephen Gross
una mezcla de secuencias de comandos en varios idiomas, procesos de Java, y los comandos de Linux
smp7d
Necesitamos más detalles. ¿Cuál es la naturaleza de las tareas? ¿Qué hacen? ¿Cómo se manejan?
Stephen Gross
@StephenGross Reúna datos de sistemas externos para el almacenamiento local, envíe notificaciones a los usuarios en función de las reglas comerciales, verifique el uso del disco, elimine huérfanos y otras mil cosas. Todos son administrados por cron si se administran en este momento. ¿Por qué necesitas estos detalles? Puede suponer que realizan funciones críticas de negocios en un horario.
smp7d
2
La razón por la que necesito estos detalles es porque para ayudarlo con su problema, necesito entenderlo. Aunque ya sabes mucho sobre estas tareas / procesos, yo no; Es útil comprender la naturaleza de las tareas a ejecutar cuando se evalúa qué tipo de solución técnica funciona mejor.
Stephen Gross

Respuestas:

17

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 ...

Dylan Cali
fuente
8

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.

ChrisF
fuente
Tus sentimientos sobre el tema reflejan los míos. Debido a que generalmente se sabe que CI es para compilaciones y pruebas, lo veo como una solución poco ortodoxa. Las otras respuestas a esta pregunta definitivamente han demostrado que ese es el caso, ya que muchos ven obviamente la herramienta incorrecta para el trabajo. Como TeamCity puede realizar estas tareas adicionales, cualquier herramienta de CI que use proyectos Maven puede hacer cualquier cantidad de cosas. Todavía me incomoda que sea una buena idea.
smp7d
1
@ smp7d - de acuerdo. Es una solución posible , pero no una solución ideal .
ChrisF
6

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.

Stephen Gross
fuente
2

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.

Guerry
fuente
Los trabajos son una mezcla de scripts en varios idiomas, procesos de Java y comandos de Linux. Quartz por sí solo no me dará la administración de front-end / build que proporcionaría Jenkins y no quiero construir todo eso. No me sorprendería si Jenkins usa Quartz detrás de escena. Sin embargo, revisaré este Administrador de cuarzo ( terracotta.org/products/quartz-scheduler ).
smp7d
2

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.

Nikolay Fominyh
fuente
1
Gracias por la respuesta. ¿Puedes describir lo que quieres decir con "aplicación de supervisor"?
smp7d
En pocas palabras, es supervisord.org . Metaprograma que controla el estado y la ejecución de otros procesos. Puede desarrollar fácilmente su propia solución que se ajuste a sus necesidades. Tengo un lote de tareas periódicas en mi proyecto y github.com/ask/django-celery me ayuda a salir de cron.
Nikolay Fominyh
Gracias, investigaré al Supervisor. El propósito de usar la herramienta CI era evitar que necesitáramos escribir nuestra propia herramienta. La herramienta CI es ingeniosa, como puede ser ya.
smp7d
1
Supongo que no tengo el representante para rechazar esto, pero es una respuesta bastante terrible: lástima que haya obtenido la recompensa. ¿Qué hace que una herramienta sea la "herramienta correcta"? Incluso si tiene exactamente todos los componentes necesarios, ¿es la "herramienta incorrecta" porque se llama un sistema de CI?
DougW
1

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.

aceinthehole
fuente
Tal vez esto sea aplicable, pero no estoy seguro de que se trate más de aplicar la herramienta incorrecta como lo sería CI. Tengo la impresión de que ESB se usaría cuando se necesita comunicación o coreografía de proceso. En este caso, solo queremos una administración central para una variedad de procesos independientes. Estamos bien con la ejecución de comandos personalizados de Linux a través de la administración central, por lo que cualquier agnosticismo del sistema operativo / lenguaje de programación probablemente sea excesivo. Probablemente valga la pena analizarlo, gracias.
smp7d
Si usted es una tienda de Unix definitivamente vaya con eso, sé que IBM tiene un producto en su línea de webphere, y también hay métodos web que son comerciales, y Appache tiene una oferta de código abierto; tiene razón en el sentido de su definición de ESB, desafortunadamente ESB se ha vuelto algo ambiguo en su uso, pero considere si eventualmente desea agregar un informe centralizado de errores, o cualquier tipo de informe como '¿se ejecutó' en su proceso? coreografía.
aceinthehole
@ smp7d Sé que webMethods Integration Server tiene soporte de programación de primera clase. Funciona bien.
Robert Grant
1

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.

Stephen Senkomago Musoke
fuente
Estos son algunos buenos pensamientos. ¿Entonces cree que lo que estoy buscando no existe y que una herramienta de CI no es una alternativa razonable?
smp7d
Puede existir, pero el pragmatismo en lo que usa puede causar que todavía tenga trabajos cron y scripts bash. Sin embargo, usar su entorno de CI puede ser un obstáculo más adelante porque CI es principalmente para flujos de trabajo de desarrollo, pero a medida que el entorno madura, está buscando soluciones relacionadas con las operaciones. Más tarde, puede decidir mover su control de versión / CI a la nube, no desea que se bloquee porque está ejecutando las operaciones diarias de su organización.
Stephen Senkomago Musoke
Bueno, estábamos pensando que usaríamos una herramienta de CI separada para la gestión de procesos, pero veo lo que estás diciendo.
smp7d
Dado que está buscando un CI independiente, entonces, ¿por qué no mirar las herramientas enfocadas en la gestión de procesos, el monitoreo y la presentación de informes? De esa manera, aprovecha el esfuerzo para configurar el CI para obtener la herramienta adecuada para el trabajo, si falla, tiene que recurrir al CI
Stephen Senkomago Musoke
Estoy de acuerdo en que este es el camino más razonable a seguir. Quartz Scheduler, supervisord.org y un ESB han sido recomendados. ¿Tiene alguna recomendación adicional o ideas sobre esto? (también: cuando dije CI por separado, me refería a otra instalación de nuestra herramienta actual con quizás una nueva marca ... la configuración no sería un problema)
smp7d
0

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.

Arquímedes Trajano
fuente
Su recomendación me llevó a esto ... en.wikipedia.org/wiki/Job_scheduler - Sorprendentemente, nadie mencionó este nombre para tal herramienta. Esto puede ser lo que estaba buscando, ya que si está diseñado para hacer lo que estoy buscando, el tiempo probablemente mostrará que lo hace mejor que una herramienta de CI. Sin embargo, tomará algo de investigación para verificar eso.
smp7d