Ist es sinnvoll, Prozesse mit CI-Tools auszuführen?

29

In meinem Unternehmen gibt es einen Sumpf unterschiedlicher Cron-Jobs (auf mehreren Systemen) und manuell gestartete Prozesse, die unsere Geschäftstätigkeit aufrechterhalten. Dies ist das Ergebnis jahrelanger zweckmäßiger Entwicklung und anschließender Vernachlässigung.

Eines Tages müssen wir aus offensichtlichen Gründen eine zentralere Lösung finden.

Ein Gedanke, den wir in die Irre geführt haben, ist die Verwendung unserer Continuous Integration-Software (Jenkins), um diese Prozesse auszuführen, was logisch erscheint.

Meine Frage ist: Tun das andere Unternehmen? Ist das eine allgemein akzeptierte Praxis? Widerspricht dies nicht der Definition eines CI-Tools, das in seinem Namen impliziert ist? Gibt es noch andere Möglichkeiten?

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

Jenkins gibt an, dass der Schwerpunkt auf der Überwachung der Ausführung von extern ausgeführten Jobs wie Cron-Jobs und Procmail-Jobs liegt. Ich bin mir nicht sicher, ob das genau das ist, wovon ich spreche.

continuous-integration cron smp7d
quelle
2
Können Sie die Art der verschiedenen Aufgaben und Prozesse erläutern, die Sie im Auge haben?
Stephen Gross
Eine Mischung aus Skripten in verschiedenen Sprachen, Java-Prozessen und Linux-Befehlen
smp7d
Wir brauchen mehr Details. Was ist die Art der Aufgaben? Was machen Sie? Wie werden sie verwaltet?
Stephen Gross
@StephenGross Sammeln Sie Daten von externen Systemen für die lokale Speicherung, senden Sie Benachrichtigungen an Benutzer basierend auf Geschäftsregeln, überprüfen Sie die Datenträgernutzung, löschen Sie Waisenkinder und etwa tausend andere Dinge. Sie werden alle von cron verwaltet, wenn sie zu diesem Zeitpunkt überhaupt verwaltet werden. Warum brauchen Sie diese Angaben? Sie können einfach davon ausgehen, dass sie geschäftskritische Funktionen nach einem Zeitplan ausführen.
smp7d
2
Der Grund, warum ich diese Details benötige, ist, dass ich das Problem verstehen muss, um Ihnen bei Ihrem Problem zu helfen. Obwohl Sie bereits viel über diese Aufgaben / Prozesse wissen, weiß ich nicht; Es ist hilfreich, die Art der auszuführenden Aufgaben zu verstehen, wenn bewertet wird, welche technische Lösung am besten funktioniert.
Stephen Gross

Antworten:

17

Wir verwenden Jenkins seit ein paar Jahren als Cron Drop-In, und hier sind einige Vor- und Nachteile:

Vorteile

  • Wenn Sie eine große Anzahl von Prozessen auf Dutzenden von Servern und mehreren Umgebungen verwalten, wird vieles einfacher. Sie erhalten sofort E-Mail-Benachrichtigungen, ein gemeinsames Dashboard für alles, eine Webschnittstelle für Protokolle und eine einfache Möglichkeit, zusätzliche Knoten für die Ausführung von Jobs einzurichten. Support-Teams schätzen vor allem die zentrale Stelle, an der Probleme überprüft und Aufträge erneut ausgeführt werden können.

  • Das Jenkins-Plug-in-Ökosystem ist sehr aktiv und bietet eine Vielzahl zusätzlicher Funktionen ... Ich denke, dies ist wirklich das Mörder-Feature von Jenkins, denn wenn Jenkins selbst nicht das bietet, wonach Sie suchen (häufig der Fall), ist es mehr Oft gibt es ein Plugin, das dies tut. Einige meiner Favoriten: Cron Column, Rebuild, NodeLabel Parameter, Log Parser und Email-ext.

  • Erweiterte Scheduling / Trigger-Unterstützung: Die Scheduling-Syntax ist im Grunde genommen cron, sodass Sie dort die gleiche Flexibilität haben, die jedoch durch Trigger, die REST-API und die Groovy / Java-API ergänzt wird

