Lisää läskiä työnkulkuun, osa 1: Hallintarepo

Mikäli muutosten tekeminen Puppet-koodiin ja Hieraan suoraan puppetmasterilla tuntuu liian kevyeltä ja helpolta, voi Puppet-työnkulusta tehdä asteittain vaikeammaksi oman sietokyvyn mukaan lisäämällä palettiin lisää komponentteja. Esimerkiksi ns. control repon ja r10k:n käyttö Puppetin environmentien ylläpitoon lisää heti useita vaiheita aiemmin yksinkertaiseen työnkulkuun. Toki tällä saavutetaan myös ihan oikeita etuja, joista lisää tuonnempana.

Control repo - tästä lähtien osin suomennettuna “hallintarepo” - on käytännössä Git repository, jonka jokaisesta haarasta (branch) luodaan (tai ainakin voidaan luoda) dynaamisesti Puppet masterille vastaava Puppet-environment. Hallintarepon oletushaaran nimi, “production”, on tästä syystä sama, kuin Puppet agenttien oletuksena käyttämä environment. Hallintarepon haaroissa on pitkälti sama sisältö kuin tavanomaisessa /etc/puppetlabs/code/environments/production -kansiossakin olisi:

$ ls control-repo
 data
 environment.conf
 hiera.yaml
 Puppetfile
 README.md
 site
 site.pp

Puppetfileä käsiteltiin jo aiemmassa artikkelista, jossa luotiin Puppet-koodiin pohjautuvia Kafo-installereja. Tiivistetysti Puppetfile sisältää viittaukset niihin Puppet-moduuleihin, jotka environmentin moduulikansiossa halutaan olevan:

# Forgen osoite
 forge "https://forgeapi.puppetlabs.com"
 
 # Moduuli Puppet Forgesta
 mod 'puppetlabs/stdlib'
 
 # Moduuli Gitistä
 mod 'puppet-mymodule',
 :git => 'git@gitlab.com:myorg/puppet-mymodule.git'

Tiedosto site.pp on näinä aikoina usein äärimmäisen pelkistetty, koska sitä tulee usein käytettyä lähinnä luokkien lataamiseen Hieran “classes”-listasta:

# Oletusarvo [] estää Puppet-ajojen epäonnistumisen siinä
 # tapauksessa, että jollakin koneella ei ole classes-listassa yhtään
 # luokkaa.
 lookup('classes', {merge => unique, default_value => []}).include

Tiedosto environment.conf on sekin varsin pelkistetty:

# Environmentin manifesti (ks. yllä)
 manifest = site.pp
 
 # Puppet-moduulien latauspolku. Alla käytetään globaaleja,
 # environmentien ulkopuolisia moduuleja kansiosta
 # /etc/puppetlabs/code/modules, sitten etsitään environmentin
 # moduulikansiosta, sitten environmentin site-kansiosta.
 # Site-kansion moduulien tiedostojen oletetaan olevan suoraan
 # hallintarepossa, ts. niihin ei viitata Puppetfilessä.
 modulepath = $basemodulepath:modules:site
 
 # Varmistetaan, että noodit käyttävät aina tuoreinta koodia. Suurella
 # noodimäärällä tämän parametrin arvoa voi joutua miettimään
 # uudelleen. 
 environment_timeout = 0

Tiedosto hiera.yaml on environment-kohtainen Hieran-asetustiedosto. Aiemmista versioista poiketen versio 5 hiera.yaml:ista sallii kolmitasoisen hierarkian, johon kuuluu globaali taso, environment-kohtainen taso ja moduulikohtainen taso. Viimeksi mainittu vaikuttaa suunnitellun vaihtoehdoksi hieman ikääntyneelle params.pp -patternille. Näillä seikoilla ei ole hallintarepon kannalta muuta merkitystä kuin se, että hallintarepon jokaisessa haarassa on hiera.yaml-tiedosto - esimerkiksi tällainen:

---
 version: 5
 defaults:
 datadir: data
 data_hash: yaml_data
 
 hierarchy:
 - name: "Per-node data"
 path: "nodes/%{trusted.certname}.yaml"
 - name: "Common data"
 path: "common.yaml"

Kansio site sisältää hallintarepossa suoraan ylläpidettävät Puppet-moduulit, kuten yllä site.pp:n kommenteissa mainittiinkin. Näin säästytään Puppetfilen ja erillisten moduulirepojen ylläpidolta.

Kansio data sisältää Hieran hierarkian, eli yllä olevaa hiera.yml-tiedostoa käytettäessä tiedoston common.yaml sekä kansion nodes, jossa on noodeille niiden omat yaml-tiedostot.

Artikkelisarjan muut osat: