Edellisessä blogipostauksessa esiteltiin tyypillinen hallintarepon rakenne. Tässä artikkelissa käsitellään r10k:ta, jolla hallintarepon haaroista muodostetaan Puppet-palvelimelle vastaavat Puppet-environmentit. R10k:n asennus Puppet 4:een tai uudempaan on suoraviivaista Puppet-pakettien mukana tulevalla gem-ohjelmalla:

$ /opt/puppetlabs/puppet/bin/gem install r10k
 

Tämän jälkeen luodaan r10k:lle asetustiedosto /etc/puppetlabs/r10k/r10k.yaml:

---
 :cachedir: /opt/puppetlabs/puppet/cache/r10k
 :sources:
 control:
 basedir: /etc/puppetlabs/code/environments
 prefix: false
 remote: git@gitlab.com:myorg/control-repo.git

Yllä oletetaan, että hallintarepo ("control repo") on jo olemassa GitLabissa tai vastaavassa, ja että SSH-avaimet on luotu ja lisätty hallintarepoon sekä mahdollisiin yksityisiin Puppet-moduulirepoihin, joihin Puppetfilessä viitataan.

Mikäli hallintarepo ei ole julkinen - mikä on erittäin todennäköistä - pitää r10k:lle osoittaa, mitä SSH-avainta sen tulisi käyttää hallintarepon itsensä ja yksityisten Puppet-moduulien lataamiseen. Tämä onnistuu muokkaamalla pääkäyttäjän SSH-asetuksia eli tiedostoa /root/.ssh/config:

Host gitlab.com
 StrictHostKeyChecking no
 RSAAuthentication yes
 IdentityFile /etc/puppetlabs/r10k/ssh/id_rsa
 User git

SSH-avaimen yksityisen osan (esim. id_rsa) pitää toki olla yllä mainitussa polussa (/etc/puppetlabs/r10k/ssh/id_rsa) ja sen tiedosto-oikeuksien pitää olla riittävän rajatut (esim. 0400).

Lopuksi - jos kaikki meni hyvin, voidaan hallintarepon kaikki haarat muuntaa Puppet environmenteiksi r10k:lla:

$ r10k deploy environment -v --puppetfile
 

Parametri --puppetfile (alias -p) aiheuttaa sen, että r10k poistaa ensin environmentit ja luo ne sen jälkeen uudestaan tyhjästä. Sivuvaikutuksena tässä on se, että kaikki Puppetfilessä mainitut Puppet-moduulit päivitetään uusimpiin versioihin, ellei niiden versiota ole erikseen määritetty.

Ajan säästämiseksi on myös mahdollista päivittää vain yksittäinen environment:

$ r10k deploy environment -v my_feature

Yllä ei myöskään käytetä parametria --puppetfile, joten olemassa olevat environmentit ainoastaan päivitetään sen sijaan, että ne jyrättäisiin sileäksi. Tarkempia ohjeita löytyy r10k:n virallisesta dokumentaatiosta.

Artikkelisarjan muut osat:

Edellisissä artikkeleissa käsiteltiin hallintarepoa ja r10k:ta. Vaikka mikään ei estäkään hallintarepon pitämistä Puppetmaster-koneella ja r10k.yaml:n osoittamista siihen, menetettäisiin silloin monta työvaihetta eikä ratkaisu siten sopisi tämän artikkelisarjan teemaan. Viimeinen puuttuva komponentti työnkulun läskiyttämisessä onkin GitLab tai vastaava, kuten GitHub tai Bitbucket. Näistä ensimmäinen soveltuu parhaiten tilanteeseen, jossa halutaan luoda paljon yksityisiä Git-repoja, joista ei haluta maksaa, eikä GitLabin edistyneemmille ominaisuuksille ole käyttöä. GitHubissa jokainen yksityinen repository maksaa, joten se on kallis ratkaisu yksityisten puppet-moduulien säilömiseen. Bitbucket sallii GitLabin tavoin rajoittamattomasti yksityisiä repositoryjä, mutta rajoittaa käyttäjien määrän tällä hetkellä viiteen, eikä tarjoa merkittävästi etuja, paitsi ehkä Trello-integraation, jos Kanbania haluaa käytellä. GitLabilla on puolellaan vielä se etu, että se on avointa lähdekoodia, joten sen voi asentaa myös omaan sisäverkkoon ja käyttää sieltä.

