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.

Puppet on jo pitkään tukenut Windowsia. Monet natiivit Puppet-resurssit, kuten File, Package ja Service ovat jo pitkään toimineet sekä *NIX-käyttöjärjestelmissä että Windowsissa. Lisäksi osa natiiveista Puppet-resursseista, kuten Registry on suunniteltu pelkästään Windows-käyttöön.

Puppetin käyttömukavuus Windows-järjestelmien ylläpidossa on parantunut mutkan kautta muutamien uusien teknologioiden myötä:

1. Powershell DSC
2. Chocolatey
3. Powershell Exec provider

Powershell DSC perustuu resurssien tilan hallintaan, aivan kuten Puppetkin. Mikä parasta, Puppet-koodissa voi käyttää natiivien Puppet-resurssien lisäksi Powershell DSC-resursseja. Puppetlabsin blogikirjoitus on hyvä alustus tähän aiheeseen. DSC vaatii toimiakseen Powershell 5.0:n, joka tulee Windows Management Framework 5.0:n mukana.

Windowsissa voidaan käyttää hosts-tiedostoa ip-osoitteiden ja nimien liittämiseen toisiinsa, aivan kuten Linuxissakin. Linuxissa tiedoston sijainti on /etc/hosts, Windowsissa se on c:windowssystem32driversetchosts, tai oikeastaan $env:windirsystem32driversetchosts.

Hosts-tiedoston käyttäminen tulee ajankohtaiseksi silloin kun sovellus tarvitsee DNS-nimen, eikä DNS-palvelinta ole käytettävissä, tai sitä ei voida jostakin syystä käyttää.

Jos Puppet agentille ei ole määritetty palvelinta, se yrittää oletuksena yhteyttä palvelimeen jonka DNS-nimi on ‘puppet’, eli jos palvelimelle on määritetty domain ’example.com’, agent hakee palvelinta jonka DNS-nimi on ‘puppet.example.com’ Määrittämällä server-asetuksella palvelimen DNS-nimi, voidaan Puppet agent osoittaa haluttuun palvelimeen. Tämä määritetään Linuxeissa tyypillisesti uusimmissa puppet-versioissa tiedostossa /etc/puppetlabs/puppet/puppet.conf osiossa main tai agent.

Vagrantin shell-provisioner tukee suoraan Powershell-skriptejä. Toisin sanoen Windows-virtuaalikoneen asetuksia voi muokata Powershellillä ilman, että tarvitsee rakentaa uusi virtuaalikonekuva. Tyypillinen esimerkki on Windows liittäminen konfiguraationhallintajärjestelmään kuten Puppetiin.

Vagrantin dokumentaatiossa mainitaan, että Powershell-skriptille voi välittää parametreja powershell_args -valinnalla joko merkkijonona (string) tai listana (array). Esimerkkejä etenkin Powershell-provisioinnista on kuitenkin heikosti, mistä syystä tämäkin blogipostaus on kirjoitettu. Otetaan esimerkkinä skripti bootstrap_windows.ps1_,_ joka liittää Windows-virtuaalikoneen olemassa olevaan Puppetserveriin. Sitä käytetään käsin Powershellistä seuraavasti:

> .bootstrap_windows.ps1 -certName win2012r2.local
 -ServerName puppet.local
 -puppetServerAddress 192.168.137.10

Rivinvaihdot on lisätty selvyyden vuoksi.

Vagrant on erittäin kätevä työkalu kehitys- ja testausympäristöjen rakentamiseen. Sillä voidaan helposti ja toistettavasti luoda virtuaalikoneita, joiden asetukset säädetään halutunlaisiksi provisioning-vaiheessa esimerkiksi skripteillä (shell, powershell) tai konfiguraationhallintatyökaluilla kuten Puppetilla. Vagrantin taustalla on yleensä käytössä Oraclen Virtuabox, mutta myös muita virtualisointialustoja tuetaan ns. providerien avulla.

Vagrantilla luodut virtuaalikoneen on myös helppo verkottaa keskenään. Vagrant toimiikin siten hyvin palvelinympäristöjen testauksessa; hyvänä esimerkkinä käy puppet-ipa -moduuli, jossa Vagrantilla luodaan FreeIPA multi-master -palvelinympäristö sekä useita asiakaskoneita eri käyttöjärjestelmillä. Toinen hyvä esimerkki on puppet-bacula -moduuli, jossa Vagrantilla luodaan täydellinen Bacula-varmuuskopiointiympäristö.

Edellisessä artikkelissa rakennettiin Packerilla ja Boxcutter-templateilla Windows box Vagrant-käyttöön. Tässä artikkelissa näytetään, miten Vagrantilla rakennetaan varsinaisia Windows-virtuaalikoneita.

Vagrantia ohjataan Vagrantfile-tiedostolla, joka usein sijaitsee projektin (esim. Puppet-moduuli) päähakemistossa. Jopa hyvin yksinkertainen Vagrantfile riittää Windows-virtuaalikoneen pystyttämiseen:

