Jenkins Configuration as Code

Job DSL eller skriptade/deklarativa pipelines blir standard för att definiera jobb i Jenkins. Nu behöver vi en liknande lösning för att hantera Jenkins självt.

Jenkins kan installeras via systemets egna paket, Docker eller köras fristående på valfri maskin med en installerad Java Runtime Environment (JRE). Men att konfigurera Jenkins är en tidskrävande process, oavsett hur du väljer att köra det, och ju fler plugins du använder, desto mer tidskrävande blir det. Eftersom det finns fler än 1 400 tillgängliga plugins är det lätt att hamna i ett ohanterligt läge.

Både Jenkins och dess plugins kräver manuell konfigurering, som som standard bara är tillgänglig via användargränssnittet. Pluginet Jenkins Configuration as Code (JCasC) gör det möjligt att hantera sådan konfiguration via lättlästa konfigurationsfiler.

Varför utvecklade vi (ännu ett!) Jenkins-plugin?

Configuration as Code är inget nytt koncept, och Jenkins erbjuder redan ett sätt att automatisera driftsättningen, till exempel genom stöd för init-skript skrivna i Groovy. Problemet är att du behöver kunna Groovy och förstå hur Jenkins och dess plugins fungerar internt. Dessutom blandas skript och konfiguration, vilket strider mot en av våra viktiga principer: att skilja på ”vad” och ”hur”.

Ett specifikt exempel är JenkinsAsCodeReference, som utvecklades på Praqma. Jag arbetade med en kund som ville införa detta arbetssätt, och jag gillade det från första början. Jag hade inte särskilt mycket erfarenhet av Jenkins vid den tiden, så det var en stor lättnad att kunna bevara befintlig konfiguration utan att behöva spara oläslig xml eller ta skärmbilder av den befintliga konfigurationen för dokumentation. Det gjorde också att jag kunde experimentera och implementera utan rädsla.

JenkinsAsCodeReference används nu av flera företag, men det har vissa problem. Det tvingar dig att använda Docker och hanterar även driftsättningen av Jenkins. Omdeployering är tidskrävande, och den faktiska konfigurationen blandas med Groovy-skript. Det här började bli frustrerande, så vi bestämde oss för att ta fram en ny och bättre lösning som skulle erbjuda samma funktioner – och mycket mer – men vara enklare att underhålla, snabbare och kunna användas i olika scenarier, inte bara med Docker.

Med vi menar jag mig själv och andra utvecklare på Praqma, som senare fick sällskap av ingenjörer från CloudBees. Med bättre lösning menar jag ett plugin.

När vi tog fram prototypen för pluginet hittade vi befintliga alternativ. Ingenjörer på CloudBees och vanliga Jenkins-användare försökte göra exakt samma sak. Vi såg detta som en fantastisk möjlighet till samarbete, så vi kontaktade CloudBees och upptäckte att våra visioner, mål och drivkrafter låg mycket nära varandra.

Nu arbetar vi tillsammans för att göra detta till den självklara Configuration as Code-lösningen för Jenkins.

Vilka fördelar har Jenkins Configuration as Code?

Målet med pluginet är att göra för Jenkins-konfigurationen det som Job DSL en gång gjorde för jobb: flytta den till kod! Vi vill också lära oss av de utmaningar som uppstod när Job DSL skapades. För att pluginet ska lyckas måste det stödja så många plugins som möjligt direkt, utan att det krävs extra integrationskod för varje plugin. Låt oss påminna oss om att det finns långt fler än 1 000 av dem. Inte ALLA kräver någon form av global konfiguration, men antalet som behöver stödjas av pluginet Jenkins Configuration as Code är fortfarande ganska stort.

Det är en utmaning, och vi vet redan att vi inte kommer att kunna stödja alla plugins. Det kommer att behövas viss integrationskod och ett antal Pull Requests för att få plugins att stödja våra krav, men vi anser att det är värt det.

Jenkins Configuration as Code hjälper dig inte att driftsätta Jenkins – det behöver du fortfarande göra på ditt favoritsätt med containers, Kubernetes, systempaket, Ansible eller liknande. Men så snart du ska starta Jenkins finns JCasC där för att hjälpa dig. Du behöver inte längre redigera den globala Jenkins-konfigurationen manuellt under Manage Jenkins efter driftsättning.

När du har förberett din konfigurationsfil kan Jenkins konfigureras automatiskt vid start. Du kan enkelt återställa Jenkins – på några sekunder. Du kan också återanvända samma fil för att konfigurera flera Jenkins-instanser eller starta en lokal instans för att testa dina ändringar innan du gör dem till en del av produktionsmiljön.

Om du väljer att spara konfigurationsfilen i ett VCS, till exempel ett Git-repository – vilket jag tycker att du bör – kan du hålla koll på ändringar i den globala Jenkins-konfigurationen. Det gör det möjligt att snabbt återställa en tidigare konfiguration om den nya inte fungerar som önskat. Det gör det också enkelt att jämföra och spåra ändringar när något går sönder.

Jenkins Configuration as Code är den sista saknade pusselbiten för att du helt ska kunna hantera din Jenkins-instans som kod. Nu kan du ha din infrastruktur som kod.

Varför jag tycker att JCasC helt enkelt är bättre

En av de många utmaningar vi tog oss an var att efterlikna Jenkins användargränssnitt i en konfigurationsfil så långt som möjligt. Vi ville inte behöva bläddra igenom långa dokumentationssidor för att ta reda på hur man konfigurerar Mailer-pluginet eller information om Artifactory Server. Och vi ville förstås inte heller implementera separata lösningar för varje plugin. Därför kommer det att kännas naturligt för dig att skriva en sådan fil om du har erfarenhet av att hantera Jenkins. Men oroa dig inte om du inte har det – vi är inte emot dokumentation, utan låter den fortfarande genereras automatiskt! Dessutom genereras den utifrån din faktiska Jenkins-konfiguration, och du kan komma åt den direkt på din egen server.

Konfigurationsfilerna för den globala Jenkins-konfigurationen ska vara lättlästa. Vi vill inte att de ska vara knutna till ett specifikt språk, de får inte kräva särskilda kunskaper och de ska stödja kommentarer. Därför valde vi YAML. Det är enkelt att skriva och tack vare tillgängliga scheman kan du också få stöd i din IDE och verifiera din konfiguration utan att köra en Jenkins-instans.

Och viktigast av allt: när du har infört ändringen i din konfigurationsfil kan du ladda om den utan att starta om Jenkins. Inga fler tidskrävande driftsättningar!

Vill du hjälpa till?

Jag nämnde att CloudBees-utvecklare är involverade i pluginet, men det finns lite mer att berätta. Vi har presenterat konceptet på flera meetups, och CloudBees uppmärksammade det under FOSDEM i början av februari. Responsen har varit fantastisk – vi får redan bidrag från externa utvecklare. Pull Requests och idéer till nya funktioner strömmar in!

Du kan också bidra – ju fler PR:er, desto bättre. Skapa gärna issues för funktioner eller buggar. Vi vill inte bara lösa våra problem, utan även dina!

https://github.com/jenkinsci/configuration-as-code-plugin är platsen att gå till nu!