Unix-komentotulkeissa kuten Bashissa on ollut vuosikaudet varsin monipuoliset tavat palata komentotulkin historiasta löytyviin komentoihin. Nuoli ylös palaa komentohistoriassa taaksepäin ja nuoli alas vie eteenpäin. Koko historian näkee komennolla “history”:

$ history
 1257 git remote -v
 1258 cd /tmp/
 --- snip ---
 2242 id -un 0
 2243 id -gn 0

Tämän voi yhdistää grepin kanssa:

$ history|grep remote
 1264 git remote -v
 --- snip --

Yksi kätevimmistä on haku historiasta: ensin painetaan Ctrl-R ja sen jälkeen syötetään hakusana (alla “gpg”):

Joskus käy niin että verkosta löytyy huolellisesti vuosien mittaan käsin säädetty, mahdollisesti jo edesmenneeltä sysadminilta peritty taideteos, jonka sielunelämästä ei kukaan enää ymmärrä, ja joka uhkaa romahtaa jos hengittää kohti liian kovaa. Se tuottaa mahdollisesti vielä jotakin yritykselle merkityksellistä palveluakin. Mikä avuksi?

Jos näin on päässyt käymään, tai odotetaan suoritettavan muun toistaiseksi villinä ja vapaana ajelevan järjestelmän hallinta puppetilla, on hyvä palauttaa mieleen, että puppet sisältää RAL-kuoren (Resource Abstraction Layer), jonka avulla voidaan tarkastella sitä miten puppet näkee järjestelmän. RAL-kuoren avulla voidaan järjestelmän tila muuntaa puppet-koodiksi pienellä vaivalla. Esimerkiksi hakemistopuun muuntaminen:

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.