streamalism.org

1. Introduktion

I denne artikel implementerer vi en simpel pipeline for kontinuerlig levering med Jenkins, Marathon og Mesos.

Først vil vi give et overblik på højt niveau af teknologiestakken og arkitekturen med en forklaring på, hvordan alt passer sammen. Herefter går vi videre til et praktisk trin for trin-eksempel.

Resultatet af dette vil være en fuldautomatisk Jenkins-pipeline, der implementerer vores applikation til vores Mesos-klynge ved hjælp af Marathon.

2. Oversigt over Technology Stack

Når vi arbejder med containere og mikroservicearkitekturer, står vi over for nye driftsproblemer, som vi ikke ville have gjort med mere traditionelle stakke.

For eksempel, når vi implementerer i en klynge, skal vi håndtere skalering, failover, netværk og mere. Disse vanskelige, distribuerede computerproblemer kan løses med distribuerede kerner og planlæggere, som Apache Mesos og Marathon.

2.1. Mesos

Mesos kan i de enkleste termer ses som den enkelte server, hvor vores applikationer køres. I virkeligheden har vi en klynge, men det er denne abstraktion, der gør den så nyttig.

2.2. Marathon

Marathon er den ramme, der bruges til at distribuere vores applikationer til Mesos og løse vanskelige problemer for os (sundhedstjek, automatisk skalering, failover, overvågning osv.).

3. Opsætning og installation

Denne artikel antager, at du allerede har Jenkins, Mesos og Marathon i gang. Hvis dette ikke er tilfældet, skal du konsultere den officielle dokumentation for hver af dem for at lære at konfigurere dem. Uden dette kan du ikke implementere nogen af ​​trinene i guiden.

4. Vores leveringsrørledning

Vi opretter følgende Jenkins-pipeline:

Der er ikke noget særligt komplekst ved denne tilgang - det er synonymt med strømmen af ​​de fleste moderne cd-rørledninger. I vores tilfælde betyder bygning at containerisere applikationen, og implementering betyder at bruge Marathon til at planlægge den i en Mesos-klynge.

5. Test og opbygning af vores applikation

Det første trin er at opbygge og teste vores ansøgning. For at holde tingene enkle er den applikation, vi skal arbejde med, en Spring Boot-applikation. På grund af dette vil vores resulterende artefakt være en eksekverbar krukke. Det vil ikke have andre eksterne afhængigheder end JRE, hvilket gør det meget simpelt at udføre.

5.1. Oprettelse af vores job

Den første ting, vi vil gøre, er at oprette vores Jenkins-job. Lad os vælge "Nyt element" i venstre navigationslinje, og vælg derefter Opret et freestyle-projekt med navnet "marathon-mesos-demo“:

5.2. Integrering med Git

Lad os derefter konfigurere det til at klone Github-arkivet, der indeholder vores applikation:

Af enkelheds skyld er vores arkiv offentligt, hvilket betyder, at vi er i stand til at klone over https. Hvis dette ikke var tilfældet, og vi klonede over SSH, ville der være et yderligere trin til at oprette en SSH-bruger og en privat nøgle uden for denne artikels anvendelsesområde.

5.3. Opsætning af Build Triggers

Lad os derefter oprette nogle build-udløsere, så vores job vil afstemme git for nye forpligtelser hvert minut:

5.4. Generering af vores Build Script

Vi kan nu fortælle vores job at udføre et shell-script, når det kører. Da vi arbejder med et simpelt Spring Boot Maven-projekt, er alt, hvad vi skal gøre, at køre kommandoen “mvn ren installation“. Dette kører alle testene og bygger vores eksekverbare jar:

5.5. Opbygning af vores projekt

Nu har vi oprettet begyndelsen på vores pipeline, lad os udløse den manuelt ved at klikke på "Byg nu" på jobbet. Når jobbet er afsluttet, kan vi bekræfte, at det er bestået, ved at det er markeret som blåt.

6. Containere vores ansøgning

Lad os gå videre til den næste fase af vores pipeline, som er emballering og offentliggørelse af vores applikation med Docker. Vi er nødt til at bruge Docker, da containere specifikt er, hvad Marathon administrerer. Dette er ikke urimeligt, da stort set alt kan køre i en container. Det er lettere for et værktøj som Marathon at arbejde med den abstraktion, som disse giver.

6.1. Oprettelse af Dockerfile

Lad os først oprette en Dockerfile i projektets rod. I det væsentlige er en Dockerfile en fil, der indeholder instruktioner til Docker Deamon om, hvordan man bygger et billede:

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

