Blog

Jenkinsin konfigurointi koodina

FEB 27, 2018

Automaatioalustan automatisointi

Ewelina Wilkosz

Ewelina has a masters in computer science and has her sharp eyes on our clients' CD/CI infrastructure. Before moving to Denmark in January 2017, she was a multi-wizard in Ericsson, juggling roles as a software developer, scrum master, and product owner. Ewelina is a big fan of Netflix, books, F1, and road bike cycling when the weather allows. She misses the warmer Polish climate and a good pierogi.

Job DSL- tai scriptattuihin/deklaratiivisiin pipelineihin perustuvat ratkaisut ovat vakiintumassa tavaksi määritellä jobeja Jenkinsissä. Nyt tarvitsemme vastaavan ratkaisun myös Jenkinsin itsensä ylläpitoon.

Jenkins voidaan asentaa käyttöjärjestelmän omista paketeista, Dockerilla tai ajaa itsenäisenä millä tahansa koneella, johon on asennettu Java Runtime Environment (JRE). Jenkinsin konfigurointi on kuitenkin työlästä riippumatta siitä, miten sitä ajetaan, ja työmäärä kasvaa käytettyjen pluginien määrän myötä. Saatavilla on yli 1 400 pluginia, joten tilanne voi helposti muuttua hallitsemattomaksi.

Sekä Jenkins että sen pluginit vaativat manuaalista konfigurointia, joka on oletuksena mahdollista vain käyttöliittymän kautta. Jenkins Configuration as Code -pluginin (JCasC) avulla voimme hallita konfiguraatiota selkeiden konfiguraatiotiedostojen avulla.

Miksi kehitimme (taas yhden!) Jenkins-pluginin?

Configuration as Code ei ole uusi käsite, ja Jenkins tarjoaa jo tavan automatisoida käyttöönottonsa esimerkiksi Groovylla kirjoitettujen init-skriptien tuen avulla. Ongelma on, että se edellyttää Groovyn osaamista sekä Jenkinsin ja sen pluginien sisäisen toiminnan ymmärtämistä. Se myös sekoittaa skriptit ja konfiguraation keskenään eikä noudata tärkeää periaatettamme erottaa ”mitä” ja ”miten” toisistaan.

Yksi esimerkki on Praqman kehittämä JenkinsAsCodeReference. Työskentelin asiakkaan kanssa, joka halusi ottaa tämän lähestymistavan käyttöön, ja pidin siitä heti alusta lähtien. Minulla ei tuolloin ollut paljon kokemusta Jenkinsistä, joten mahdollisuus säilyttää vanhat konfiguraatiot ilman, että piti tallentaa vaikeasti luettavaa XML:ää tai ottaa kuvakaappauksia olemassa olevasta asetuksesta dokumentointia varten, oli suuri helpotus. Sen ansiosta pystyin myös kokeilemaan ja toteuttamaan muutoksia huoletta.

JenkinsAsCodeReferencea käyttää nykyään usea yritys, mutta siinä on omat haasteensa. Se pakottaa käyttämään Dockeria ja huolehtii myös Jenkinsin käyttöönotosta. Uudelleenkäyttöönotto vie aikaa, ja varsinainen konfiguraatio on sekoittunut Groovy-skripteihin. Tämä alkoi tuntua hankalalta, joten päätimme kehittää uuden ja paremman ratkaisun, joka tarjoaisi samat ominaisuudet – ja paljon muuta – mutta olisi helpompi ylläpitää, nopeampi ja käytettävissä erilaisissa tilanteissa, ei vain Dockerin kanssa.

Meillä tarkoitan itseäni ja muita Praqman kehittäjiä, joihin myöhemmin liittyi CloudBeesin insinöörejä. Paremmalla ratkaisulla tarkoitan pluginia.

Pluginin prototyyppiä valmistellessamme löysimme jo olemassa olevia ratkaisuja. CloudBeesin insinöörit ja Jenkinsin aktiiviset käyttäjät yrittivät tehdä täsmälleen samaa. Näimme tässä erinomaisen yhteistyömahdollisuuden, joten otimme yhteyttä CloudBeesiin. Huomasimme, että visiomme, tavoitteemme ja motivaatiomme olivat hyvin samankaltaiset.

Cloud Native Jenkins Summit

Nyt työskentelemme yhdessä tehdäksemme tästä sen Configuration as Code -ratkaisun Jenkinsille.

Mitä hyötyä Jenkins Configuration as Codesta on?

Pluginin tavoitteena on tehdä Jenkinsin konfiguraatiolle sama kuin Job DSL teki aikoinaan jobeille: siirtää se koodiin! Haluamme myös oppia Job DSL:n kehittämiseen liittyneistä haasteista. Jotta plugin onnistuisi, sen on tuettava mahdollisimman montaa pluginia suoraan ilman, että jokaiselle pluginille tarvitsee kirjoittaa yhdistävää koodia. Muistutetaan, että plugineja on reilusti yli 1 000. Kaikki niistä eivät vaadi jonkinlaista globaalia konfiguraatiota, mutta Jenkins Configuration as Code -pluginin tuettavien pluginien määrä on silti huomattava.

