Puppet on kokoonpanonhallintajärjestelmä. Sitä käytetään tuomaan isännät haluttuun tilaan ja ylläpitämään tätä tilaa.

Olen työskennellyt Puppetin kanssa nyt yli viisi vuotta. Tämä teksti on pohjimmiltaan käännetty ja uudelleen järjestetty kokoelma virallisten asiakirjojen tärkeimmistä kohdista, jonka avulla aloittelijat voivat nopeasti ymmärtää Puppetin olemuksen.

Perustiedot

Puppetin käyttöjärjestelmä on asiakaspalvelin, vaikka se tukee myös palvelimetonta toimintaa rajoitetulla toiminnallisuudella.

Käytössä on pull-toimintamalli: oletusarvoisesti asiakkaat ottavat yhteyttä palvelimeen puolen tunnin välein määritystä varten ja ottavat sen käyttöön. Jos olet työskennellyt Ansiblen kanssa, he käyttävät erilaista push-mallia: järjestelmänvalvoja aloittaa konfiguraation käyttöönottoprosessin, asiakkaat eivät itse käytä mitään.

Verkkoviestinnässä käytetään kaksisuuntaista TLS-salausta: palvelimella ja asiakkaalla on omat yksityiset avaimensa ja vastaavat sertifikaatit. Tyypillisesti palvelin myöntää asiakkaille varmenteita, mutta periaatteessa on mahdollista käyttää ulkoista CA:ta.

Johdatus manifesteihin

Nukketerminologiassa nukkepalvelimelle kytkeä solmut (solmut). Solmujen konfiguraatio on kirjoitettu manifesteissa erityisellä ohjelmointikielellä - Puppet DSL.

Puppet DSL on deklaratiivinen kieli. Se kuvaa solmun halutun tilan yksittäisten resurssien ilmoitusten muodossa, esimerkiksi:

Tiedosto on olemassa ja sillä on tiettyä sisältöä.
Paketti on asennettu.
Palvelu on alkanut.

Resurssit voidaan yhdistää toisiinsa:

On olemassa riippuvuuksia, ne vaikuttavat resurssien käyttöjärjestykseen.
Esimerkiksi "asenna ensin paketti, muokkaa sitten asetustiedostoa ja käynnistä sitten palvelu."
Ilmoituksia on - jos resurssi on muuttunut, se lähettää ilmoitukset sen tilatuille resursseille.
Jos esimerkiksi asetustiedosto muuttuu, voit käynnistää palvelun automaattisesti uudelleen.

Lisäksi Puppet DSL:ssä on funktioita ja muuttujia sekä ehdollisia lausekkeita ja valitsimia. Myös erilaisia mallintamismekanismeja tuetaan - EPP ja ERB.

Puppet on kirjoitettu rubiinilla, joten monet rakenteet ja termit on otettu sieltä. Rubyn avulla voit laajentaa Puppetia - lisätä monimutkaista logiikkaa, uudenlaisia resursseja, toimintoja.

Kun Puppet on käynnissä, palvelimen kunkin tietyn solmun manifestit kootaan hakemistoon. Hakemisto on luettelo resursseista ja niiden suhteista funktioiden, muuttujien ja ehdollisten lausekkeiden arvon laskemisen jälkeen.

Syntaksi ja koodityyli

Tässä ovat virallisen dokumentaation osat, jotka auttavat sinua ymmärtämään syntaksia, jos annetut esimerkit eivät riitä:

Tässä on esimerkki siitä, miltä luettelo näyttää:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова node,
# за которым следует селектор ноды — хостнейм (с доменом или без)
# или регулярное выражение для хостнеймов, или ключевое слово default.
#
# После этого в фигурных скобках описывается собственно конфигурация ноды.
#
# Одна и та же нода может попасть под несколько селекторов. Про приоритет
# селекторов написано в статье про синтаксис описания нод.
node 'hostname', 'f.q.d.n', /regexp/ {
  # Конфигурация по сути является перечислением ресурсов и их параметров.
  #
  # У каждого ресурса есть тип и название.
  #
  # Внимание: не может быть двух ресурсов одного типа с одинаковыми названиями!
  #
  # Описание ресурса начинается с его типа. Тип пишется в нижнем регистре.
  # Про разные типы ресурсов написано ниже.
  #
  # После типа в фигурных скобках пишется название ресурса, потом двоеточие,
  # дальше идёт опциональное перечисление параметров ресурса и их значений.
  # Значения параметров указываются через т.н. hash rocket (=>).
  resource { 'title':
    param1 => value1,
    param2 => value2,
    param3 => value3,
  }
}

Sisennykset ja rivinvaihdot eivät ole pakollinen osa luetteloa, mutta niitä suositellaan tyyliopas. Yhteenveto:

Kahden välilyönnin sisennykset, sarkaimia ei käytetä.
Kiharat aaltosulkeet erotetaan välilyönnillä, kaksoispisteitä ei eroteta välilyönnillä.
Pilkut jokaisen parametrin jälkeen, mukaan lukien viimeinen. Jokainen parametri on erillisellä rivillä. Poikkeuksena on tapaus ilman parametreja ja yhtä parametria: voit kirjoittaa yhdelle riville ja ilman pilkkua (ts. resource { 'title': } и resource { 'title': param => value }).
Parametrien nuolien tulee olla samalla tasolla.
Resurssisuhdenuolet on kirjoitettu niiden eteen.

Tiedostojen sijainti pappetserverillä

Lisäselvitystä varten esittelen "juurihakemiston" käsitteen. Juurihakemisto on hakemisto, joka sisältää tietyn solmun Nukke-määritykset.

Päähakemisto vaihtelee Puppetin version ja käytettyjen ympäristöjen mukaan. Ympäristöt ovat itsenäisiä kokoonpanojoukkoja, jotka on tallennettu erillisiin hakemistoihin. Yleensä käytetään yhdessä gitin kanssa, jolloin ympäristöt luodaan git-haaroista. Vastaavasti jokainen solmu sijaitsee yhdessä tai toisessa ympäristössä. Tämä voidaan määrittää itse solmussa tai ENC:ssä, josta puhun seuraavassa artikkelissa.

Kolmannessa versiossa ("old Puppet") perushakemisto oli /etc/puppet. Ympäristöjen käyttö on valinnaista - emme esimerkiksi käytä niitä vanhan Puppetin kanssa. Jos ympäristöjä käytetään, ne yleensä varastoidaan /etc/puppet/environments, juurihakemisto on ympäristöhakemisto. Jos ympäristöjä ei käytetä, juurihakemisto on perushakemisto.
Neljännestä versiosta ("uusi Puppet") alkaen ympäristöjen käyttö tuli pakolliseksi ja perushakemisto siirrettiin /etc/puppetlabs/code. Vastaavasti ympäristöt tallennetaan /etc/puppetlabs/code/environments, juurihakemisto on ympäristöhakemisto.