# -*- mode: ruby -*-
 # vi: set ft=ruby :
 
 Vagrant.configure("2") do |config|
 config.vm.define "win2012r2" do |box|
 box.vm.box = "mwrock/Windows2012R2"
 box.vm.box_version = "0.6.1"
 box.vm.hostname = "windows2012r2a"
 box.vm.network "private_network", ip: "192.168.31.101"
 box.vm.provider "virtualbox" do |vb|
 # Poistetaan Virtualboxin konsolinäkymä käytöstä
 vb.gui = false
 vb.memory = 2048
 end
 end
 end

Yllä käytetään erästä julkista Windows 2012r2 boxia. Aivan yhtä hyvin voitaisiin käyttää aiemmassa artikkelissa Packerilla luotua boxia tähän tapaan:

Puppet on erittäin kätevä erityisesti hyvin monimutkaisten järjestelmien rakentamisessa ja ylläpidossa. Sen avulla on helppoa myös häivyttää suuriakin käyttöjärjestelmäeroja yhden luokkarajapinnan taakse. Hyvänä esimerkkinä käyvät Puppet-Finland-projektin thunderbird- ja openvpn-moduulit, jotka toimivat useilla eri Linux-jakeluilla ja Windowsilla.

Yleensä Puppettia varten rakennetaan palvelinympäristö, joka koostuu puppetserveristä, yleensä puppetdb:stä sekä mahdollisesti myös puppetboardista tai foremanista. Kullekin hallittavalle koneelle asennettu puppet-agent ottaa yhteyden puppetserveriin esim. kerran puolessa tunnissa, päivittää konfiguraationsa vastaamaan puppetserverillä määriteltyä tilaa ja lähettää raportin puppetserverin kautta puppetdb:lle.

Puppettia voidaan ajaa myös paikallisesti ilman puppetserveriä käyttämällä puppet apply-komentoa esimerkiksi seuraavasti:

Vagrant on näppärä väline myös Windows-virtuaalikoneiden luontiin esim. Puppet-resurssien testauksessa. Windows-virtuaalikoneille on luontevaa käyttää Powershell-provisiointia, minkä Vagrant tekee melkoisen yksinkertaiseksi. Aika nopeasti ilmenee tarve välittää Powershell-skriptille parametrejä Vagrantin kautta. Tästä on hieman hankalaa löytää esimerkkejä, joten tässä yksi.

Oletetaan että meillä on Powershell-skripti nimeltä bootstrap_windows.ps1 Vagrant-projektin alihakemistossa ‘provision’. Skripti asentaa ja konfiguroi Puppet-agentin Windows-virtuaalikoneelle. Skriptille pitää välittää kaksi parametria: Puppetserverin FQDN (serverName) ja mukavuusbonuksena virtuaalikoneelle haluttu FQDN (certName). (Käytän itse Vagrantille yaml-muotoista ns. data-driven vagrant-tiedostoa, joten syntaksi on hieman erilainen vakiomuotoiseen Vagrant-tiedostoon verrattuna).

Tässä artikkelissa näytetään kaksi tapaa Debianin asentamiseksi muistitikulta. Ensimmäisessä CD/DVD-asennin yksinkertaisesti kopioidaan muistitikulla, jolloin siitä tulee kätevämpi ja nopeampi CD-levyn korvike. Toinen tapa on monimutkaisempi, mutta mahdollistaa asennusten automatisoinnin helposti. Alla oletetaan, että muistitikun laitetiedosto on /dev/sdb ja että komennot ajetaan pääkäyttäjän oikeuksin esim. sudoa käyttämällä.

Koska väärän laitetiedoston käyttäminen voi ylikirjoittaa koko järjestelmälevyn, on muistitikun laitetiedosto syytä tarkistaa esimerkiksi “dmesg”-komennolla:

[79499.127904] usb 2-1.2: new high-speed USB device number 13 using ehci-pci
 [79499.230913] usb 2-1.2: New USB device found, idVendor=0951, idProduct=1607
 [79499.230918] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 [79499.230920] usb 2-1.2: Product: DataTraveler 2.0
 [79499.230921] usb 2-1.2: Manufacturer: Kingston
 [79499.230923] usb 2-1.2: SerialNumber: 5B840D0001DA
 [79499.231294] usb-storage 2-1.2:1.0: USB Mass Storage device detected
 [79499.231633] scsi16 : usb-storage 2-1.2:1.0
 [79500.230217] scsi 16:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
 [79500.230722] sd 16:0:0:0: Attached scsi generic sg1 type 0
 [79500.460385] sd 16:0:0:0: [sdb] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
 [79500.461321] sd 16:0:0:0: [sdb] Write Protect is off
 [79500.461327] sd 16:0:0:0: [sdb] Mode Sense: 23 00 00 00
 [79500.462022] sd 16:0:0:0: [sdb] No Caching mode page found
 [79500.462028] sd 16:0:0:0: [sdb] Assuming drive cache: write through
 [79500.465797] sdb: sdb1
 [79500.468449] sd 16:0:0:0: [sdb] Attached SCSI removable disk

Lisäksi on syytä vamistaa, että kyseiseltä muistitikulta on ylipäätään mahdollista bootata käyttöjärjestelmä tai sen asennin; kaikilta ei nimittäin voi.