Det billede, vi bygger, er simpelt - alt det indeholder er en eksekverbar krukke og en shell-kommando, der udfører det, når containeren starter. Vi er også nødt til at sikre os, at vi udsætter den port, som vores applikation vil lytte til, i dette tilfælde '8082'.

6.2. Udgivelse af billedet

Nu hvor vi er i stand til at opbygge vores billede, lad os oprette et simpelt bash-script, der bygger og udgiver det til vores private Docker Hub-arkiv og lægger det i vores projektrod:

#! / 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 

Det kan være nødvendigt at skubbe dit billede til den offentlige docker-registreringsdatabase eller din private.

Det $ BUILD_NUMBER miljøvariablen er befolket af Jenkins, der øges med hver build. Selvom det er lidt skørt, er det en hurtig måde at få hver build til at stige i versionsnummer. Det $ DOCKER_PASSWORD er også befolket af Jenkins, og i dette tilfælde bruger vi EnvInject-pluginet for at holde det hemmeligt.

Mens vi kunne gemme dette script direkte i Jenkins, er det bedre praksis for det at forblive i versionskontrol, da det derefter kan versioneres og revideres sammen med resten af ​​vores projekt.

6.3. Bygning og udgivelse på Jenkins

Lad os nu ændre vores Jenkins-job, så det kører "Dockerise.sh" efter at have bygget krukken:

Og så lad os køre vores job for at bekræfte igen og bekræfte, at alt fungerer, ved at det går blåt.

7. Implementering af vores image

Vores rørledning er næsten færdig. Der er kun endnu et trin, nemlig at bruge Marathon til at implementere vores applikation i vores Mesos-klynge.

Jenkins leveres med et "Deploy with Marathon" plugin. Dette fungerer som en indpakning omkring Marathon API, hvilket gør det lettere, end det ville være, når du arbejder med traditionel shell-scripting. Du kan installere det via plugin manager.

7.1. Oprettelse af vores Marathon.Json-fil

Inden vi kan bruge Marathon-pluginet, skal vi oprette en "marathon.json" -fil og gemme den i vores projektrod. Dette skyldes, at pluginet er afhængigt af det.

Denne fil: "marathon.json" indeholder en Mesos-applikationsdefinition. Dette er en beskrivelse af en langvarig tjeneste (applikation), som vi vil køre. I sidste ende vil Jenkins Marathon-pluginet POST indholdet af filen til Marathon / v2 / apps slutpunkt. Marathon planlægger derefter den definerede applikation til at køre på Mesos:

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

Dette er den enkleste konfiguration, vi kan give til en containeriseret applikation.

Ejendommen: "portMappings”Skal indstilles korrekt for at gøre vores applikation tilgængelig fra vores Mesos-slave. Det betyder dybest set, kort containerporten 8082, til en tilfældig port på værten (mesoslave), så vi kan tale med vores ansøgning fra omverdenen. Efter implementeringen af ​​vores applikation fortæller Marathon os, hvad den havn brugte.

7.2. Tilføjelse af et Marathon-implementeringstrin

Lad os tilføje en Marathon Deployment post build-handling til vores job:

Bemærk, at vi fortæller pluginet, hvor Marathon kører, i dette tilfælde 'localhost: 8081'. Vi fortæller det også det billede, vi vil implementere. Dette er, hvad det tomme "billede" -felt i vores fil bliver erstattet med.

Nu har vi oprettet den sidste fase af vores pipeline, lad os køre vores job endnu en gang og bekræfte, at det stadig går, denne gang med det ekstra trin, hvor det sender vores ansøgning til Marathon.

7.3. Bekræftelse af vores implementering i maraton

Nu er det blevet implementeret, lad os se på Marathon UI:

Som vi kan se, vises vores ansøgning nu i brugergrænsefladen. For at få adgang til det skal vi bare kontrollere, hvilken vært og port det er tildelt:

I dette tilfælde er det tilfældigt tildelt porten 31143 på localhost, som internt kortlægges til port 8082 i vores container som konfigureret i applikationsdefinitionen. Vi kan derefter besøge denne URL i vores browser for at bekræfte, at applikationen serveres korrekt.

8. Konklusion

I denne artikel har vi oprettet en simpel pipeline for kontinuerlig levering ved hjælp af Jenkins, Marathon og Mesos. Hver gang vi skubber til en ændring af vores kode, kører den i et miljø et par minutter senere.

Senere artikler i denne serie vil dække mere avancerede Marathon-emner, såsom sundhedskontrol af applikationer, skalering, failover. Andre brugssager til Mesos, såsom batchbehandling, kan også være omfattet.

Kildekoden til vores applikation er tilgængelig på over på GitHub; dette er et Maven-projekt, som skal kunne køre som det er.