Nachteile

  • Zentrale Fehlerquelle: Da alle Ihre Jobs von einem Server gestartet werden, wird Big Trouble angezeigt, wenn diese Box ausfällt und niemand etwas davon merkt. So haben Sie eine gute Überwachung, um Ausfälle sofort zu erkennen, sowie alle Ihre Konfigurationen, die in der Quellcodeverwaltung gespeichert sind. Auch wenn Sie den ursprünglichen Server nicht wiederherstellen können, ist es trivial, ihn an einem anderen Ort einzurichten, solange Sie über die Jobkonfigurationen verfügen. Wenn es um die Zeit bis zur Lösung geht, ist es wahrscheinlich auch eine gute Idee, einen Standby-Modus vorkonfiguriert zu haben.

  • In mehreren Umgebungen (Dev, UAT, Prod) werden in der Regel geringfügig unterschiedliche Versionen eines Jobs in jeder Umgebung ausgeführt. Alle diese Jobs auf einem Jenkins zu haben, kann unhandlich werden, und die manuelle Konfiguration dieser Jobs wird zu einem großen Problem. In unserem Fall führen wir für jede Umgebung eine separate Jenkins-Cron-Instanz aus. Die Instanzen werden mithilfe eines internen Bereitstellungstools automatisch installiert und konfiguriert. Möglicherweise haben Sie so etwas nicht, aber es gibt Open-Source-Tools, die ähnliche Aufgaben ausführen (Configs mithilfe von Vorlagen generieren). Wenn Sie das Problem der Konfigurationsgenerierung lösen können, vereinfacht dies das Einrichten und Bereitstellen von Jenkins erheblich und macht es auch einfacher, alle Ihre Inhalte in der Quellcodeverwaltung zu belassen.

  • Ein Upgrade von Jenkins führt manchmal zu Funktionsstörungen, insbesondere bei Plugins. Aktualisieren Sie Ihre geschäftskritische Jenkins-Instanz erst, wenn Sie die neue Version zuerst an einer anderen Stelle ausprobiert haben. Hier bietet sich eine Mirror-Dev-Umgebung mit einer eigenen Jenkins-Instanz an.

Eines ist vielleicht hervorzuheben: Wir verwenden Jenkins zwar auch für CI, aber dies ist eine separate Instanz ... Die 'cron'-Instanzen sind für die Auftragsverwaltung und die' CI'-Instanz für CI reserviert. Die Trennung der Bedenken scheint die Dinge sauberer zu machen.

Als Randnotiz verwende ich Jenkins anstelle von cron auf meiner Linux-Box zu Hause :)

Übrigens ist dies tatsächlich ein ziemlich häufiger Anwendungsfall für Jenkins. Sandia National Lab verwendet Jenkins beispielsweise folgendermaßen: https://software.sandia.gov/trac/fast/wiki/Hudson

Und es gibt zahlreiche Blogposts und Tutorials, die dies beschreiben. Hier einige Beispiele: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

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

Ich sollte auch hinzufügen, dass dies wirklich nur Jenkins betrifft und nicht alle CI-Tools im Allgemeinen. Nur weil Jenkins dafür gut geeignet ist, heißt das nicht, dass andere (TeamCity, Buildbot usw.) ...

Dylan Cali
quelle
8

Ich hätte gesagt, dass Sie hier nicht das richtige Tool für den Job verwenden, da der Hauptgrund für CI-Tools darin besteht, dass sie etwas überwachen - Ihren Quellcode in der Regel - und bei Änderungen einen Build / Deployment / was auch immer starten .

Diese Tools können jedoch geplante Jobs ausführen (z. B. TeamCity), sodass Sie (z. B.) eine Website bereitstellen können, wenn niemand in der Nähe ist. Eine zentrale Liste aller von Ihnen ausgeführten Aufgaben ist daher eine gute Idee. Mit den Tools sollten Sie auch entscheiden können, wann und wie oft diese Jobs ausgeführt werden.

Ein weiterer Vorteil ist, dass Sie das System sogar aus der Ferne überwachen können (falls gewünscht).

Alles in allem würde ich sagen, dass es sinnvoll war, dies zu tun.