Työnkulku on GitLabin ja sen kaltaisten järjestelmien kanssa jokseenkin sama. Lisäksi valmisteluvaihe on jokseenkin identtinen:

Edellisessä artikkelissa kerrottiin, miten r10k konfiguroidaan käyttämään GitLabin kanssa oikeaa SSH-avainta eli "deploy keytä". Kun kaikki yllä mainitut valmistelut on tehty, voidaankin siirtyä varsinaiseen työnkulkuun, joka menee tyypillisesti näin.

Ensin käyttäjä päivättä oman hallintarepo-klooninsa production-haaran:

$ git branch
 * production
 $ git pull

luo paikalliseen hallintarepon klooniinsa uuden haaran (ns. "feature branch"):

$ git branch feature_a
 $ git checkout feature_a

Seuraavaksi hän tekee tarvittavat muokkaukset ja commitoi ("commit") muutokset:

$ git add <file>
 $ git commit -m "Add feature a"

Sitten hän julkaisee muutokset GitLabissa:

$ git push origin feature_a

Muutokset siis löytyvät nyt GitLab-reposityn haarasta feature_a.

Seuraavaksi käyttäjä tekee "Merge requestin" GitLabin käyttöliittymällä. Yleensä GitLab osaa valita oikean lähdehaaran automaattisesti, mutta jos näin ei ole, voi sen valita myös käsin. Merge requestin kohteeksi valitaan tyypillisesti production-haara, mutta mikään ei estä erillisen, pitkäikäisen testing tai staging-haaran käyttöä ennen production-haaraan siirtämistä.

Jonkun toisen käyttäjän olisi hyvä seuraavaksi tarkistaa Merge requestin sisältämät muutokset niiden laadun varmistamiseksi. Tässä vaiheessa on myös mahdollista ja jopa järkevää ajaa r10k Puppetmasterilla, jolloin se luo Puppet environmentin feature_a:

$ r10k deploy environment
 

Nyt uutta ominaisuutta ("feature_a") voi testata oikeilla Puppetiin liitetyillä koneilla tähän tapaan:

$ puppet agent -tv --environment=feature_a --noop

Testikoneilla komento voidaan turvallisesti ajaa myös ilman --noop -vipua.

Jos muutokset näyttävät hyviltä ja toimivat odotetulla tavalla, voi tarkistava käyttäjä liittää ("merge") ne hallintarepoon, jolloin ne päätyvät sen production-haaraan.

Seuraava ja viimeinen vaihe on uuden production-haaran sisällön vienti oikeasti tuotantoon r10k:lla:

$ r10k deploy environment
 

Sama prosessi toistetaan aina muutoksia tehdessä.

Jos (ja vain jos) Puppetia käyttää ainostaan yksi henkilö, voi merge requestit halutessaan unohtaa ja tarkistaa muutokset pelkästään Gitin omilla työkaluilla eli lähinnä "git diff"-komennolla. Erillisten feature-haarojen käyttö on kuitenkin perusteltua, koska se helpottaa uuden koodin testausta r10k:lla. Testien jälkeen muutokset voi liittää ("merge") production-haaraan ja julkaista suoraan:

$ git branch
 * feature_a
 production
 $ git push origin feature_a
 $ r10k deploy environment
 --- testaus ---
 $ git checkout production
 $ git merge feature_a
 $ git push

Artikkelisarjan muut osat:

menucross-circle