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

29

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.

smp7d
la source
2
Pouvez-vous clarifier la nature des différentes tâches et processus que vous envisagez?
Stephen Gross
un mélange de scripts dans différentes langues, des processus java et des commandes linux
smp7d
Nous avons besoin de plus de détails. Quelle est la nature des tâches? Que font-ils? Comment sont-ils gérés?
Stephen Gross
@StephenGross Rassemblez des données de systèmes externes pour le stockage local, envoyez des notifications aux utilisateurs en fonction des règles de l'entreprise, vérifiez l'utilisation du disque, supprimez les orphelins et environ mille autres choses. Ils sont tous gérés par cron s'ils sont gérés à ce stade. Pourquoi avez-vous besoin de ces détails? Vous pouvez simplement supposer qu'ils exécutent des fonctions critiques de l'entreprise selon un calendrier.
smp7d
2
La raison pour laquelle j'ai besoin de ces détails est parce que pour vous aider avec votre problème, j'ai besoin de comprendre le problème. Même si vous en savez déjà beaucoup sur ces tâches / processus, je ne le sais pas; il est utile de comprendre la nature des tâches à exécuter lors de l'évaluation du type de solution technique qui fonctionne le mieux.
Stephen Gross

Réponses:

17

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

Dylan Cali
la source
8

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.

ChrisF
la source
Vos sentiments sur le sujet reflètent les miens. Parce que CI est généralement connu pour les builds et les tests, je le vois comme une solution peu orthodoxe. Les autres réponses à cette question ont certainement montré que c'était le cas, car beaucoup le voient évidemment comme le mauvais outil pour le travail. Comme TeamCity peut effectuer ces tâches supplémentaires, tout outil de CI utilisant des projets Maven peut faire un certain nombre de choses. Je suis toujours mal à l'aise que ce soit une bonne idée.
smp7d
1
@ smp7d - d'accord. C'est une solution possible , mais pas une solution idéale .
ChrisF
6

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.

Stephen Gross
la source
2

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.

Guerry
la source
Les travaux sont un mélange de scripts dans différentes langues, de processus java et de commandes linux. Quartz seul ne me donnera pas la gestion frontale / build que Jenkins fournirait et je ne veux pas construire tout ça. Je ne serais pas surpris si Jenkins utilise Quartz dans les coulisses. Je vais vérifier ce gestionnaire de quartz cependant ( terracotta.org/products/quartz-scheduler ).
smp7d
2

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.

Nikolay Fominyh
la source
1
Merci d'avoir répondu. Pouvez-vous décrire ce que vous entendez par «application superviseur»?
smp7d
En quelques mots - c'est supervisord.org . Programme méta qui contrôle l'état et l'exécution d'autres processus. Vous pouvez facilement développer votre propre solution adaptée à vos besoins. J'ai un lot de tâches périodiques sur mon projet et github.com/ask/django-celery m'aide à sortir de cron.
Nikolay Fominyh
Merci, je vais me renseigner sur le superviseur. Le but de l'utilisation de l'outil CI était de nous empêcher d'avoir à écrire notre propre outil. L'outil CI est lisse comme peut l'être déjà.
smp7d
1
Je suppose que je n'ai pas le représentant pour voter contre, mais c'est une réponse assez terrible - dommage qu'il ait obtenu la prime. Qu'est-ce qui fait d'un outil le "bon outil"? Même s'il possède exactement tous les composants nécessaires, ce n'est pas le "bon outil" car il s'appelle un système CI?
DougW
1

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.

aceinthehole
la source
Peut-être que cela est applicable, mais je ne suis pas sûr qu'il s'agisse plus d'appliquer le mauvais outil que le CI le serait. J'ai l'impression que l'ESB serait utilisé lorsque la communication ou la chorégraphie de processus sont nécessaires. Dans ce cas, nous souhaitons simplement une gestion centrale pour un ensemble de processus autonomes. Nous sommes très bien avec l'exécution de commandes linux personnalisées via la gestion centrale, donc tout agnosticisme OS / langage de programmation est probablement exagéré. Cela vaut probablement la peine d'examiner, merci.
smp7d
Si vous êtes une boutique Unix, allez-y, je sais qu'IBM a un produit dans sa gamme Websphere, et il y a aussi des méthodes Web qui sont commerciales, et Appache a une offre open source; vous avez raison dans le sens de votre définition de l'ESB, malheureusement l'ESB est devenu quelque peu ambigu dans son utilisation, mais envisagez si vous souhaitez éventuellement ajouter un rapport d'erreurs centralisé, ou tout autre type de rapport comme `` est-ce qu'il a fonctionné '' dans votre processus qui est chorégraphie.
aceinthehole
@ smp7d Je sais que webMethods Integration Server prend en charge la planification de première classe. Fonctionne bien.
Robert Grant,
1

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.

Stephen Senkomago Musoke
la source
Ce sont de bonnes pensées. Vous pensez donc que ce que je recherche n'existe pas et qu'un outil CI n'est pas une alternative raisonnable?
smp7d
Il peut exister, mais le pragmatisme sur ce que vous utilisez peut vous faire avoir encore des tâches cron et des scripts bash. Cependant, l'utilisation de votre environnement CI peut être un obstacle plus tard, car CI est principalement destiné aux flux de travail de développement, mais à mesure que l'environnement mûrit, vous recherchez des solutions liées aux opérations. Plus tard, vous pouvez décider de déplacer votre contrôle de version / CI vers le cloud, vous ne voulez pas que cela soit embourbé pour gérer les opérations quotidiennes de votre organisation.
Stephen Senkomago Musoke
Eh bien, nous pensions utiliser un outil CI distinct pour la gestion des processus, mais je vois ce que vous dites.
smp7d
Puisque vous cherchez un CI distinct, alors pourquoi ne pas regarder des outils axés sur la gestion des processus, la surveillance et le reporting. De cette façon, vous tirez parti de l'effort de mise en place du CI pour obtenir le bon outil pour le travail, s'il échoue, vous avez le CI sur
lequel
Je suis d'accord que c'est la voie la plus raisonnable à prendre. Quartz Scheduler, supervisord.org et un ESB ont été recommandés. Avez-vous d'autres recommandations ou réflexions à ce sujet? (aussi: quand j'ai dit CI séparé, je voulais juste dire une autre installation de notre outil actuel avec peut-être une nouvelle marque ... la configuration ne serait pas un problème)
smp7d
0

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.

Archimedes Trajano
la source
Votre recommandation m'a conduit à ceci ... en.wikipedia.org/wiki/Job_scheduler - Étonnamment, personne n'a jamais mentionné ce nom pour un tel outil. C'est peut-être ce que je cherchais comme s'il était conçu pour faire ce que je cherchais, le temps montrera probablement qu'il le fait mieux qu'un outil CI. Il faudra cependant quelques recherches pour vérifier cela.
smp7d