ChrisF
quelle
Ihre Gefühle zu diesem Thema spiegeln meine wider. Da CI allgemein für Builds und Tests bekannt ist, sehe ich es als unorthodoxe Lösung an. Die anderen Antworten auf diese Frage haben definitiv gezeigt, dass dies der Fall ist, da viele es offensichtlich als das falsche Werkzeug für den Job ansehen. Da TeamCity diese zusätzlichen Aufgaben ausführen kann, kann jedes CI-Tool, das Maven-Projekte verwendet, eine beliebige Anzahl von Dingen ausführen. Es ist mir immer noch unangenehm, dass es eine gute Idee ist.
smp7d
1
@ smp7d - einverstanden. Es ist eine mögliche Lösung, aber keine ideale Lösung.
ChrisF
6

Es hört sich so an, als wäre cron bereits ein geeignetes Werkzeug für Ihre Bedürfnisse. Ich empfehle Ihnen, zunächst Ihr System besser zu dokumentieren. Prüfen Sie die verschiedenen Systeme und stellen Sie eine umfassende Liste der Prozesse zusammen, die auf welchen Maschinen ausgeführt werden.

Überlegen Sie sich dann, ob Sie einen dedizierten Computer für die Ausführung all dieser Cron-Prozesse festlegen möchten. Vergewissern Sie sich, dass Sie dokumentieren, um welchen Computer es sich handelt, und weisen Sie ihm die entsprechenden Administratorrechte zu, um ihn zu steuern. Platzieren Sie alle Cronjobs auf dieser Maschine, und Sie haben einen zentralen Kontrollpunkt für Ihre verschiedenen automatisierten Prozesse.

Stephen Gross
quelle
2

Meine Bauchreaktion ist die gleiche, dass Sie ein Tool verwenden, das ein Zeitplankonzept enthält, um die Arbeit eines Job Schedulers zu erledigen.

Sie haben nicht erwähnt, was Ihre Jobs sind, aber Ihre Erwähnung von CRON lässt mich vermuten, dass es sich um Shell-Skripte usw. handelt. Es gibt Open-Source- und kommerzielle Job Scheduler-Pakete. Manchmal werden sie als Stapelplaner bezeichnet. Einige werden einfach CRON einpacken und es freundlicher machen. Einige, wie z. B. der Quartz Scheduler, führen eine leistungsstarke Verwaltung von Jobs durch, erfordern jedoch deren Implementierung als Java-Klassen. Sie könnten dies möglicherweise nutzen und die Laufzeitaufrufe für Ihre verschiedenen Skripte mit einem Java-Wrapper abschließen. Ich glaube, Sie werden viele Optionen finden, wenn Sie weiter schauen.

Guerry
quelle
Die Jobs sind eine Mischung aus Skripten in verschiedenen Sprachen, Java-Prozessen und Linux-Befehlen. Quarz allein wird mir nicht das Front-End- / Build-Management geben, das Jenkins bereitstellen würde, und ich möchte das alles nicht bauen. Es würde mich nicht wundern, wenn Jenkins hinter den Kulissen Quarz verwendet. Ich werde mir diesen Quartz Manager anschauen ( terracotta.org/products/quartz-scheduler ).
smp7d
2

Verwenden Sie CI nicht zum Ausführen von regelmäßigen Aufgaben, die nicht mit dem Erstellen zusammenhängen.

Vermeiden Sie auch cron für Aufgaben, die nicht mit der Systemwartung zusammenhängen.

Verwenden Sie die richtigen Werkzeuge. Verwenden Sie für Anwendungsanforderungen AMQP-basierte Lösungen.

PS: Ich verstehe, das passt zu deinem Fall. Andererseits haben Sie eine Menge Aufgaben - versuchen Sie also, eine Supervisor-App für sie zu schreiben.

Nikolay Fominyh
quelle
1
Danke für die Antwort. Können Sie beschreiben, was Sie mit "Supervisor-App" meinen?
smp7d
In wenigen Worten - es ist supervisord.org . Metaprogramm, das den Status und die Ausführung anderer Prozesse steuert. Sie können ganz einfach Ihre eigene Lösung entwickeln, die Ihren Anforderungen entspricht. Ich habe eine Reihe von regelmäßigen Aufgaben in meinem Projekt und github.com/ask/django-celery hilft mir dabei, mich von cron zu lösen.
Nikolay Fominyh
Danke, ich werde mich um Supervisor kümmern. Mit dem CI-Tool wollten wir verhindern, dass wir unser eigenes Tool schreiben müssen. Das CI-Tool ist, wie es schon sein kann, flott.
smp7d
1
Ich schätze, ich habe nicht den Repräsentanten, der das ablehnt, aber es ist eine ziemlich schreckliche Antwort - schade, dass es das Kopfgeld bekommen hat. Was macht ein Werkzeug zum "richtigen Werkzeug"? Auch wenn es genau alle benötigten Komponenten hat, ist es das "falsche Werkzeug", weil es ein CI-System heißt?
DougW
1