Tämä on haastavaa, ja tiedämme jo, ettemme pysty tukemaan kaikkia plugineja. Tarvitaan jonkin verran yhdistävää koodia ja useita Pull Requesteja, jotta pluginit täyttävät vaatimuksemme, mutta uskomme sen olevan vaivan arvoista.

Jenkins Configuration as Code ei auta Jenkinsin käyttöönotossa. Se täytyy edelleen tehdä haluamallasi tavalla esimerkiksi konttien, Kubernetesin, käyttöjärjestelmäpakettien, Ansiblen tai vastaavien avulla. Kun olet käynnistämässä Jenkinsiä, JCasC on kuitenkin valmiina auttamaan. Käyttöönoton jälkeen Jenkinsin globaalia konfiguraatiota ei enää tarvitse muokata manuaalisesti Manage Jenkins -näkymässä.

Kun olet valmistellut konfiguraatiotiedoston, Jenkins voidaan konfiguroida automaattisesti käynnistyksen yhteydessä. Voit palauttaa Jenkinsin helposti muutamassa sekunnissa. Voit myös käyttää samaa tiedostoa useiden Jenkins-instanssien konfigurointiin tai käynnistää paikallisen instanssin muutosten testaamiseksi ennen niiden viemistä tuotantoympäristöön.

Jos päätät säilyttää konfiguraatiotiedostosi VCS:ssä, esimerkiksi Git-repositoriossa – kuten mielestäni kannattaa – voit seurata Jenkinsin globaalin konfiguraation muutoksia. Näin voit palauttaa aiemman konfiguraation nopeasti, jos uusi ei toimikaan odotetusti. Se helpottaa myös muutosten vertailua ja jäljittämistä, kun jokin menee rikki.

Jenkins Configuration as Code on viimeinen palanen kokonaisuudessa, jonka avulla voit hallita Jenkins-instanssiasi täysin koodina. Nyt myös infrastruktuurisi voi olla koodia.

Miksi JCasC on mielestäni yksinkertaisesti parempi

Yksi monista asettamistamme haasteista oli jäljitellä Jenkinsin käyttöliittymää konfiguraatiotiedostossa mahdollisimman tarkasti. Emme halunneet selata pitkiä dokumentaatiosivuja selvittääksemme, miten Mailer-plugin tai Artifactory Serverin tiedot konfiguroidaan. Emme tietenkään halunneet myöskään toteuttaa erillisiä ratkaisuja jokaiselle pluginille. Jos sinulla siis on kokemusta Jenkinsin hallinnasta, tällaisen tiedoston kirjoittaminen käy luontevasti. Jos ei käy, ei hätää: emme ole dokumentaation vihollisia, vaan annamme sen edelleen luoda itse itsensä! Lisäksi dokumentaatio luodaan todellisen Jenkins-asennuksesi perusteella, ja voit käyttää sitä suoraan omalla palvelimellasi.

Jenkinsin globaalin konfiguraation konfiguraatiotiedostojen tulee olla ihmisen luettavissa. Emme halua niiden olevan sidoksissa tiettyyn ohjelmointikieleen, edellyttävän erityisosaamista, ja niiden tulee tukea kommentteja. Näistä syistä valitsimme YAMLin. Sitä on helppo kirjoittaa, ja saatavilla olevan skeeman ansiosta IDE voi tukea sen käyttöä. Voit myös tarkistaa konfiguraatiosi ilman käynnissä olevaa Jenkins-instanssia.

jenkins.yaml example

Ja mikä tärkeintä: kun olet tehnyt muutoksen konfiguraatiotiedostoosi, voit ladata sen uudelleen ilman Jenkinsin uudelleenkäynnistystä. Ei enää aikaa vieviä uudelleenkäyttöönottoja!

Haluatko auttaa?

Mainitsin CloudBeesin insinöörien osallistumisesta pluginin kehitykseen, mutta tarinassa on vielä hieman lisää. Olemme esitelleet konseptia useissa meetupeissa, ja CloudBees nosti sitä esiin FOSDEMissä helmikuun alussa. Vastaanotto on ollut loistava – saamme jo ulkopuolisia kontribuuttoreita. Pull Requesteja ja ominaisuusideoita alkaa tulla!

Sinäkin voit osallistua – mitä enemmän PR:iä, sen parempi. Voit vapaasti luoda issueita ominaisuustoiveista tai bugeista. Emme halua ratkaista vain omia ongelmiamme, vaan myös sinun!

https://github.com/jenkinsci/configuration-as-code-plugin on nyt oikea paikka!

  • DevOps
  • CI/CD

Subscribe to our newsletter