Juurihakemistossa on oltava alihakemisto manifests, joka sisältää yhden tai useamman solmuja kuvaavan manifestin. Lisäksi pitäisi olla alihakemisto modules, joka sisältää moduulit. Kerron vähän myöhemmin, mitkä moduulit ovat. Lisäksi vanhalla Puppetilla voi olla myös alihakemisto files, joka sisältää erilaisia tiedostoja, jotka kopioimme solmuihin. Uudessa Puppetissa kaikki tiedostot on sijoitettu moduuleihin.

Luettelotiedostoilla on tunniste .pp.

Pari esimerkkiä taistelusta

Kuvaus solmusta ja siinä olevasta resurssista

Solmun päällä server1.testdomain tiedosto on luotava /etc/issue sisällön kanssa Debian GNU/Linux n l. Tiedoston on oltava käyttäjän ja ryhmän omistuksessa root, käyttöoikeuksien on oltava 644.

Kirjoitamme manifestin:

node 'server1.testdomain' {   # блок конфигурации, относящийся к ноде server1.testdomain
    file { '/etc/issue':   # описываем файл /etc/issue
        ensure  => present,   # этот файл должен существовать
        content => 'Debian GNU/Linux n l',   # у него должно быть такое содержимое
        owner   => root,   # пользователь-владелец
        group   => root,   # группа-владелец
        mode    => '0644',   # права на файл. Они заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

Solmun resurssien väliset suhteet

Solmun päällä server2.testdomain nginxin on oltava käynnissä ja toimittava aiemmin valmistetun kokoonpanon kanssa.

Puretaan ongelma:

Paketti on asennettava nginx.
Konfigurointitiedostot on kopioitava palvelimelta.
Palvelu on aloitettava nginx.
Jos kokoonpano päivitetään, palvelu on käynnistettävä uudelleen.

Kirjoitamme manifestin:

node 'server2.testdomain' {   # блок конфигурации, относящийся к ноде server2.testdomain
    package { 'nginx':   # описываем пакет nginx
        ensure => installed,   # он должен быть установлен
    }
  # Прямая стрелка (->) говорит о том, что ресурс ниже должен
  # создаваться после ресурса, описанного выше.
  # Такие зависимости транзитивны.
    -> file { '/etc/nginx':   # описываем файл /etc/nginx
        ensure  => directory,   # это должна быть директория
        source  => 'puppet:///modules/example/nginx-conf',   # её содержимое нужно брать с паппет-сервера по указанному адресу
        recurse => true,   # копировать файлы рекурсивно
        purge   => true,   # нужно удалять лишние файлы (те, которых нет в источнике)
        force   => true,   # удалять лишние директории
    }
  # Волнистая стрелка (~>) говорит о том, что ресурс ниже должен
  # подписаться на изменения ресурса, описанного выше.
  # Волнистая стрелка включает в себя прямую (->).
    ~> service { 'nginx':   # описываем сервис nginx
        ensure => running,   # он должен быть запущен
        enable => true,   # его нужно запускать автоматически при старте системы
    }
  # Когда ресурс типа service получает уведомление,
  # соответствующий сервис перезапускается.
}

Jotta tämä toimisi, tarvitset noin seuraavan tiedoston sijainnin nukkepalvelimella:

/etc/puppetlabs/code/environments/production/ # (это для нового Паппета, для старого корневой директорией будет /etc/puppet)
├── manifests/
│   └── site.pp
└── modules/
    └── example/
        └── files/
            └── nginx-conf/
                ├── nginx.conf
                ├── mime.types
                └── conf.d/
                    └── some.conf

Resurssityypit

Täydellinen luettelo tuetuista resurssityypeistä löytyy täältä dokumentaatiossa, tässä kuvailen viisi perustyyppiä, jotka käytännössä riittävät ratkaisemaan useimmat ongelmat.

tiedosto

Hallitsee tiedostoja, hakemistoja, symbolilinkkejä, niiden sisältöä ja käyttöoikeuksia.

vaihtoehdot:

resurssin nimi - tiedoston polku (valinnainen)
polku - tiedoston polku (jos sitä ei ole määritetty nimessä)
varmistaa - tiedostotyyppi:
- absent - poista tiedosto
- present - tiedosto on oltava minkä tahansa tyyppinen (jos tiedostoa ei ole, luodaan tavallinen tiedosto)
- file - tavallinen tiedosto
- directory - hakemisto
- link - symbolilinkki
pitoisuus - tiedoston sisältö (sopii vain tavallisille tiedostoille, ei voi käyttää yhdessä lähde tai tavoite)
lähde — linkki polkuun, josta haluat kopioida tiedoston sisällön (ei voi käyttää yhdessä pitoisuus tai tavoite). Voidaan määrittää joko URI:ksi kaavion kanssa puppet: (silloin käytetään nukkepalvelimen tiedostoja) ja järjestelmän kanssa http: (Toivottavasti on selvää, mitä tässä tapauksessa tapahtuu), ja jopa kaavion kanssa file: tai absoluuttisena poluna ilman skeemaa (silloin käytetään solmun paikallisen FS:n tiedostoa)
tavoite — mihin symbolin pitäisi osoittaa (ei voi käyttää yhdessä pitoisuus tai lähde)
omistaja — käyttäjä, jonka pitäisi omistaa tiedosto
ryhmä — ryhmä, johon tiedoston tulee kuulua
tila - tiedostojen käyttöoikeudet (merkkijonona)
toistua - mahdollistaa rekursiivisen hakemistokäsittelyn
puhdistus - mahdollistaa sellaisten tiedostojen poistamisen, joita ei ole kuvattu Puppetissa
pakottavat - mahdollistaa sellaisten hakemistojen poistamisen, joita ei ole kuvattu Puppetissa

paketti

Asentaa ja poistaa paketteja. Pystyy käsittelemään ilmoituksia - asentaa paketin uudelleen, jos parametri on määritetty reinstall_on_refresh.

vaihtoehdot:

resurssin nimi - paketin nimi (valinnainen)
nimi - paketin nimi (jos sitä ei ole mainittu nimessä)
toimittaja - paketinhallinta käytettäväksi
varmistaa — pakkauksen haluttu tila:
- present, installed - mikä tahansa versio asennettuna
- latest - uusin versio asennettuna
- absent - poistettu (apt-get remove)
- purged - poistettu kokoonpanotiedostojen kanssa (apt-get purge)
- held - pakettiversio on lukittu (apt-mark hold)
- любая другая строка — määritetty versio on asennettu
reinstall_on_refresh - jos true, paketti asennetaan uudelleen ilmoituksen saatuaan. Hyödyllinen lähdepohjaisissa jakeluissa, joissa koontiparametreja muutettaessa saattaa olla tarpeen rakentaa uudelleen paketteja. Oletus false.

palvelu

Hallitsee palveluita. Pystyy käsittelemään ilmoituksia - käynnistää palvelun uudelleen.

vaihtoehdot:

resurssin nimi - hallinnoitava palvelu (valinnainen)
nimi - hallittava palvelu (jos sitä ei ole mainittu nimessä)
varmistaa — haluttu palvelun tila:
- running - käynnistettiin
- stopped - pysähtyi
mahdollistaa — ohjaa palvelun käynnistämistä:
- true - automaattinen käynnistys on käytössä (systemctl enable)
- mask - naamioitu (systemctl mask)
- false - automaattinen käynnistys on poistettu käytöstä (systemctl disable)
uudelleenkäynnistys - komento käynnistää palvelu uudelleen
tila — komento palvelun tilan tarkistamiseksi
käynnistää uudelleen — ilmoittaa, tukeeko palvelun aloitusskripti uudelleenkäynnistystä. Jos false ja parametri on määritetty uudelleenkäynnistys — käytetään tämän parametrin arvoa. Jos false ja parametri uudelleenkäynnistys ei määritetty - palvelu pysäytetään ja käynnistetään uudelleen (mutta systemd käyttää komentoa systemctl restart).
hasstatus — ilmoittaa, tukeeko palvelun aloitusskripti komentoa status. jos false, silloin käytetään parametrin arvoa tila. Oletus true.

Exec

Suorittaa ulkoisia komentoja. Jos et määritä parametreja luo, vain jos, ellei tai virkistävästi, komento suoritetaan aina, kun Puppet ajetaan. Pystyy käsittelemään ilmoituksia - suorittaa komennon.

vaihtoehdot:

resurssin nimi - suoritettava komento (valinnainen)
komento - suoritettava komento (jos sitä ei ole määritetty nimessä)
polku - polut, joista suoritettavaa tiedostoa etsitään
vain jos — jos tässä parametrissa määritetty komento täydennetään nollapalautuskoodilla, pääkomento suoritetaan
ellei — jos tässä parametrissa määritetty komento täydennetään nollasta poikkeavalla palautuskoodilla, pääkomento suoritetaan
luo — jos tässä parametrissa määritettyä tiedostoa ei ole olemassa, pääkomento suoritetaan
virkistävästi - jos true, komento suoritetaan vain, kun tämä exec saa ilmoituksen muista resursseista
CWD — hakemisto, josta komento suoritetaan
lähettämä — käyttäjä, jolta komento suoritetaan
toimittaja - kuinka komento suoritetaan:
- posix — lapsiprosessi luodaan yksinkertaisesti, muista määrittää polku
- kuori - komento käynnistetään kuoressa /bin/sh, ei voida määrittää polku, voit käyttää palloja, putkia ja muita kuoren ominaisuuksia. Yleensä tunnistetaan automaattisesti, jos siellä on erikoismerkkejä (|, ;, &&, || jne).

cron

Ohjaa cronjobs.

vaihtoehdot:

resurssin nimi - vain jonkinlainen tunniste
varmistaa — crownjob State:
- present - luo, jos sitä ei ole olemassa
- absent - poista, jos se on olemassa
komento - mikä komento suoritetaan
ympäristö - missä ympäristössä komento suoritetaan (luettelo ympäristömuuttujista ja niiden arvoista =)
lähettämä — keneltä käyttäjältä komento suoritetaan
minuutti, tunti, arkipäivä, kuukausi, kuukauden päivä - milloin ajaa cron. Jos jotakin näistä määritteistä ei ole määritetty, sen arvo crontabissa on *.

Puppet 6.0:ssa cron ikään kuin poistettu laatikosta nukkepalvelimessa, joten yleisellä sivustolla ei ole dokumentaatiota. Mutta hän on laatikossa nukke-agentissa, joten sitä ei tarvitse asentaa erikseen. Voit katsoa sen dokumentaatiota Puppetin viidennen version dokumentaatiossaTai GitHubissa.

Resursseista yleisesti

Resurssien ainutlaatuisuuden vaatimukset

Yleisin kohtaamamme virhe on Päällekkäinen ilmoitus. Tämä virhe ilmenee, kun hakemistossa näkyy vähintään kaksi samantyyppistä resurssia samalla nimellä.

Siksi kirjoitan uudelleen: saman solmun luettelot eivät saa sisältää samantyyppisiä resursseja samalla otsikolla!

Joskus on tarpeen asentaa paketteja, joilla on sama nimi, mutta joilla on eri paketinhallinta. Tässä tapauksessa sinun on käytettävä parametria namevirheen välttämiseksi:

package { 'ruby-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'gem',
}
package { 'python-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'pip',
}

Muilla resurssityypeillä on samanlaiset vaihtoehdot päällekkäisyyden välttämiseksi − name у palvelu, command у Exec, ja niin edelleen.

Metaparametrit

Jokaisella resurssityypillä on tiettyjä erityisparametreja sen luonteesta riippumatta.

Täydellinen luettelo metaparametreista Nukke-dokumentaatiossa.

Lyhyt lista:

edellyttää — Tämä parametri osoittaa, mistä resursseista tämä resurssi riippuu.
ennen - Tämä parametri määrittää, mitkä resurssit ovat riippuvaisia tästä resurssista.
merkitä — Tämä parametri määrittää, mistä resursseista tämä resurssi saa ilmoituksia.
ilmoittaa — Tämä parametri määrittää, mitkä resurssit saavat ilmoituksia tästä resurssista.

Kaikki luetellut metaparametrit hyväksyvät joko yhden resurssin linkin tai joukon linkkejä hakasulkeissa.

Linkkejä resursseihin

Resurssilinkki on yksinkertaisesti maininta resurssista. Niitä käytetään pääasiassa osoittamaan riippuvuuksia. Viittaus olemattomaan resurssiin aiheuttaa käännösvirheen.

Linkin syntaksi on seuraava: resurssityyppi isolla kirjaimella (jos tyypin nimi sisältää kaksoispisteitä, niin jokainen kaksoispisteiden välissä oleva nimen osa kirjoitetaan isolla), sitten resurssin nimi hakasulkeissa (nimen kirjainkoko ei muutu!). Välilyöntejä ei saa olla, hakasulkeet kirjoitetaan välittömästi tyypin nimen jälkeen.

Esimerkiksi:

file { '/file1': ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3': ensure => absent }
File['/file1'] -> File['/file3']

Riippuvuudet ja ilmoitukset

Dokumentaatio tästä.

Kuten aiemmin todettiin, yksinkertaiset riippuvuudet resurssien välillä ovat transitiivisia. Muuten, ole varovainen, kun lisäät riippuvuuksia - voit luoda syklisiä riippuvuuksia, jotka aiheuttavat käännösvirheen.

Toisin kuin riippuvuudet, ilmoitukset eivät ole ohimeneviä. Ilmoituksiin sovelletaan seuraavia sääntöjä:

Jos resurssi saa ilmoituksen, se päivitetään. Päivitystoimet riippuvat resurssityypistä − Exec suorittaa komennon, palvelu käynnistää palvelun uudelleen, paketti asentaa paketin uudelleen. Jos resurssille ei ole määritetty päivitystoimintoa, mitään ei tapahdu.
Yhden Puppetin ajon aikana resurssi päivitetään enintään kerran. Tämä on mahdollista, koska ilmoitukset sisältävät riippuvuuksia ja riippuvuuskaavio ei sisällä jaksoja.
Jos Puppet muuttaa resurssin tilaa, resurssi lähettää ilmoitukset kaikille sen tilaamille resursseille.
Jos resurssi päivitetään, se lähettää ilmoitukset kaikille sen tilatuille resursseille.

Määrittelemättömien parametrien käsittely

Yleensä jos jollakin resurssiparametrilla ei ole oletusarvoa eikä tätä parametria ole määritetty luettelossa, Puppet ei muuta tätä ominaisuutta solmun vastaavalle resurssille. Jos esimerkiksi tyyppinen resurssi tiedosto parametria ei ole määritetty owner, silloin Puppet ei muuta vastaavan tiedoston omistajaa.

Johdatus luokkiin, muuttujiin ja määritelmiin

Oletetaan, että meillä on useita solmuja, joilla on sama osa kokoonpanosta, mutta niissä on myös eroja - muuten voisimme kuvata sen kaikki yhdessä lohkossa node {}. Tietysti voit yksinkertaisesti kopioida identtisiä osia kokoonpanosta, mutta yleensä tämä on huono ratkaisu - kokoonpano kasvaa, ja jos muutat kokoonpanon yleistä osaa, joudut muokkaamaan samaa asiaa monessa paikassa. Samalla on helppo tehdä virhe, ja yleensä DRY (älä toista itseäsi) -periaate keksittiin syystä.

Tämän ongelman ratkaisemiseksi on olemassa sellainen suunnittelu kuin luokka.

Sarjat

Luokka on nimetty poppet-koodilohko. Luokkia tarvitaan koodin uudelleenkäyttöön.

Ensin luokka on kuvattava. Itse kuvaus ei lisää resursseja mihinkään. Luokka on kuvattu manifesteissa:

# Описание класса начинается с ключевого слова class и его названия.
# Дальше идёт тело класса в фигурных скобках.
class example_class {
    ...
}

Tämän jälkeen luokkaa voi käyttää:

# первый вариант использования — в стиле ресурса с типом class
class { 'example_class': }
# второй вариант использования — с помощью функции include
include example_class
# про отличие этих двух вариантов будет рассказано дальше

Esimerkki edellisestä tehtävästä - siirretään nginxin asennus ja konfigurointi luokkaan:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => 'puppet:///modules/example/nginx-conf',
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    include nginx_example
}

muuttujat

Edellisen esimerkin luokka ei ole lainkaan joustava, koska se tuo aina saman nginx-kokoonpanon. Tehdään polku konfiguraatiomuuttujaan, niin tämän luokan avulla voidaan asentaa nginx millä tahansa kokoonpanolla.

Se voi olla tehty käyttämällä muuttujia.

Huomio: Puppetin muuttujat ovat muuttumattomia!

Lisäksi muuttujaan pääsee käsiksi vasta sen ilmoittamisen jälkeen, muuten muuttujan arvo on undef.

Esimerkki muuttujien kanssa työskentelystä:

# создание переменных
$variable = 'value'
$var2 = 1
$var3 = true
$var4 = undef
# использование переменных
$var5 = $var6
file { '/tmp/text': content => $variable }
# интерполяция переменных — раскрытие значения переменных в строках. Работает только в двойных кавычках!
$var6 = "Variable with name variable has value ${variable}"

Nukkella on nimitilat, ja muuttujilla vastaavasti on näkyvyysalue: Samanniminen muuttuja voidaan määrittää eri nimiavaruuksiin. Kun muuttujan arvoa ratkaistaan, muuttujaa etsitään nykyisestä nimiavaruudesta, sitten sitä ympäröivästä nimiavaruudesta ja niin edelleen.

Esimerkkejä nimiavaruudesta:

globaali - luokan tai solmun kuvauksen ulkopuoliset muuttujat menevät sinne;
solmun nimiavaruus solmun kuvauksessa;
luokan nimiavaruus luokan kuvauksessa.

Voit välttää epäselvyyden muuttujaa käytettäessä määrittämällä nimiavaruuden muuttujan nimessä:

# переменная без пространства имён
$var
# переменная в глобальном пространстве имён
$::var
# переменная в пространстве имён класса
$classname::var
$::classname::var

Sovitaan, että polku nginx-kokoonpanoon on muuttujassa $nginx_conf_source. Sitten luokka näyttää tältä:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => $nginx_conf_source,   # здесь используем переменную вместо фиксированной строки
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    $nginx_conf_source = 'puppet:///modules/example/nginx-conf'
    include nginx_example
}

Annettu esimerkki on kuitenkin huono, koska on "salaista tietoa", että jossain luokan sisällä käytetään muuttujaa sellaisella ja sellaisella nimellä. On paljon oikeampaa tehdä tämä tieto yleiseksi - luokilla voi olla parametreja.

Luokkaparametrit ovat muuttujia luokan nimiavaruudessa, ne määritetään luokan otsikossa ja niitä voidaan käyttää kuten tavallisia muuttujia luokan rungossa. Parametrien arvot määritetään, kun luokkaa käytetään luettelossa.

Parametri voidaan asettaa oletusarvoon. Jos parametrilla ei ole oletusarvoa eikä arvoa ole asetettu, kun sitä käytetään, se aiheuttaa käännösvirheen.

Parametrisoidaan luokka yllä olevasta esimerkistä ja lisätään kaksi parametria: ensimmäinen pakollinen on polku kokoonpanoon ja toinen, valinnainen, on paketin nimi nginxin kanssa (esim. Debianissa on paketteja nginx, nginx-light, nginx-full).

# переменные описываются сразу после имени класса в круглых скобках
class nginx_example (
  $conf_source,
  $package_name = 'nginx-light', # параметр со значением по умолчанию
) {
  package { $package_name:
    ensure => installed,
  }
  -> file { '/etc/nginx':
    ensure  => directory,
    source  => $conf_source,
    recurse => true,
    purge   => true,
    force   => true,
  }
  ~> service { 'nginx':
    ensure => running,
    enable => true,
  }
}

node 'server2.testdomain' {
  # если мы хотим задать параметры класса, функция include не подойдёт* — нужно использовать resource-style declaration
  # *на самом деле подойдёт, но про это расскажу в следующей серии. Ключевое слово "Hiera".
  class { 'nginx_example':
    conf_source => 'puppet:///modules/example/nginx-conf',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Puppetissa muuttujat kirjoitetaan. Syödä monia tietotyyppejä. Tietotyyppejä käytetään tyypillisesti luokkiin ja määritelmiin siirrettyjen parametriarvojen vahvistamiseen. Jos välitetty parametri ei vastaa määritettyä tyyppiä, tapahtuu käännösvirhe.

Tyyppi kirjoitetaan välittömästi ennen parametrin nimeä:

class example (
  String $param1,
  Integer $param2,
  Array $param3,
  Hash $param4,
  Hash[String, String] $param5,
) {
  ...
}

Luokat: sisällytä luokan nimi vs class{'classname':}

Jokainen luokka on tyyppinen resurssi luokka. Kuten minkä tahansa muun resurssin kohdalla, samassa solmussa ei voi olla kahta saman luokan esiintymää.

Jos yrität lisätä luokan samaan solmuun kahdesti käyttämällä class { 'classname':} (ei eroa, eri tai identtiset parametrit), tulee käännösvirhe. Mutta jos käytät luokkaa resurssityylissä, voit välittömästi määrittää kaikki sen parametrit luettelossa.

Jos kuitenkin käytät include, niin luokkaa voidaan lisätä niin monta kertaa kuin halutaan. Tosiasia on, että include on idempotentti funktio, joka tarkistaa, onko luokkaa lisätty hakemistoon. Jos luokka ei ole hakemistossa, se lisää sen, ja jos se on jo olemassa, se ei tee mitään. Mutta käytön tapauksessa include Et voi asettaa luokkaparametreja luokan määrityksen aikana - kaikki vaaditut parametrit on asetettava ulkoisessa tietolähteessä - Hiera tai ENC. Puhumme niistä seuraavassa artikkelissa.

Määrittää

Kuten edellisessä lohkossa sanottiin, sama luokka ei voi olla läsnä solmussa useammin kuin kerran. Joissakin tapauksissa sinun on kuitenkin voitava käyttää samaa koodilohkoa eri parametreilla samassa solmussa. Toisin sanoen tarvitaan omaa resurssityyppiä.

Esimerkiksi PHP-moduulin asentamiseksi teemme seuraavat Avitossa:

Asenna paketti tämän moduulin kanssa.
Luodaan tälle moduulille asetustiedosto.
Luomme symlinkin php-fpm:n konfiguraatioon.
Luomme symlinkin php cli:n konfiguraatioon.

Tällaisissa tapauksissa suunnittelu, kuten määritellä (määritelty, määritelty tyyppi, määritelty resurssityyppi). Define on samanlainen kuin luokka, mutta siinä on eroja: ensinnäkin jokainen Define on resurssityyppi, ei resurssi; toiseksi jokaisella määritelmällä on implisiittinen parametri $title, johon resurssin nimi menee, kun se ilmoitetaan. Kuten luokkienkin tapauksessa, on ensin kuvattava määritelmä, jonka jälkeen sitä voidaan käyttää.

Yksinkertaistettu esimerkki PHP-moduulista:

define php74::module (
  $php_module_name = $title,
  $php_package_name = "php7.4-${title}",
  $version = 'installed',
  $priority = '20',
  $data = "extension=${title}.son",
  $php_module_path = '/etc/php/7.4/mods-available',
) {
  package { $php_package_name:
    ensure          => $version,
    install_options => ['-o', 'DPkg::NoTriggers=true'],  # триггеры дебиановских php-пакетов сами создают симлинки и перезапускают сервис php-fpm - нам это не нужно, так как и симлинками, и сервисом мы управляем с помощью Puppet
  }
  -> file { "${php_module_path}/${php_module_name}.ini":
    ensure  => $ensure,
    content => $data,
  }
  file { "/etc/php/7.4/cli/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
  file { "/etc/php/7.4/fpm/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
}

node server3.testdomain {
  php74::module { 'sqlite3': }
  php74::module { 'amqp': php_package_name => 'php-amqp' }
  php74::module { 'msgpack': priority => '10' }
}

Helpoin tapa havaita Duplicate-ilmoitusvirhe on Määritä. Näin tapahtuu, jos määritelmässä on resurssi, jolla on vakionimi, ja jossakin solmussa on kaksi tai useampia tämän määritelmän esiintymiä.

Tältä on helppo suojautua: kaikilla määritelmän sisällä olevilla resursseilla on oltava nimi riippuen $title. Vaihtoehtona on idempotentti resurssien lisääminen, yksinkertaisimmassa tapauksessa riittää, että siirrät määritelmän kaikille esiintymille yhteiset resurssit erilliseen luokkaan ja sisällytät tämän luokan määritelmään - funktio include idempotentti.

On olemassa muita tapoja saavuttaa idempotenssi resursseja lisättäessä, nimittäin funktioiden avulla defined и ensure_resources, mutta kerron siitä seuraavassa jaksossa.

Luokkien ja määritelmien riippuvuudet ja ilmoitukset

Luokat ja määritelmät lisäävät seuraavat säännöt riippuvuuksien ja ilmoitusten käsittelyyn:

riippuvuus luokasta/määrityksestä lisää riippuvuuksia luokan/määritelmän kaikista resursseista;
luokka/määrittele riippuvuus lisää riippuvuuksia kaikkiin luokka/määritele resursseihin;
class/define-ilmoitus ilmoittaa kaikille luokan/määrittelyn resursseille;
class/define-tilaus tilaa kaikki class/define-resurssit.

Ehdolliset lausunnot ja valitsimet

Dokumentaatio tästä.

if

Täällä kaikki on yksinkertaista:

if ВЫРАЖЕНИЕ1 {
  ...
} elsif ВЫРАЖЕНИЕ2 {
  ...
} else {
  ...
}

ellei

ellei if ole käänteinen: koodilohko suoritetaan, jos lauseke on epätosi.

unless ВЫРАЖЕНИЕ {
  ...
}

tapaus

Tässäkään ei ole mitään monimutkaista. Voit käyttää arvoina säännöllisiä arvoja (merkkijonoja, numeroita jne.), säännöllisiä lausekkeita ja tietotyyppejä.

case ВЫРАЖЕНИЕ {
  ЗНАЧЕНИЕ1: { ... }
  ЗНАЧЕНИЕ2, ЗНАЧЕНИЕ3: { ... }
  default: { ... }
}

Valitsijat

Valitsin on kielirakenne, joka on samanlainen kuin case, mutta koodilohkon suorittamisen sijaan se palauttaa arvon.

$var = $othervar ? { 'val1' => 1, 'val2' => 2, default => 3 }

Moduulit

Kun kokoonpano on pieni, se voidaan helposti pitää yhdessä luettelossa. Mutta mitä enemmän määrityksiä kuvaamme, sitä enemmän luokkia ja solmuja luettelossa on, se kasvaa ja sen kanssa työskentely on hankalaa.

Lisäksi ongelmana on koodin uudelleenkäyttö - kun kaikki koodi on yhdessä luettelossa, on vaikeaa jakaa tätä koodia muiden kanssa. Näiden kahden ongelman ratkaisemiseksi Puppetilla on entiteetti nimeltä moduulit.

Moduulit - nämä ovat erilliseen hakemistoon sijoitettuja luokkien, määritelmien ja muiden Puppet-entiteettien joukkoja. Toisin sanoen moduuli on itsenäinen osa Nukkelogiikkaa. Esimerkiksi nginx:n kanssa työskentelyyn voi olla moduuli, joka sisältää sen ja vain sen, mitä nginxin kanssa työskentelyyn tarvitaan, tai voi olla moduuli PHP:n kanssa työskentelyä varten ja niin edelleen.

Moduulit on versioitu, ja moduulien riippuvuuksia toisistaan myös tuetaan. Siellä on avoin moduulivarasto - Puppet Forge.

Nukkepalvelimella moduulit sijaitsevat juurihakemiston modules-alihakemistossa. Jokaisen moduulin sisällä on vakiohakemisto - manifestit, tiedostot, mallit, lib ja niin edelleen.

Tiedostorakenne moduulissa

Moduulin juurihakemisto voi sisältää seuraavat hakemistot kuvaavilla nimillä:

manifests - Se sisältää manifesteja
files - Se sisältää tiedostoja
templates - Se sisältää malleja
lib - Se sisältää Ruby-koodin

Tämä ei ole täydellinen luettelo hakemistoista ja tiedostoista, mutta se riittää tähän artikkeliin toistaiseksi.

Moduulin resurssien ja tiedostojen nimet

Dokumentaatio tästä.

Moduulin resursseja (luokkia, määritelmiä) ei voi nimetä haluamallasi tavalla. Lisäksi resurssin nimen ja sen tiedoston nimen välillä on suora vastaavuus, josta Puppet etsii kuvauksen kyseisestä resurssista. Jos rikot nimeämissääntöjä, Puppet ei yksinkertaisesti löydä resurssin kuvausta ja saat käännösvirheen.

Säännöt ovat yksinkertaiset:

Kaikkien moduulin resurssien on oltava moduulin nimiavaruudessa. Jos moduulia kutsutaan foo, niin kaikki siinä olevat resurssit tulee nimetä foo::<anything>, tai vain foo.
Resurssin moduulin nimellä on oltava tiedostossa init.pp.
Muiden resurssien tapauksessa tiedostojen nimeämisjärjestelmä on seuraava:
- moduulin nimen sisältävä etuliite hylätään
- kaikki kaksoispisteet, jos sellaisia on, korvataan vinoviivalla
- laajennus on lisätty .pp

Esitän esimerkin. Oletetaan, että kirjoitan moduulia nginx. Se sisältää seuraavat resurssit:

luokka nginx kuvataan manifestissa init.pp;
luokka nginx::service kuvataan manifestissa service.pp;
määritellä nginx::server kuvataan manifestissa server.pp;
määritellä nginx::server::location kuvataan manifestissa server/location.pp.

Mallit

Tiedät varmasti itse, mitä mallit ovat; en kuvaile niitä tässä yksityiskohtaisesti. Mutta jätän sen varmuuden vuoksi linkki Wikipediaan.

Mallien käyttö: Mallin merkitystä voidaan laajentaa funktiolla template, joka välitetään malliin. tyyppisille resursseille tiedosto käytetään yhdessä parametrin kanssa content. Esimerkiksi näin:

file { '/tmp/example': content => template('modulename/templatename.erb')

Näytä polku <modulename>/<filename> tarkoittaa tiedostoa <rootdir>/modules/<modulename>/templates/<filename>.

Lisäksi on toiminto inline_template — se vastaanottaa syötteenä mallitekstin, ei tiedoston nimeä.

Malleissa voit käyttää kaikkia nykyisen laajuuden Puppet-muuttujia.

Puppet tukee ERB- ja EPP-muotoisia malleja:

Lyhyesti ERB:stä

Ohjausrakenteet:

<%= ВЫРАЖЕНИЕ %> — lisää lausekkeen arvo
<% ВЫРАЖЕНИЕ %> — laskea lausekkeen arvon (lisäämättä sitä). Ehdolliset lauseet (if) ja silmukat (kukin) menevät yleensä tähän.
<%# КОММЕНТАРИЙ %>

ERB:n lausekkeet kirjoitetaan rubiinilla (ERB on itse asiassa Embedded Ruby).

Jos haluat käyttää muuttujia luettelosta, sinun on lisättävä @ muuttujan nimeen. Jos haluat poistaa ohjausrakenteen jälkeen näkyvän rivinvaihdon, sinun on käytettävä sulkevaa tunnistetta -%>.

Esimerkki mallin käytöstä

Oletetaan, että kirjoitan moduulia ZooKeeperin ohjaamiseksi. Määrityksen luomisesta vastaava luokka näyttää suunnilleen tältä:

class zookeeper::configure (
  Array[String] $nodes,
  Integer $port_client,
  Integer $port_quorum,
  Integer $port_leader,
  Hash[String, Any] $properties,
  String $datadir,
) {
  file { '/etc/zookeeper/conf/zoo.cfg':
    ensure  => present,
    content => template('zookeeper/zoo.cfg.erb'),
  }
}

Ja vastaava malli zoo.cfg.erb - Joten:

<% if @nodes.length > 0 -%>
<% @nodes.each do |node, id| -%>
server.<%= id %>=<%= node %>:<%= @port_leader %>:<%= @port_quorum %>;<%= @port_client %>
<% end -%>
<% end -%>

dataDir=<%= @datadir %>

<% @properties.each do |k, v| -%>
<%= k %>=<%= v %>
<% end -%>

Faktat ja sisäänrakennetut muuttujat

Usein kokoonpanon tietty osa riippuu siitä, mitä solmussa sillä hetkellä tapahtuu. Esimerkiksi riippuen siitä, mikä Debian-julkaisu on, sinun on asennettava jokin paketin versio. Voit seurata kaikkea tätä manuaalisesti ja kirjoittaa luetteloita uudelleen, jos solmut muuttuvat. Mutta tämä ei ole vakava lähestymistapa; automaatio on paljon parempi.

Tietojen saamiseksi solmuista Puppetilla on mekanismi, jota kutsutaan faktoiksi. tosiasiat - tämä on tietoa solmusta, saatavilla manifesteissa tavallisten muuttujien muodossa globaalissa nimiavaruudessa. Esimerkiksi isäntänimi, käyttöjärjestelmän versio, prosessorin arkkitehtuuri, käyttäjäluettelo, luettelo verkkoliitännöistä ja niiden osoitteista ja paljon muuta. Faktat ovat saatavilla luetteloissa ja malleissa tavallisina muuttujina.

Esimerkki tosiasioiden kanssa työskentelystä:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

Muodollisesti faktalla on nimi (merkkijono) ja arvo (saatavana on useita tyyppejä: merkkijonoja, taulukoita, sanakirjoja). Syödä joukko sisäänrakennettuja tosiasioita. Voit myös kirjoittaa omasi. Faktankerääjät on kuvattu kuten Rubyn toiminnotjoko nimellä suoritettavat tiedostot. Faktat voidaan esittää myös muodossa tekstitiedostoja datalla solmuissa.

Toiminnan aikana nukkeagentti kopioi ensin kaikki saatavilla olevat faktankerääjät pappetserveristä solmuun, minkä jälkeen se käynnistää ne ja lähettää kerätyt faktat palvelimelle; Tämän jälkeen palvelin alkaa laatia luetteloa.

Faktat suoritettavien tiedostojen muodossa

Tällaiset tosiasiat sijoitetaan hakemiston moduuleihin facts.d. Tietysti tiedostojen on oltava suoritettavia. Ajettaessa niiden on tulostettava tiedot vakiotulostukseen joko YAML- tai avain=arvo-muodossa.

Älä unohda, että tosiasiat koskevat kaikkia solmuja, joita ohjaa poppet-palvelin, johon moduulisi on asennettu. Varmista siis skriptissä, että järjestelmässä on kaikki ohjelmat ja tiedostot, jotka ovat tarpeen faktasi toimimiseksi.

#!/bin/sh
echo "testfact=success"

#!/bin/sh
echo '{"testyamlfact":"success"}'

Rubiini faktoja

Tällaiset tosiasiat sijoitetaan hakemiston moduuleihin lib/facter.

# всё начинается с вызова функции Facter.add с именем факта и блоком кода
Facter.add('ladvd') do
# в блоках confine описываются условия применимости факта — код внутри блока должен вернуть true, иначе значение факта не вычисляется и не возвращается
  confine do
    Facter::Core::Execution.which('ladvdc') # проверим, что в PATH есть такой исполняемый файл
  end
  confine do
    File.socket?('/var/run/ladvd.sock') # проверим, что есть такой UNIX-domain socket
  end
# в блоке setcode происходит собственно вычисление значения факта
  setcode do
    hash = {}
    if (out = Facter::Core::Execution.execute('ladvdc -b'))
      out.split.each do |l|
        line = l.split('=')
        next if line.length != 2
        name, value = line
        hash[name.strip.downcase.tr(' ', '_')] = value.strip.chomp(''').reverse.chomp(''').reverse
      end
    end
    hash  # значение последнего выражения в блоке setcode является значением факта
  end
end

Faktoja tekstistä

Tällaiset tosiasiat sijoitetaan hakemiston solmuihin /etc/facter/facts.d vanhassa Nukke tai /etc/puppetlabs/facts.d uudessa Nukkessa.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

Tosiasioihin pääseminen

On kaksi tapaa lähestyä tosiasioita:

sanakirjan kautta $facts: $facts['fqdn'];
käyttämällä tosiasian nimeä muuttujan nimenä: $fqdn.

On parasta käyttää sanakirjaa $facts, tai vielä parempi, ilmaise globaali nimiavaruus ($::facts).

Tässä on asiakirjan asiaankuuluva osa.

Sisäänrakennetut muuttujat

Faktojen lisäksi on olemassa myös joitain muuttujia, saatavilla maailmanlaajuisessa nimiavaruudessa.

luotettavia faktoja — muuttujat, jotka otetaan asiakkaan varmenteesta (koska varmenne yleensä myönnetään poppet-palvelimella, agentti ei voi vain ottaa ja muuttaa varmennetaan, joten muuttujat ovat "luotettuja"): varmenteen nimi, varmenteen nimi isäntä ja verkkotunnus, varmenteen laajennukset.
palvelimen tosiasiat —palvelimen tietoihin liittyvät muuttujat — versio, nimi, palvelimen IP-osoite, ympäristö.
agenttien tosiasiat — muuttujat, jotka on lisätty suoraan nukke-agentin eikä tekijän mukaan — varmenteen nimi, agenttiversio, nukkeversio.
master-muuttujat - Pappetmaster-muuttujat (sic!). Se on suunnilleen sama kuin sisällä palvelimen tosiasiat, sekä konfigurointiparametrien arvot ovat saatavilla.
kääntäjän muuttujat — kääntäjämuuttujat, jotka eroavat kussakin laajuudessa: nykyisen moduulin nimi ja sen moduulin nimi, jossa nykyistä objektia käytettiin. Niitä voidaan käyttää esimerkiksi tarkistamaan, ettei yksityisluokkia käytetä suoraan muista moduuleista.

Lisäys 1: kuinka suorittaa ja korjata kaikki tämä?

Artikkeli sisälsi monia esimerkkejä nukkekoodista, mutta se ei kertonut meille ollenkaan, kuinka tämä koodi suoritetaan. No, korjaan itseäni.

Puppetin suorittamiseen riittää agentti, mutta useimmissa tapauksissa tarvitset myös palvelimen.

agentti

Ainakin versiosta XNUMX lähtien, nukke-agenttipaketit alkaen virallinen Puppetlabs-arkisto sisältävät kaikki riippuvuudet (ruby ja vastaavat jalokivet), joten asennusongelmia ei ole (puhun Debian-pohjaisista jakeluista - emme käytä RPM-pohjaisia jakeluja).

Yksinkertaisimmassa tapauksessa nukkekokoonpanon käyttämiseksi riittää käynnistää agentti palvelimettomassa tilassa: jos nukkekoodi kopioidaan solmuun, käynnistä puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

On tietysti parempi määrittää palvelin ja suorittaa agentit solmuissa demonitilassa - sitten puolen tunnin välein he käyttävät palvelimelta ladattua kokoonpanoa.

Voit jäljitellä työn työntömallia - mene kiinnostavaan solmuun ja aloita sudo puppet agent -t. Avain -t (--test) sisältää itse asiassa useita vaihtoehtoja, jotka voidaan ottaa käyttöön yksittäin. Näitä vaihtoehtoja ovat seuraavat:

älä suorita demonitilassa (oletusarvoisesti agentti käynnistyy demonitilassa);
sammuta luettelon käyttöönoton jälkeen (oletusarvoisesti agentti jatkaa työskentelyä ja käyttää määritystä puolen tunnin välein);
kirjoittaa yksityiskohtainen työpäiväkirja;
näyttää muutokset tiedostoissa.

Agentissa on toimintatila ilman muutoksia - voit käyttää sitä, kun et ole varma, että olet kirjoittanut oikean konfiguraation ja haluat tarkistaa, mitä agentti tarkalleen muuttaa toiminnan aikana. Tämä tila otetaan käyttöön parametrilla --noop komentorivillä: sudo puppet agent -t --noop.

Lisäksi voit ottaa käyttöön työn virheenkorjauslokin - siinä nukke kirjoittaa kaikista suorittamistaan toiminnoista: resurssista, jota se parhaillaan käsittelee, tämän resurssin parametreista, siitä, mitä ohjelmia se käynnistää. Tämä on tietysti parametri --debug.

Server

En käsittele tässä artikkelissa pappetserverin täyttä asennusta ja koodin käyttöönottoa siihen; sanon vain, että palvelimesta on valmiina täysin toimiva versio, joka ei vaadi lisämäärityksiä toimiakseen pienen palvelimen kanssa. solmujen lukumäärä (esimerkiksi jopa sata). Suurempi määrä solmuja vaatii virityksen - oletusarvoisesti nukkepalvelin käynnistää enintään neljä työntekijää, suuremman suorituskyvyn saavuttamiseksi sinun on lisättävä niiden määrää ja älä unohda lisätä muistirajoja, muuten palvelin kerää roskat suurimman osan ajasta.

Koodin käyttöönotto – jos tarvitset sitä nopeasti ja helposti, katso (r10k)[https://github.com/puppetlabs/r10k], pienille asennuksille sen pitäisi riittää.

Lisäys 2: Koodausohjeet

Sijoita kaikki logiikka luokkiin ja määritelmiin.
Säilytä luokat ja määritelmät moduuleissa, älä solmuja kuvaavissa luetteloissa.
Käytä tosiasioita.
Älä tee jos-lauseita isäntänimien perusteella.
Voit vapaasti lisätä parametreja luokille ja määritelmille - tämä on parempi kuin luokan/määritelmän runkoon piilotettu implisiittinen logiikka.

Selitän seuraavassa artikkelissa, miksi suosittelen tämän tekemistä.

Johtopäätös

Lopetetaan esittely. Seuraavassa artikkelissa kerron sinulle Hierasta, ENC:stä ja PuppetDB:stä.

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Itse asiassa materiaalia on paljon enemmän - voin kirjoittaa artikkeleita seuraavista aiheista, äänestää siitä, mistä olisit kiinnostunut lukemaan:

59,1%Kehittyneet nukkerakenteet – jotain seuraavan tason paskaa: silmukat, kartoitus ja muut lambda-lausekkeet, resurssien kerääjät, viety resurssit ja isäntien välinen viestintä Puppetin kautta, tunnisteet, toimittajat, abstraktit tietotyypit.13
31,8%"Olen äitini admin" eli kuinka me Avitossa ystävystyimme useiden eri versioiden poppet-palvelimien kanssa, ja periaatteessa se osa poppet-palvelimen hallintaa.7
81,8%Kuinka kirjoitamme nukkekoodin: instrumentointi, dokumentaatio, testaus, CI/CD.18

22 käyttäjää äänesti. 9 käyttäjää pidättyi äänestämästä.

Lähde: will.com

Johdatus Puppetiin

Perustiedot

Johdatus manifesteihin

Syntaksi ja koodityyli

Tiedostojen sijainti pappetserverillä

Pari esimerkkiä taistelusta

Kuvaus solmusta ja siinä olevasta resurssista

Solmun resurssien väliset suhteet

Resurssityypit

tiedosto

paketti

palvelu

Exec

cron

Resursseista yleisesti

Resurssien ainutlaatuisuuden vaatimukset

Metaparametrit

Linkkejä resursseihin

Riippuvuudet ja ilmoitukset

Määrittelemättömien parametrien käsittely

Johdatus luokkiin, muuttujiin ja määritelmiin

Sarjat

muuttujat

Luokat: sisällytä luokan nimi vs class{'classname':}

Määrittää

Luokkien ja määritelmien riippuvuudet ja ilmoitukset

Ehdolliset lausunnot ja valitsimet

if

ellei

tapaus

Valitsijat

Moduulit

Tiedostorakenne moduulissa

Moduulin resurssien ja tiedostojen nimet

Mallit

Lyhyesti ERB:stä

Esimerkki mallin käytöstä

Faktat ja sisäänrakennetut muuttujat

Faktat suoritettavien tiedostojen muodossa

Rubiini faktoja

Faktoja tekstistä

Tosiasioihin pääseminen

Sisäänrakennetut muuttujat

Lisäys 1: kuinka suorittaa ja korjata kaikki tämä?

agentti

Server

Lisäys 2: Koodausohjeet

Johtopäätös

Itse asiassa materiaalia on paljon enemmän - voin kirjoittaa artikkeleita seuraavista aiheista, äänestää siitä, mistä olisit kiinnostunut lukemaan: