Puppet-koodissa on monia tapoja vähentää koodiin määrää. Silloin, kun pitää luoda useita hyvin samankaltaisia resursseja, on each-funktio erittäin kätevä työkalu. Jos luotavien resurssien erot rajoittuvat yhden parametrin arvoon, riittää seuraava:

# testfiles.pp
 $testfiles = ['/tmp/foo','/tmp/bar']
 $testfiles.each |$testfile| {
 file { $testfile:
 ensure => 'present',
 }
 }

Yllä oleva koodi luo molemmat tiedostot:

$ puppet apply testfiles.pp
 Notice: Compiled catalog for computer.example.org in environment production in 0.13 seconds
 Notice: /Stage[main]/Main/File[/tmp/foo]/ensure: created
 Notice: /Stage[main]/Main/File[/tmp/bar]/ensure: created
 Notice: Applied catalog in 0.03 seconds

Each-funktio on erityisen voimallinen, kun sen käyttämä data määritetään Hash-tyyppisessä muuttujassa. Alla esimerkki ini-tiedoston muokkauksesta gitdaemon-moduulissa:

Aiemmassa blogikirjoituksessa käsittelin custom faktojen luontia dynaamisesti. Tällä kertaa käsittelemme ulkoisten faktojen (“external facts”) perusteita. Puppetlabsin oma dokumentaatio aiheesta on varsin laadukasta, kunhan sen vain malttaa lukea ajatuksen kanssa (toisin kuin allekirjoittanut).

Ulkoisilla faktoilla tarkoitetaan faktoja, joiden arvon Facter päättelee niiden tulosteesta ja joita ei tyypillisesti ole kirjoitettu Rubyllä vaan esim. Bashilla, Pythonilla tai PowerShellillä. Ne toimivat muutoin kuin “oikeat” faktat, mutta niissä ei voida viitata muihin faktoihin, eikä niitä voi rajata (“confine”) toimimaan vain jossain käyttöjärjestelmässä.

Staattisten faktojen kirjoittaminen on varsin helppoa melko vähäisinkin Ruby-taidoin. Alla esimerkki faktasta, joka palauttaa true tai false riippuen siitä, onko noodilla /boot-osiota:

Facter.add(:has_bootfs) do
 setcode do
 if Facter.value(:mountpoints)['/boot'].nil?
 false
 else
 true
 end
 end
 end

Kuten yltä näkyy, itse tieto löytyi jo valmiiksi Facterin “mountpoints”-faktan sisältä: yllä sen sisältöä vain muunnettiin erilliseksi, helposti käsiteltäväksi faktaksi visualisointia ja skriptausta helpottamaan.

Mountpoints-fakta sisältää myös paljon muuta kiinnostaa tietoa, kuten sen, miten suuri osio on ja paljonko siellä on tilaa vapaana. Jos näistäkin tiedoista halutaan luoda samaan tapaan erilliset faktat, voidaan ne helposti luoda dynaamisesti:

NOTE: this article is now also available in English (here).

Aiemmassa blogikirjoituksessa käsittelin Augeaksen käyttöä Puppetin kanssa esimerkkinä PostgreSQL:n pg_hba.conf -tiedoston muokkaus. Tässä kirjoituksessa käsitellään XML-tiedostojen muokkausta Augeaksella, mikä on luultavasti siistein ratkaisu silloin, kun ei haluta hallita koko tiedostoa esimerkiksi ERB-templatena. Alla muokataan Pwm:n web.xml-tiedostoa, johon on määritettävä asetushakemiston polku.

Ennen itse Augeas-resurssin kirjoitusta kannattaa tarkistaa, mikä Augeaksen käsitys muokattavan tiedoston rakenteesta on. Ensin augtoolille pitää kertoa, mistä hallittava tiedosto löytyy:

Puppet-moduulien ja manifestien uudelleenkäytettävyyden vuoksi on suositeltavaa pitää data niistä erillään. Tämä tapahtuu käyttämällä hieraa. Moduulit voivat esimerkiksi tuottaa erilaisia asetuksia käyttämällä hieran perusteella organisaatiohin tai sijainteihin määriteltyä dataa