Für diese Art von Aufgabe müssen Sie einen Enterprise Service Bus (ESB) verwenden.

Mein Hintergrund ist jetzt Windows / BizTalk, aber ich bin sicher, dass alle Entsprechungen auch auf der Unix-Seite vorhanden sind. Normalerweise richten wir Prozesse in der BizTalk-Box ein, die für den Start der Aktionen in der anderen Box, die Überwachung des Fortschritts / der Fehler und die Rückmeldung des Status an das SharePoint- (oder Web-) Portal oder das Senden von E-Mails und Nachrichten zuständig sind solche, wenn es Aufmerksamkeit braucht.

Der Vorteil dieses Ansatzes besteht darin, dass die gesamte Konfiguration und Verwaltung Ihrer verschiedenen Geschäftsprozesse zentral erfolgt, sodass Sie wissen, wo Sie suchen müssen. Es gibt bereits eine Software, mit der Sie den Codierungsteil von der physischen Konfiguration abstrahieren können (in BizTalk können Sie gegen einen logischen 'Port' wie einen SQL-Server programmieren und dann in Prod, wenn eine SQL-Box den Speicherort ändert oder aktualisiert wird, oder was auch immer) können den konfigurierten physischen Port mit ihrem Admin-Tool ändern (ich bin mir sicher, dass es auf der Unix-Seite Entsprechungen gibt).

Der Vorteil gegenüber der Verwendung von CI-Tools besteht darin, dass Sie bei einem Prozessfehler die Nachrichten automatisch physisch erneut übermitteln und eine Cluster-Failover-Umgebung mit einem besser geeigneten Aufzeichnungs- und Protokollierungssystem einrichten können. Sobald Sie das System eingerichtet haben, können Sie mit der Architektur Ihrer Organisation beginnen, um sie zu verwenden, oder besser SOA verwenden. Der Nachteil ist, dass der Entwicklungsaufwand je nach Größe Ihres Unternehmens hoch und die Lizenzkosten unerschwinglich sein können.

aceinthehole
quelle
Vielleicht trifft dies zu, aber ich bin mir nicht sicher, ob es sich mehr um die Anwendung des falschen Tools handelt, wie es bei CI der Fall wäre. Ich habe den Eindruck, dass ESB verwendet wird, wenn Kommunikation oder Prozesschoreografie benötigt werden. In diesem Fall möchten wir nur eine zentrale Verwaltung für eine Reihe von eigenständigen Prozessen. Wir sind in der Lage, benutzerdefinierte Linux-Befehle über die zentrale Verwaltung auszuführen, daher ist jede Agnostik in Bezug auf Betriebssysteme und Programmiersprachen wahrscheinlich übertrieben. Dies ist wahrscheinlich einen Blick wert, danke.
smp7d
Wenn Sie auf jeden Fall ein Unix-Shop sind, dann ist mir klar, dass IBM ein Produkt in seiner Websphere-Reihe hat, und es gibt auch kommerzielle Webmethoden, und Appache hat ein Open-Source-Angebot. Sie haben im Sinne Ihrer Definition von ESB recht, leider ist die Verwendung von ESB etwas mehrdeutig geworden. Überlegen Sie sich jedoch, ob Sie eventuell eine zentrale Fehlerberichterstattung oder eine Art Berichterstattung, wie sie in Ihrem Prozess ausgeführt wird, hinzufügen möchten Choreografie.
Aceinthehole
@ smp7d Ich weiß, dass webMethods Integration Server erstklassige Planungsunterstützung bietet. Funktioniert gut.
Robert Grant
1

Theoretisch ist es für Sie sinnvoll, alle unterschiedlichen Jobs an einem einzigen Ort zu verwalten. Aufgrund der Branchenerfahrung, die dem "Heiligen Gral" gleicht, benötigen Sie hier jedoch Cron-Jobs, Bash-Skripte und Cli-Skripte.

