Est-il raisonnable d'exécuter des processus avec des outils CI?

Dans mon entreprise, nous avons un bourbier de tâches cron disparates (sur plusieurs systèmes) et de processus déclenchés manuellement qui maintiennent le fonctionnement de notre entreprise, résultat d'années de développement rapide et de négligence subséquente.

Un jour, nous devrons trouver une solution plus centralisée pour des raisons évidentes.

Une idée que nous avons essayée est d'utiliser notre logiciel d'intégration continue (Jenkins) pour exécuter ces processus, ce qui semble logique.

Ma question est: d'autres entreprises font-elles cela? Est-ce une pratique généralement acceptée? Cela ne contredit-il pas la définition d'un outil CI implicite dans son nom? Il y a-t-il des alternatives?

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

Jenkins affirme qu'il se concentre sur "la surveillance des exécutions des travaux exécutés en externe, tels que les travaux cron et les travaux procmail". Je ne sais pas si c'est exactement ce dont je parle.

Nous utilisons Jenkins comme cron drop depuis quelques années maintenant, et voici quelques avantages et inconvénients:

Avantages

• Si vous gérez un grand nombre de processus sur des dizaines de serveurs et plusieurs environnements, cela facilite beaucoup de choses. Vous obtenez des alertes par e-mail, un tableau de bord commun pour tout, une interface Web pour les journaux et un moyen facile de configurer des nœuds supplémentaires pour exécuter des travaux. Les équipes de support apprécient particulièrement d'avoir cet emplacement central pour vérifier les problèmes et relancer les travaux.

• L'écosystème de plug-ins Jenkins est très actif et offre une multitude de fonctionnalités supplémentaires ... Je pense que c'est vraiment la fonctionnalité `` tueur '' de Jenkins, car si Jenkins lui-même ne fournit pas ce que vous recherchez (souvent le cas), plus souvent, il existe un plugin qui le fait. Certains de mes favoris: Cron Column, Rebuild, NodeLabel Parameter, Log Parser et Email-ext.

• Prise en charge avancée de la planification / déclenchement: la syntaxe de planification est essentiellement cron, vous avez donc la même flexibilité, mais elle est complétée par les déclencheurs, l'API REST et l'API Groovy / Java

Les inconvénients

• Point central d'échec: Parce que tous vos travaux sont lancés par un seul serveur, si cette boîte tombe en panne et que personne ne le remarque, Big Trouble. Il est donc préférable d'avoir une bonne surveillance pour détecter immédiatement les pannes, ainsi que toutes vos configurations enregistrées dans le contrôle de source. Même si vous ne pouvez pas récupérer le serveur d'origine, tant que vous avez configuré votre travail, il est trivial de les configurer ailleurs. Si le délai de résolution est un problème, avoir une veille préconfigurée quelque part est également une bonne idée.

• Si vous avez plusieurs environnements (Dev, UAT, Prod), vous disposez généralement de versions légèrement différentes d'un travail en cours d'exécution sur chaque environnement. Avoir tous ces travaux sur un seul Jenkins peut devenir compliqué, et les configurer manuellement devient une énorme douleur. Dans notre cas, nous exécutons une instance Jenkins 'Cron' distincte pour chaque environnement. Les instances sont installées et configurées automatiquement à l'aide d'un outil de déploiement interne. Vous n'avez peut-être pas quelque chose comme ça, mais il existe des outils open source qui font des choses similaires (générer des configurations à l'aide de modèles). Si vous pouvez résoudre le problème de génération de configuration, cela rend la configuration et le déploiement de Jenkins beaucoup plus faciles et facilite également le contrôle de toutes vos données.

• La mise à niveau de Jenkins rompt parfois les fonctionnalités, en particulier avec les plugins. Ne mettez pas à niveau votre instance Jenkins critique avant d'avoir essayé la nouvelle version ailleurs auparavant. C'est là qu'avoir un environnement Dev miroir avec sa propre instance Jenkins est très pratique.

Une chose à souligner peut-être: nous utilisons en effet également Jenkins pour CI, mais il s'agit d'une instance distincte ... les instances «cron» sont dédiées à la gestion des travaux, et l'instance «CI» est dédiée à CI. Séparer les préoccupations semble rendre les choses plus propres.

En passant, j'utilise Jenkins au lieu de cron sur ma box Linux à la maison :)

Soit dit en passant, il s'agit en fait d'un cas d'utilisation Jenkins assez courant. Par exemple, Sandia National Lab utilise Jenkins de cette façon: https://software.sandia.gov/trac/fast/wiki/Hudson

Et il existe de nombreux articles de blog et tutoriels décrivant cela. Voici quelques exemples: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

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

Je dois également ajouter que cela concerne vraiment Jenkins, et pas tous les outils CI en général. Ce n'est pas parce que Jenkins est bien adapté pour le faire que d'autres (TeamCity, buildbot, etc.) sont ...

J'aurais dit que vous n'utilisez pas le bon outil pour le travail ici car le point principal des outils CI est qu'ils surveillent quelque chose - votre code source généralement - et quand il y a un changement, ils lancent une construction / déploiement / quoi que ce soit .

Cependant, ces outils peuvent exécuter des tâches planifiées (TeamCity le fait par exemple), vous pouvez donc déployer un site Web (par exemple) lorsqu'il n'y a personne autour. Donc, avoir une seule liste centrale de toutes les tâches que vous exécutez est en fait une bonne idée. Les outils devraient également vous permettre de décider quand et à quelle fréquence ces travaux sont exécutés.

