Share
In dit tweede en laatste deel van de serie zullen we de Jenkins Workflow-plug-in bekijken als een oplossing voor het opzetten van meer complexe Jenkins-pijpleidingen.
We gaan verder waar het eerste deel van de serie was gebleven. In deel een heeft Jeff Reifman je begeleid bij het opzetten van een Jenkins-instantie op Digital Ocean en het maken van je eerste Jenkins-build. Als u dit nog niet hebt gelezen, raad ik u aan dit te doen voordat u doorgaat. Het is goed, ik wacht. Ik kan heel geduldig zijn ...
... Alles ingehaald? Super goed! Laten we dit doen.
Jenkins Workflow is een plug-in voor Jenkins. Na installatie komt er een nieuw itemtype beschikbaar: een "Workflow". Workflow-projecten kunnen voor dezelfde doeleinden worden gebruikt als reguliere "Freestyle" Jenkins-projecten, maar ze kunnen ook veel grotere taken orkestreren die meerdere projecten kunnen omvatten en zelfs meerdere werkruimten in één workflow maken en beheren. Bovendien kan al dit beheer worden georganiseerd in een enkel script, in plaats van verspreid over een verzameling configuraties, projecten en stappen.
Voordat we Workflows kunnen gaan bouwen, moeten we de Jenkins Workflow-plug-in installeren. Klik vanuit het Jenkins-dashboard op Beheer Jenkins, dan Beheer plug-ins. Schakel over naar de Beschikbaar tab en zoek naar "Workflow".
Vink het vakje aan voor Workflow-plug-in, dan Installeren zonder herstarten.
Nu, hier is de vangst. Er zijn meerdere plug-ins genaamd "Workflow-plug-in", dus u moet de bovenstaande stappen verschillende keren herhalen. U kunt ook op meerdere checkboxes klikken of de plug-in Workflow Aggregator installeren.
Zodra "Workflow Plugin" niet langer in de lijst met beschikbare plug-ins verschijnt, ga je gang en start je Jenkins opnieuw door te navigeren naar /herstarten en klikken Ja.
Laten we onze Workflow-voeten nat maken. We nemen het project dat Jeff in deel een heeft opgezet en bouwen het als een workflow.
Ga om te beginnen naar het Jenkins-dashboard en klik op Nieuw item. Geef het nieuwe item de naam "Shell-test (werkstroom)" en selecteer de workflow type.
Klik OK om het nieuwe project te maken. Je komt terecht op de configuratiepagina van het project.
U zult merken dat de configuratie-opties afwijken van standaard Jenkins-projecten. Er zijn niet langer opties om een GitHub-repo toe te voegen, stappen te bouwen of acties na het bouwen te maken. In plaats daarvan is er een nieuw gedeelte genaamd workflow.
In het gedeelte Werkstroom is een tekstvak met het label Script. Hier definieert u het workflow-script dat Jenkins zal uitvoeren wanneer het een build van het project initialiseert.
"Welk type script?" Vraagt u. Uitstekende vraag. De Jenkins-workflow-plug-in gebruikt de taal Groovy voor zijn scripts. Groovy is een veelzijdige scripttaal voor de JVM. Maak je geen zorgen, je hoeft niet echt Groovy of Java te kennen om dingen te laten werken - de Jenkins Workflow-plug-in gebruikt een kleine DSL op Groovy en het is heel eenvoudig om opdrachten te combineren om je projectworkflow uit te bouwen.
Ga je gang en voeg het volgende toe aan het scriptvak:
java node git 'https://github.com/redhotvengeance/hello-jenkins.git' sh 'uptime'
Dus wat gebeurt hier hier?
Ten eerste openen we een knooppunt blok. Knopen zijn waar workflow-acties plaatsvinden. Wanneer u een knooppunt, een nieuwe werkruimte (een context / map) wordt gemaakt. Alle code binnen de knooppunt blok wordt uitgevoerd binnen die werkruimte. Dit helpt ervoor te zorgen dat build-stappen elkaar niet vervuilen.
Vervolgens voeren we een Git-commando uit met git 'https://github.com/redhotvengeance/hello-jenkins.git'. Dit commando klonen de Git repo in onze werkruimte.
Ten slotte vertellen we Workflow dat het moet worden uitgevoerd uptime shell commando met 'uptime'.
Klik Opslaan, en u wordt naar de bestemmingspagina van het project geleid. In het linker menu staat een knop met het label Bouw nu. Klik erop om een build te starten.
Zodra de build is voltooid, klikt u op build # 1 gevonden in de Bouw geschiedenis sectie. Dan klikken Console uitvoer in het linker menu.
Hier kunnen we alles zien dat is vastgelegd terwijl de build werd uitgevoerd. Het begon met het toewijzen van een knooppunt in de werkruimte "Shell Test (Workflow)". Vervolgens is de Git-repo opgehaald. Ten slotte heeft het de uptime shellscript, dat de server-uptime-statistieken afdrukte.
En dat is het! We hebben nu dezelfde stappen opnieuw gemaakt als de normale Jenkins-projectinstallatie in deel één, behalve deze keer als een workflow. Laten we nu dezelfde concepten gebruiken om iets complexers te doen.
Voordat we onze complexe workflow kunnen maken, hebben we het werk nodig dat er doorheen gaat. Nep-project (en) om te redden!
Omdat we Groovy al gebruiken voor het schrijven van onze Workflow, gebruiken we Gradle voor onze nep-projecten. Gradle is een build-systeem dat gebruik maakt van Groovy (verrassend, ik weet het!). Om Gradle te gebruiken, moeten we het op onze server installeren. SSH op je server (bekijk Jeff's deel één als je je geheugen moet vernieuwen) en voer het volgende uit:
shell sudo apt-get install gradle
Daar - we zijn goed om te gaan.
We zullen twee repo's gebruiken in onze nieuwe workflow. De eerste is de bouwer. Ons bouwproject is heel eenvoudig - het bevat een Gradle-build-script met de volgende code:
groovy taak createBuild << new File("built.txt").write("You cannot pass.\n")
Wat is hier aan de hand? Gradle werkt door "taken" uit te voeren, en het Grading Build-script definieert deze taken. We hebben een taak gedefinieerd met de naam createBuild, en wat het doet is een tekstbestand maken met de naam built.txt met de inhoud:
Je kunt het niet halen.
Dat is het. (Nou, ik deed zeg dat het eenvoudig was!)
De tweede Git-repo is onze packager. De packager heeft ook een Gradle Build-script, maar het is een beetje ingewikkelder:
groovy taak createPackage << String packageText = "I am a servant of the Secret Fire, wielder of the flame of Anor. You cannot pass. The dark fire will not avail you, flame of Udûn. Go back to the Shadow!" String builtText = new File('built.txt').text new File("package.txt").write(packageText + "\n\n" + builtText)
De createPackage taak maakt ook een tekstbestand (genaamd package.txt), maar er wordt verwacht inhoud van te gebruiken built.txt, welke niet bestaat in de repo van de verpakker. Als built.txt bestond in de repo, de gegenereerde package.txt zou bevatten:
Ik ben een dienaar van het Geheime Vuur, bestuurder van de vlam van Anor. Je kunt het niet halen. Het duistere vuur zal u niet baten, vuur van Udûn. Ga terug naar de schaduw!
Je kunt het niet halen.
Als built.txt is vermist, onze createPackage taak zal een fout veroorzaken.
Dus elke keer dat we onze packager bouwen, moeten we eerst onze builder uitvoeren en de resulterende maken built.txt beschikbaar voor de verpakker, zodat deze kan creëren package.txt.
En dat is precies wat we gaan doen om een Jenkins-workflow op te zetten!
Ga naar het Jenkins-dashboard, klik Nieuw item, noem het "Assembler", selecteer workflow, en klik OK.
Laten we beginnen met scripten. Eerst stellen we een knooppunt blokkeren, net als eerder:
"java node
"
Laten we vervolgens de opbouw van onze builder repo klonen:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
Nu moeten we ons Gradle Build-script uitvoeren om het te genereren built.txt het dossier:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'
Laten we tot slot zeker weten dat alles werkt zoals we verwachten. We voegen een toe kat om de inhoud van de built.txt het dossier:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'
Klik Opslaan, en start dan een build. Als het klaar is, kijk eens naar de Console uitvoer.
Uitstekend! We zijn bezig met het klonen van de repo, het uitvoeren van de createBuild taak, en hebben bevestigd dat de inhoud van built.txt is Je kunt het niet halen.. Nu naar de verpakker.
Net als met de bouwer moeten we onze repository voor packers klonen. Laten we de packagercode toevoegen:
"java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'
node git 'https://github.com/redhotvengeance/jenkins-workflow-package.git' sh 'gradle createPackage' sh 'cat ./package.txt' "
Omdat we niet expliciet een nieuwe werkruimte hebben gemaakt, is de createPackage taak wordt uitgevoerd in dezelfde werkruimte als de createBuild taak, wat betekent dat de built.txt bestand dat de verpakker verwacht beschikbaar zal zijn.
Ga je gang en Opslaan en Bouw nu, en bekijk dan de Console uitvoer.
Alles liep zoals verwacht - onze bouwer werd gekloond en uitgevoerd en onze packager werd gekloond en uitgevoerd. En als we naar de output kijken - daar is het! De Balrog van Morgoth is volledig Gandalfd geweest.
Contrived? Zeer zeker.
Maar een complex concept is eigenlijk gewoon een stel simpele concepten die samen worden geplet. Op het eerste gezicht hebben we de toespraak van Gandalf op de brug van Khazad-dûm verzameld. Maar echt, we namen de build-output van één project en injecteerden het in de uitvoer van een ander project.
Wat als in plaats van de dialoog van Gandalf de build-outputs uitvoerbare bestanden waren uit afzonderlijke codebases die allemaal moeten worden samengevoegd voor de software die u verzendt? U zou dezelfde workflow gebruiken die we hier hebben ingesteld: klonen, bouwen, kopiëren en verpakken. Met de plug-in Jenkins Workflow duurde het slechts een paar regels Groovy. En als bonus zit alles in één script!
Er zijn ook andere hulpmiddelen beschikbaar om een Jenkins-workflow te helpen beheren en visualiseren. CloudBees biedt een Workflow Stage View-functie op hun Enterprise Jenkins Platform.
Dit krast alleen het oppervlak van wat kan worden gedaan met de plug-in Jenkins Workflow. Zorg ervoor dat u de gerelateerde links hieronder bekijkt voor meer informatie.
Veel succes om je werk te laten stromen!
Accentsconagua