Einfache Jenkins-Pipeline mit Marathon und Mesos
1. Einführung
In diesem Artikel implementieren wir eine einfache Continuous Delivery-Pipeline mitJenkins,Marathon undMesos.
Zunächst geben wir einen allgemeinen Überblick über den Technologie-Stack und die Architektur und erklären, wie alles zusammenpasst. Anschließend gehen wir Schritt für Schritt zu einem praktischen Beispiel über.
Das Ergebnis ist eine vollautomatisierte Jenkins-Pipeline, die unsere Anwendung mithilfe von Marathon auf unserem Mesos-Cluster bereitstellt.
2. Übersicht über den Technologie-Stack
Bei der Arbeit mit Containern und Microservice-Architekturen treten neue betriebliche Probleme auf, die wir mit herkömmlichen Stacks nicht hätten lösen können.
Bei der Bereitstellung in einem Cluster müssen wir uns beispielsweise mit Skalierung, Failover, Netzwerk und mehr befassen. Diese schwierigen, verteilten Computerprobleme können mit verteilten Kerneln und Schedulern wie Apache Mesos und Marathon gelöst werden.
2.1. Mesos
Mesos kann im einfachsten Sinne als der einzige Server angesehen werden, auf dem unsere Anwendungen ausgeführt werden. In Wirklichkeit haben wir einen Cluster, aber diese Abstraktion macht ihn so nützlich.
2.2. Marathon
Marathon ist das Framework, mit dem wir unsere Anwendungen auf Mesos bereitstellen und schwierige Probleme für uns lösen (Integritätsprüfung, automatische Skalierung, Failover, Überwachung usw.).
3. Einrichtung und Installation
In diesem Artikel wird davon ausgegangen, dass Sie bereits über Jenkins, Mesos und Marathon verfügen. Ist dies nicht der Fall, lesen Sie die offiziellen Dokumentationen der einzelnen Benutzer, um zu erfahren, wie sie eingerichtet werden. Ohne dies können Sie keinen der Schritte im Handbuch ausführen.
4. Unsere Lieferpipeline
Wir werden die folgende Jenkins-Pipeline erstellen:
Dieser Ansatz ist nicht besonders komplex - er ist gleichbedeutend mit dem Fluss der meisten modernen CD-Pipelines. In unserem Fall bedeutet das Erstellen eines Containers das Containerisieren der Anwendung und das Bereitstellen mithilfe von Marathon, um sie auf einem Mesos-Cluster zu planen.
5. Testen und Erstellen unserer Anwendung
Der erste Schritt ist das Erstellen und Testen unserer Anwendung. Zur Vereinfachung ist die Anwendung, mit der wir arbeiten, eine Spring Boot-Anwendung. Aus diesem Grund wird unser resultierendes Artefakt ein ausführbares Glas sein. Es gibt keine anderen externen Abhängigkeiten als die JRE, was die Ausführung sehr einfach macht.
5.1. Unseren Job schaffen
Als erstes wollen wir unseren Jenkins-Job schaffen. Wählen Sie in der linken Navigationsleiste "Neues Element" aus und wählen Sie "Freestyle-Projekt erstellen" mit dem Namen "marathon-mesos-demo":
5.2. Integration mit Git
Als nächstes konfigurieren wir es aufclone the Github repository, die unsere Anwendung enthalten:
Der Einfachheit halber ist unser Repository öffentlich, was bedeutet, dass wir über https. klonen können. Wenn dies nicht der Fall wäre und wir über SSH klonen würden, gäbe es einen zusätzlichen Schritt zum Einrichten eines SSH Benutzer und privater Schlüssel, die über den Rahmen dieses Artikels hinausgehen.
5.3. Einrichten von Build-Triggern
Als Nächstes richten wir einige Build-Trigger ein, damit unser Job jede Minute git nach neuen Commits abfragt:
5.4. Generieren unseres Build-Skripts
Wir können unseren Job jetzt anweisen, ein Shell-Skript auszuführen, wenn es ausgeführt wird. Da wir mit einem einfachen Spring Boot Maven-Projekt arbeiten, müssen wir nur den Befehl „mvn clean install“ ausführen. Dadurch werden alle Tests ausgeführt und unsere ausführbare JAR: erstellt
5.5. Aufbau unseres Projekts
Nachdem wir den Anfang unserer Pipeline eingerichtet haben, können Sie ihn manuell auslösen, indem Sie im Job auf "Jetzt erstellen" klicken. Sobald der Auftrag abgeschlossen ist, können wir bestätigen, dass er bestanden wurde, indem er als blau markiert wird.
6. Containerisierung unserer Anwendung
Fahren wir mit der nächsten Phase unserer Pipeline fort, in der wir unsere Anwendung in Docker verpacken und veröffentlichen. Wir müssen Docker verwenden, da Container genau das sind, was Marathon verwaltet. Dies ist nicht unangemessen, da praktisch alles in einem Container ausgeführt werden kann. Für ein Tool wie Marathon ist es einfacher, mit der von diesen gewährten Abstraktion zu arbeiten.
6.1. Dockerfile erstellen
Zuerst erstellen wir einDockerfile im Projektstamm. Im Wesentlichen ist eine Docker-Datei eine Datei, die Anweisungen zum Erstellen eines Images für Docker Deamon enthält:
FROM openjdk:8-jre-alpine
ADD target/mesos-marathon-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8082
ENTRYPOINT ["java","-jar","/app.jar"]Das Image, das wir erstellen, ist einfach - alles, was es enthält, ist ein ausführbares Jar und ein Shell-Befehl, der es ausführt, wenn der Container startet. Wir müssen auch sicherstellen, dass wir den Port freigeben, auf dem unsere Anwendung empfangsbereit ist, in diesem Fall "8082".
6.2. Veröffentlichen des Bildes
Nachdem wir unser Image erstellen können, erstellen wir ein einfaches Bash-Skript, das es erstellt, im Repository unseres privatenDocker Hubveröffentlicht und in unser Projektstammverzeichnis einfügt:
#!/usr/bin/env bash
set -e
docker login -u example -p $DOCKER_PASSWORD
docker build -t example/mesos-marathon-demo:$BUILD_NUMBER .
docker push example/mesos-marathon-demo:$BUILD_NUMBERMöglicherweise müssen Sie Ihr Bild an die öffentliche oder private Docker-Registrierung senden.
Die Umgebungsvariable$BUILD_NUMBERwird von Jenkins gefüllt und mit jedem Build erhöht. Obwohl es leicht spröde ist, ist es eine schnelle Möglichkeit, die Versionsnummer jedes Builds zu erhöhen. Das$DOCKER_PASSWORD wird auch von Jenkins gefüllt, und in diesem Fall werden wir dasEnvInject plugin verwenden, um es geheim zu halten.
Obwohl wir dieses Skript direkt in Jenkins speichern können, ist es besser, es in der Versionskontrolle zu belassen, da es dann zusammen mit dem Rest unseres Projekts versioniert und geprüft werden kann.
6.3. Aufbau und Veröffentlichung auf Jenkins
Ändern wir nun unseren Jenkins-Job so, dass nach dem Erstellen des JARs "Dockerise.sh" ausgeführt wird:
Lassen Sie uns dann unseren Job ausführen, um ihn erneut zu bestätigen und zu bestätigen, dass alles funktioniert, indem er blau wird.
7. Bereitstellen unseres Images
Unsere Pipeline ist fast abgeschlossen. Es gibt nur noch eine Phase: Verwenden Sie Marathon, um unsere Anwendung in unserem Mesos-Cluster bereitzustellen.
Jenkins wird mit einem Plugin "https://wiki.jenkins-ci.org/display/JENKINS/Marathon+Plugin[Deploy with Marathon]" geliefert. Dies dient als Wrapper für die Marathon-API und vereinfacht die Arbeit mit herkömmlichem Shell-Scripting. Sie können es über den Plugin-Manager installieren.
7.1. Erstellen unserer Marathon.Json-Datei
Bevor wir das Marathon-Plugin verwenden können, müssen wir eine „marathon.json“ -Datei erstellen und in unserem Projektstamm speichern. Dies liegt daran, dass das Plugin davon abhängig ist.
Diese Datei: "marathon.json" enthält einMesos Application Definition. Dies ist eine Beschreibung eines langfristigen Dienstes (einer Anwendung), den wir ausführen möchten. Letztendlich wird das Jenkins Marathon-Plugin den Inhalt der Datei auf den Endpunkt des Marathon/v2/appsPOSTEN. Marathon plant dann wiederum die Ausführung der definierten Anwendung auf Mesos:
{
"id": "mesos-marathon-demo",
"container": {
"type": "DOCKER",
"docker": {
"image": "",
"network": "BRIDGE",
"portMappings": [
{ "containerPort": 8082, "hostPort": 0 }
]
}
}
}Dies ist die einfachste Konfiguration, die wir für eine containerisierte Anwendung geben können.
Die Eigenschaft: "portMappings" muss korrekt eingestellt sein, damit unsere Anwendung von unserem Mesos-Slave aus zugänglich ist. Grundsätzlich bedeutet dies, dass der Container-Port8082 einem zufälligen Port auf dem Host (Mesos-Slave) zugeordnet wird, damit wir von außen mit unserer Anwendung sprechen können. Nach der Bereitstellung Ihrer Anwendung teilt Marathon uns mit, welcher Port verwendet wurde.
7.2. Hinzufügen eines Marathon Deployment Build-Schritts
Fügen wir unserem Job eine Marathon-Bereitstellungsaktion nach dem Erstellen hinzu:
Beachten Sie, dass wir dem Plugin mitteilen, wo Marathon ausgeführt wird, in diesem Fall "localhost: 8081". Wir teilen ihm auch das Image mit, das wir bereitstellen möchten. Dies ist, durch was das leere "Bild" -Feld in unserer Datei ersetzt wird.
Jetzt haben wir die letzte Phase unserer Pipeline erstellt. Lassen Sie uns unseren Job noch einmal ausführen und bestätigen, dass er noch nicht abgeschlossen ist. Diesmal mit dem zusätzlichen Schritt, in dem unsere Bewerbung an Marathon gesendet wird.
7.3. Überprüfung unserer Bereitstellung in Marathon
Nachdem es bereitgestellt wurde, werfen wir einen Blick auf die Marathon-Benutzeroberfläche:
Wie wir sehen können, wird Ihre Anwendung nicht in der Benutzeroberfläche angezeigt. Um darauf zuzugreifen, müssen wir nur überprüfen, welchem Host und Port es zugewiesen wurde:
In diesem Fall wurde dem Port 31143 auf localhost zufällig zugewiesen, der intern dem Port 8082 in unserem Container zugeordnet wird, wie in der Anwendungsdefinition konfiguriert. Wir können diese URL dann in Ihrem Browser aufrufen, um zu bestätigen, dass die Anwendung ordnungsgemäß bereitgestellt wird.
8. Fazit
In diesem Artikel haben wir eine einfache Continuous Delivery-Pipeline mit Jenkins, Marathon und Mesos erstellt. Wann immer wir eine Änderung an unserem Code vornehmen, wird dieser einige Minuten später in einer Umgebung ausgeführt.
In späteren Artikeln dieser Reihe werden weiterführende Marathon-Themen behandelt, z. B. Überprüfung des Anwendungszustands, Skalierung und Failover. Andere Anwendungsfälle für Mesos, wie die Stapelverarbeitung, können ebenfalls abgedeckt werden.
Der Quellcode für unsere Anwendung ist aufover on GitHub verfügbar. Dies ist ein Maven-Projekt, das so ausgeführt werden sollte, wie es ist.