Un autre avantage est que vous pouvez même surveiller le système à distance (si vous le souhaitez).

Donc, dans l'ensemble, je dirais que c'était une chose sensée à faire.

Il semble que cron soit déjà un outil approprié à vos besoins. Je vous recommande de commencer par mieux documenter votre système. Auditez les différents systèmes et établissez une liste complète des processus exécutés sur les machines.

Pensez ensuite à désigner une machine dédiée pour exécuter tous ces processus cron. Assurez-vous de documenter de quel ordinateur il s'agit et attribuez les privilèges d'administrateur appropriés pour le contrôler. Mettez tous les cronjobs sur cette machine, puis vous avez un point de contrôle central pour vos différents processus automatisés.

Ma réaction instinctive est la même, que vous utilisez un outil qui a un concept de calendrier, pour faire le travail d'un planificateur de travaux.

Vous n'avez pas mentionné vos emplois, mais votre mention de CRON me fait penser qu'il s'agit de scripts shell, etc. Parfois, ils sont appelés ordonnanceurs par lots. Certains vont simplement conclure CRON et le rendre plus convivial. Certains, comme le planificateur Quartz, font une gestion puissante des travaux, mais nécessitent leur implémentation en tant que classes Java. Vous pouvez potentiellement l'utiliser et terminer les appels d'exécution à vos différents scripts à l'aide d'un wrapper java. Je pense que vous trouverez de nombreuses options si vous regardez plus loin.

N'utilisez pas CI pour exécuter des tâches périodiques non liées à la génération.

Évitez également cron pour les tâches qui ne sont pas liées à la maintenance du système.

Utilisez les bons outils. Pour les besoins des applications - essayez d'utiliser des solutions basées sur AMQP.

PS je vois, ce cron convient à votre cas. D'autre part, vous avez beaucoup de tâches - essayez donc d'écrire une application de superviseur pour elles.

Vous devez utiliser un bus de services d'entreprise (ESB) pour ce type de tâche.

Maintenant, mon expérience est dans Windows / BizTalk, mais je suis sûr que tous les équivalents existent également du côté unix des choses. Ce que nous ferions normalement est de mettre en place des processus sur la boîte BizTalk qui seraient chargés de lancer les choses sur l'autre boîte, de surveiller la progression / les erreurs et de rendre compte de l'état au portail SharePoint (ou Web), ou d'envoyer des e-mails et par exemple, s'il a besoin d'attention.

Les avantages de cette approche sont que toutes les configurations et la gestion de vos différents processus métier sont centralisées, vous savez donc par où commencer. Le logiciel existe déjà qui vous permet d'extraire la partie de codage de la configuration physique (dans BizTalk, vous pouvez programmer contre un `` port '' logique comme un serveur SQL, puis dans Prod, si une boîte SQL change d'emplacement ou est mise à niveau ou autre, vous peut changer le port physique configuré en utilisant leur outil d'administration, encore une fois, je suis sûr que des équivalents existent du côté unix).

Les avantages de l'utilisation d'un outil CI seraient des choses comme: si votre erreur de processus est éliminée, vous pouvez automatiquement renvoyer physiquement les messages et vous pouvez configurer un environnement de basculement en cluster, ayant un système d'enregistrement et de journalisation mieux adapté; De plus, une fois que le système est en place, il vous permettra de commencer à concevoir l'architecture de votre organisation pour l'utiliser, ou mieux utiliser SOA. L'inconvénient est que, selon la taille de votre organisation, l'effort de développement peut être élevé et les coûts de licence peuvent être prohibitifs.

Théoriquement, il est logique que vous ayez un emplacement unique pour contrôler tous les travaux disparates, mais en fonction de l'expérience de l'industrie qui est comme le "Saint Graal", vous aurez besoin d'emplois cron ici, de scripts bash là-bas et de scripts cli ici.

Il y a aussi un mantra "Si ce n'est pas cassé, ne le répare pas", alors pendant qu'ils avancent, concentrez-vous d'abord sur la documentation des scripts que vous exécutez, ce qu'ils font et les systèmes qu'ils touchent pour que vous "sachiez" "comment votre entreprise est gérée.

Puis, en tant que stratégie à long terme, installez un système centralisé pour exécuter les travaux, choisissez judicieusement votre solution car vous allez devoir vivre avec. Ensuite, pour chaque demande de changement, amélioration, mise à niveau, correction de bogue ou nouvelle solution que vous ajoutez dans votre architecture d'entreprise, assurez-vous que ses tâches planifiées et automatisées sont ajoutées à votre «solution de contrôle d'entreprise».

De cette façon, vous migrez progressivement d'un lot de scripts vers un environnement plus convivial pour l'entreprise.

Dans les grands systèmes d'entreprise avec lesquels j'ai travaillé, ils ont tendance à utiliser un outil conçu pour la planification. Le plus populaire que j'ai utilisé est CA7. Il vous permet de centraliser toute la planification de tous vos systèmes.

Cron est généralement utilisé pour la machine unique, bien que vous puissiez le "pirater" en faisant des appels à distance ssh. Cependant, il n'aura pas le concept de dépendances et d'autres choses. Lorsqu'il s'agit d'équipes opérationnelles dont le périmètre est encore plus limité, il est préférable d'utiliser un outil.