Eenvoudige Jenkins-pijpleiding met Marathon en Mesos

1. Inleiding

In dit artikel implementeren we een eenvoudige pijplijn voor continue levering met Jenkins, Marathon en Mesos.

Eerst geven we een overzicht op hoog niveau van de technologiestack en architectuur, met uitleg over hoe alles in elkaar past. Daarna gaan we verder met een praktisch, stap voor stap voorbeeld.

Het resultaat hiervan is een volledig geautomatiseerde Jenkins-pijplijn, waarbij onze applicatie met Marathon in ons Mesos-cluster wordt geïmplementeerd.

2. Overzicht van technologiestapel

Bij het werken met containers en microservice-architecturen worden we geconfronteerd met nieuwe operationele problemen die we niet zouden hebben gedaan met meer traditionele stapels.

Bij implementatie in een cluster hebben we bijvoorbeeld te maken met schaalvergroting, failover, netwerken en meer. Deze moeilijke, gedistribueerde computerproblemen kunnen worden opgelost met gedistribueerde kernels en planners, zoals Apache Mesos en Marathon.

2.1. Mesos

Mesos kan, in eenvoudigste bewoordingen, worden gezien als de enige server waarop onze applicaties zullen draaien. In werkelijkheid hebben we een cluster, maar het is deze abstractie die het zo nuttig maakt.

2.2. Marathon

Marathon is het raamwerk dat wordt gebruikt om onze applicaties in Mesos te implementeren en moeilijke problemen voor ons op te lossen (gezondheidscontrole, auto-scaling, failover, monitoring enz.).

3. Configuratie en installatie

In dit artikel wordt ervan uitgegaan dat je al Jenkins, Mesos en Marathon hebt lopen. Als dit niet het geval is, raadpleeg dan de officiële documentatie voor elk van hen om te zien hoe u ze moet instellen. Zonder dit kunt u geen van de stappen in de handleiding implementeren.

4. Onze leveringspijplijn

We zullen de volgende Jenkins-pijplijn maken:

Er is niets bijzonders aan deze aanpak - het is synoniem voor de stroom van de meeste moderne CD-pijplijnen. In ons geval betekent bouwen dat de applicatie wordt gecontaineriseerd, en implementatie betekent dat we Marathon gebruiken om deze op een Mesos-cluster te plannen.

5. Testen en bouwen van onze applicatie

De eerste stap is het bouwen en testen van onze applicatie. Om het simpel te houden, is de applicatie waarmee we gaan werken een Spring Boot-applicatie. Hierdoor zal ons resulterende artefact een uitvoerbare pot zijn. Het heeft geen andere externe afhankelijkheden dan de JRE, waardoor het heel eenvoudig uit te voeren is.

5.1. Onze baan creëren

Het eerste dat we willen doen, is onze Jenkins-baan creëren. Laten we 'Nieuw item' selecteren in de navigatiebalk aan de linkerkant, en vervolgens een freestyle-project maken, met de naam 'marathon-mesos-demo:

5.2. Integreren met Git

Laten we het vervolgens configureren om de Github-repository met onze applicatie te klonen:

Eenvoudigheidshalve is onze repository openbaar, wat betekent dat we over https kunnen klonen. Als dit niet het geval was en we waren aan het klonen via SSH, zou er een extra stap zijn om een ​​SSH-gebruiker en privésleutel in te stellen, buiten het bestek van dit artikel.

5.3. Build-triggers instellen

Laten we vervolgens enkele build-triggers instellen, zodat onze taak elke minuut git vraagt ​​voor nieuwe commits:

5.4. Ons build-script genereren

We kunnen nu onze taak vertellen om een ​​shellscript uit te voeren wanneer het wordt uitgevoerd. Omdat we werken met een eenvoudig Spring Boot Maven-project, hoeven we alleen maar de opdracht 'mvn schone installatie“. Hiermee worden alle tests uitgevoerd en onze uitvoerbare jar gebouwd:

5.5. Ons project bouwen

Nu we het begin van onze pijplijn hebben ingesteld, kunnen we deze handmatig activeren door op de taak op "Nu bouwen" te klikken. Zodra de klus is geklaard, kunnen we bevestigen dat de klus is gepasseerd door te worden gemarkeerd als blauw.

6. Containeriseren van onze applicatie

Laten we naar de volgende fase van onze pijplijn gaan, namelijk het verpakken en publiceren van onze applicatie met Docker. We moeten Docker gebruiken omdat containers specifiek zijn wat Marathon beheert. Dit is niet onredelijk, aangezien vrijwel alles in een container kan lopen. Het is gemakkelijker voor een tool als Marathon om te werken met de abstractie die deze biedt.

6.1. Het Dockerfile

Laten we eerst een Dockerfile maken in de projectroot. In wezen is een Dockerfile een bestand met instructies voor de Docker Deamon over het maken van een image:

FROM openjdk: 8-jre-alpine ADD target / mesos-marathon-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8082 ENTRYPOINT ["java", "- jar", "/ app.jar"]

De afbeelding die we aan het bouwen zijn, is eenvoudig - het bevat alleen een uitvoerbare jar en een shell-commando dat het zal uitvoeren wanneer de container start. We moeten er ook voor zorgen dat we de poort tonen waarop onze applicatie zal luisteren, in dit geval '8082'.

6.2. Publiceren van de afbeelding