Hieraan tallennetaan tyypillisesti myös sellaista yksityistä dataa mikä pitää olla suojattua, ja minkä ei haluta joutuvan ulkopuolisten saataville. Tyypillisesti data tallennetaan muun koodin ohella versionhallintajärjestelmään, joka voi olla organisaation rajojen ulkopuolella. Tällöin on käytettävä hieran encryptionta.

Aiemmin yleisesti käytetty hieran salauksen menetelmä oli hiera-gpg. Hiera-gpg:n avulla salattiin koko tiedosto. Hiera-eyaml parantaa tilannetta sallimalla hieratiedoston sisällä haluttujen datalohkojen salaamisen, mikä parantaa käytettävyyttä.

Puppetin palvelinpuoleen kuuluu on nykyisin aikamoinen tukku palvelinsovelluksia, työkaluja ja suositeltuja työnkulkuja:

1. Palvelinkomponentit
   • Puppetserver: Varsinainen Puppet-palvelin, johon Puppet agentit ottavat yhteyttä. Toimii myös itsenäisesti ilman PuppetDB:tä ja Puppetboardia
   • PuppetDB: Datasäilö, johon Puppet agentit tallentavat faktojaan ja raporttejaan. Dataan päästään haluttaessa käsin ohjelmallisesti.
   • PostgreSQL: PuppetDB:n taustalla oleva tietokantapalvelin
   • Puppetboard: PuppetDB:n datan visualisoitiin tarkoitettu webbisovellus.
   • Apache 2: Puppetboardin taustalla oleva webbipalvelin
2. Työkalut
   • Git: versionhallintajärjestelmä, josta hallintarepo, r10k ja monien Puppet moduulien käyttö on riippuvaista.
   • Hiera: hierarkinen datasäilö Puppet-moduulien, esim. profiilien, parametreille. Voidaan käyttää asiakaskoneiden asetusten räätälöintiin eri luokitteluperustein. Luokittelu voi perustua faktoihin (esim. käyttöjärjestelmäversio, datakeskus) tai asiakaskoneelle erikseen määritettyihin arvoihin (esim. asiakas, koneen kriittisyys liiketoiminnan kannalta).
   • Eyaml: Hieran datatiedostossa (yaml) olevan datan kryptaukseen tarkoitettu työkalu. Tärkeä erityisesti silloin, kun Hieran dataa säilötään organisaation ulkopuolella kuten esimerkiksi GitLabissa.
   • R10k: työkalu dynaamisten Puppet environmentien hallintaan. Käytännössä r10k luo kustakin hallintarepon haarasta Puppet environmentin. Kukin haara sisältää environmentin vaatimat Puppet-moduulit sekä niiden tarvitsemat parametrit.
3. Suositellut työnkulut
   • Komponenttimoduulien, roolien ja profiilien käyttö
   • Hallintarepon ja r10k:n käyttö
   • Versionhallinnan (Gitin) käyttö on perusoletus

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:

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.

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ä.

Mikäli hallintarepon, r10k:n ja GitLab:in sisältävä työnkulku tuntuu vielä liian kevyeltä, on läskiä ja abstraktiotasoja lisättävissä onneksi toisaalla, nimittäin itse Puppet-moduuleissa. Pelastuksen tarjoaa ns. “Roles and Profiles pattern”, jonka kehitti alunperin Craig Dunn, ja joka löi läpi todennäköisesti Gary Larizzan blogikirjoitusten myötä. Alla käytämme englanninkielisen termin sijaan lähes suomenkielistä termiä “roolit ja profiilit”.

Roolit ja profiilit ovat aivan tavallisia Puppet-luokkia. Ne eivät ole kuitenkaan ole Gary Larizzan termiä käyttäen ns. komponenttimoduuleja, jotka on suunniteltu jonkin yksittäisen asian tekoon, ja jotka olisivat siten (ainakin periaatteessa) jaettavissa muiden käyttäjien kesken esim. Puppet Forgessa.