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 => '[email protected]: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.