Nu we in staat zijn om onze afbeelding te bouwen, laten we een eenvoudig bash-script maken dat het bouwt en publiceert naar onze privé Docker Hub-repository, en het in onze projectroot plaatsen:

#! / usr / bin / env bash set -e docker login -u baeldung -p $ DOCKER_PASSWORD docker build -t baeldung / mesos-marathon-demo: $ BUILD_NUMBER. docker push baeldung / mesos-marathon-demo: $ BUILD_NUMBER 

Mogelijk moet u uw afbeelding naar het openbare docker-register of uw privé-register pushen.

De $ BUILD_NUMBER omgevingsvariabele wordt gevuld door Jenkins en wordt bij elke build verhoogd. Hoewel het enigszins broos is, is het een snelle manier om elke build in versienummer te laten toenemen. De $ DOCKER_PASSWORD wordt ook gevuld door Jenkins, en in dit geval zullen we de EnvInject-plug-in gebruiken om deze geheim te houden.

Hoewel we dit script rechtstreeks in Jenkins zouden kunnen opslaan, is het beter om het in versiebeheer te houden, aangezien het dan samen met de rest van ons project kan worden bewerkt en gecontroleerd.

6.3. Bouwen en publiceren op Jenkins

Laten we nu onze Jenkins-taak aanpassen zodat deze "Dockerise.sh" uitvoert na het bouwen van de jar:

En laten we dan onze taak uitvoeren om opnieuw te bevestigen, door te bevestigen dat alles werkt door blauw te worden.

7. Ons imago inzetten

Onze pijplijn is bijna voltooid. Er is nog maar één fase en dat is om Marathon te gebruiken om onze applicatie in ons Mesos-cluster te implementeren.

Jenkins wordt geleverd met een plug-in "Deploy with Marathon". Dit fungeert als een wrapper rond de Marathon API, waardoor het gemakkelijker wordt dan wanneer je met traditionele shell-scripts zou werken. U kunt het installeren via de plugin-manager.

7.1. Ons Marathon.Json-bestand maken

Voordat we de Marathon-plug-in kunnen gebruiken, moeten we een "marathon.json" -bestand maken en dit opslaan in onze projectroot. Dit komt doordat de plug-in hiervan afhankelijk is.

Dit bestand: “marathon.json” bevat een Mesos-toepassingsdefinitie. Dit is een beschrijving van een langlopende service (applicatie) die we willen draaien. Uiteindelijk zal de Jenkins Marathon-plug-in de inhoud van het bestand naar de Marathon POST / v2 / apps eindpunt. Marathon plant dan op zijn beurt de gedefinieerde applicatie om op Mesos te draaien:

{"id": "mesos-marathon-demo", "container": {"type": "DOCKER", "docker": {"image": "", "network": "BRIDGE", "portMappings": [{"containerPort": 8082, "hostPort": 0}]}}}

Dit is de eenvoudigste configuratie die we kunnen geven voor een gecontaineriseerde applicatie.

Het eigendom: "portMappings”Moet correct worden ingesteld om onze applicatie toegankelijk te maken vanaf onze Mesos-slaaf. Het betekent in feite, de containerhaven in kaart brengen 8082, naar een willekeurige poort op de host (mesos-slaaf) zodat we vanuit de buitenwereld met onze applicatie kunnen praten. Na het implementeren van onze applicatie, zal Marathon ons vertellen wat die poort heeft gebruikt.

7.2. Een bouwstap voor marathonimplementatie toevoegen

Laten we een post-build-actie voor Marathon-implementatie aan ons werk toevoegen:

Merk op dat we de plug-in vertellen waar Marathon actief is, in dit geval ‘localhost: 8081 '. We vertellen het ook het imago dat we willen inzetten. Dit is waar het lege veld "afbeelding" in ons bestand door wordt vervangen.

Nu we de laatste fase van onze pijplijn hebben gemaakt, laten we ons werk nog een keer uitvoeren en bevestigen dat het nog steeds voorbij is, dit keer met de extra stap waarbij het onze aanvraag naar Marathon stuurt.

7.3. Onze implementatie in Marathon verifiëren

Nu het is geïmplementeerd, laten we eens kijken in de Marathon-gebruikersinterface:

Zoals we kunnen zien, wordt onze applicatie nu weergegeven in de gebruikersinterface. Om er toegang toe te krijgen, hoeven we alleen maar te controleren aan welke host en poort deze is toegewezen:

In dit geval is willekeurig de poort 31143 op localhost toegewezen, die intern wordt toegewezen aan poort 8082 in onze container zoals geconfigureerd in de toepassingsdefinitie. We kunnen deze URL vervolgens in onze browser bezoeken om te bevestigen dat de applicatie correct wordt bediend.

8. Conclusie

In dit artikel hebben we een eenvoudige pijplijn voor continue levering gemaakt met Jenkins, Marathon en Mesos. Elke keer dat we een wijziging in onze code pushen, wordt deze een paar minuten later in een omgeving uitgevoerd.

Latere artikelen in deze serie zullen meer geavanceerde Marathon-onderwerpen behandelen, zoals gezondheidscontrole van toepassingen, schalen en failover. Andere use-cases voor Mesos, zoals batchverwerking, kunnen ook worden gedekt.

De broncode voor onze applicatie is beschikbaar op meer dan op GitHub; dit is een Maven-project dat zou moeten kunnen draaien zoals het is.


$config[zx-auto] not found$config[zx-overlay] not found