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

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.

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

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.

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.

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.

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.

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.

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.

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.