Es gibt auch ein Mantra: "Wenn es nicht kaputt ist, beheben Sie es nicht". Konzentrieren Sie sich also beim Herumtollen zunächst darauf, zu dokumentieren, welche Skripte Sie ausführen, was sie tun und welche Systeme sie berühren, damit Sie wissen, "was Sie tun "wie Ihr Geschäft läuft.

Wählen Sie dann als langfristige Strategie ein zentrales System für die Ausführung der Jobs aus, und wählen Sie Ihre Lösung mit Bedacht aus, da Sie damit leben müssen. Stellen Sie dann für jede Änderungsanforderung, Erweiterung, Aktualisierung, Fehlerbehebung oder neue Lösung, die Sie in Ihrer Geschäftsarchitektur hinzufügen, sicher, dass die geplanten und automatisierten Aufgaben zu Ihrer "Unternehmenssteuerungslösung" hinzugefügt werden.

Auf diese Weise migrieren Sie schrittweise von einer Reihe von Skripten zu einer unternehmensfreundlicheren Umgebung.

Stephen Senkomago Musoke
quelle
Das sind einige gute Gedanken. Sie denken also, dass das, wonach ich suche, nicht existiert und dass ein CI-Tool keine vernünftige Alternative ist?
smp7d
Es mag existieren, aber Pragmatismus in Bezug auf das, was Sie verwenden, kann dazu führen, dass Sie immer noch Cron-Jobs und Bash-Skripte haben. Die Verwendung Ihrer CI-Umgebung kann jedoch später ein Hindernis sein, da CI in erster Linie für Entwicklungsworkflows vorgesehen ist. Mit zunehmendem Alter der Umgebung suchen Sie jedoch nach betriebsbezogenen Lösungen. Später können Sie entscheiden, Ihre Versionskontrolle / Ihr CI in die Cloud zu verlagern. Sie möchten jedoch nicht, dass die Versionskontrolle festgefahren ist, da sie im Tagesgeschäft Ihres Unternehmens ausgeführt wird.
Stephen Senkomago Musoke
Nun, wir dachten, wir würden ein separates CI-Tool für das Prozessmanagement verwenden, aber ich verstehe, was Sie sagen.
smp7d
Wenn Sie sich ein separates CI ansehen, sollten Sie sich die Tools ansehen, die sich auf Prozessmanagement, Überwachung und Berichterstellung konzentrieren. Auf diese Weise können Sie den Aufwand für die Einrichtung des CI nutzen, um das richtige Tool für den Job zu finden. Wenn dies fehlschlägt, können Sie auf das CI zurückgreifen
Stephen Senkomago Musoke
Ich stimme zu, dass dies der vernünftigste Weg ist. Quartz Scheduler, supervisord.org und ein ESB wurden empfohlen. Haben Sie zusätzliche Empfehlungen oder Gedanken zu diesen? (auch: Als ich separate CI sagte, meinte ich nur eine weitere Installation unseres aktuellen Tools mit vielleicht neuem Branding ... Setup wäre kein Problem)
smp7d
0

In großen Unternehmenssystemen, mit denen ich gearbeitet habe, wird in der Regel ein Tool für die Zeitplanung verwendet. Das beliebteste, das ich verwendet habe, ist CA7. Damit können Sie die gesamte Zeitplanung für alle Ihre Systeme zentralisieren.

Cron wird in der Regel für eine einzelne Maschine verwendet, obwohl Sie es "hacken" können, indem Sie ssh-Fernaufrufe ausführen. Es wird jedoch nicht das Konzept von Abhängigkeiten und anderen Dingen haben. Wenn es um Betriebsteams geht, deren Umfang noch eingeschränkter ist, wird am besten ein Tool verwendet.

Archimedes Trajano
quelle
Ihre Empfehlung hat mich zu diesem ... en.wikipedia.org/wiki/Job_scheduler - Überraschenderweise hat noch niemand diesen Namen für ein solches Tool erwähnt. Dies könnte das sein, wonach ich gesucht habe, als ob es das tun soll, wonach ich suche. Die Zeit wird wahrscheinlich zeigen, dass es besser funktioniert als ein CI-Tool. Es wird allerdings einige Nachforschungen erfordern, um dies zu überprüfen.
smp7d