Puppet er stillingarstjórnunarkerfi. Það er notað til að koma vélum í æskilegt ástand og viðhalda þessu ástandi.

Ég hef unnið með Puppet í meira en fimm ár núna. Þessi texti er í meginatriðum þýdd og endurskipuð samantekt á lykilatriðum úr opinberu skjölunum, sem gerir byrjendum kleift að skilja kjarna Puppet fljótt.

Grunnupplýsingar

Stýrikerfi Puppet er biðlara-þjónn, þó það styðji einnig netþjónalausa rekstur með takmarkaðri virkni.

Notað er dráttarlíkan af rekstri: sjálfgefið, einu sinni á hálftíma fresti, hafa viðskiptavinir samband við netþjóninn til að fá uppsetningu og nota hana. Ef þú hefur unnið með Ansible, þá nota þeir annað ýtingarlíkan: stjórnandinn byrjar ferlið við að beita stillingunum, viðskiptavinirnir sjálfir munu ekki nota neitt.

Við netsamskipti er tvíhliða TLS dulkóðun notuð: þjónninn og viðskiptavinurinn hafa sína eigin einkalykla og samsvarandi vottorð. Venjulega gefur þjónninn út vottorð fyrir viðskiptavini, en í grundvallaratriðum er hægt að nota utanaðkomandi CA.

Kynning á stefnuskrám

Í Puppet terminology á dúkkuþjóninn tengja hnúta (hnútar). Uppsetningin fyrir hnútana er skrifuð í stefnuskrám á sérstöku forritunarmáli - Puppet DSL.

Puppet DSL er yfirlýsingamál. Það lýsir æskilegu ástandi hnútsins í formi yfirlýsinga um einstakar auðlindir, til dæmis:

Skráin er til og hún hefur sérstakt efni.
Pakkinn er settur upp.
Þjónustan er hafin.

Hægt er að tengja auðlindir:

Það eru ósjálfstæði, þau hafa áhrif á í hvaða röð auðlindir eru notaðar.
Til dæmis, "settu fyrst upp pakkann, breyttu síðan stillingarskránni og ræstu síðan þjónustuna."
Það eru tilkynningar - ef auðlind hefur breyst sendir hún tilkynningar til auðlindanna sem eru áskrifendur að henni.
Til dæmis, ef stillingarskráin breytist geturðu sjálfkrafa endurræst þjónustuna.

Að auki hefur Puppet DSL aðgerðir og breytur, svo og skilyrtar staðhæfingar og veljara. Ýmsar sniðmátsaðferðir eru einnig studdar - EPP og ERB.

Puppet er skrifuð í Ruby, svo mörg smíðanna og hugtökin eru tekin þaðan. Ruby gerir þér kleift að stækka Puppet - bæta við flókinni rökfræði, nýjum tegundum auðlinda, aðgerðum.

Á meðan Puppet er í gangi eru birtingarmyndir fyrir hvern tiltekinn hnút á þjóninum settar saman í möppu. Directory er listi yfir tilföng og tengsl þeirra eftir útreikninga á gildi falla, breyta og stækkun skilyrtrar fullyrðinga.

Setningafræði og kóðastíll

Hér eru hlutar af opinberu skjölunum sem hjálpa þér að skilja setningafræðina ef dæmin sem gefin eru eru ekki nóg:

Hér er dæmi um hvernig upplýsingaskráin lítur út:

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

Inndráttur og línuskil eru ekki nauðsynlegur hluti af upplýsingaskránni, en það er mælt með því stíl fylgja. Samantekt:

Tveggja bila inndráttur, flipar eru ekki notaðir.
Hrokkið axlabönd eru aðskilin með bili; tvípunktar eru ekki aðskildir með bili.
Kommur á eftir hverri færibreytu, þar með talið þeirri síðustu. Hver færibreyta er á sérstakri línu. Undantekning er gerð fyrir tilvikið án breytu og einni færibreytu: þú getur skrifað á eina línu og án kommu (þ.e.a.s. resource { 'title': } и resource { 'title': param => value }).
Örvarnar á breytunum ættu að vera á sama stigi.
Örvar til aðfangatengsla eru skrifaðar fyrir framan þær.

Staðsetning skráa á pappetserver

Til frekari útskýringa mun ég kynna hugtakið „rótarskrá“. Rótarskráin er skráin sem inniheldur Puppet stillinguna fyrir tiltekinn hnút.

Rótarskráin er mismunandi eftir útgáfu Puppet og umhverfinu sem er notað. Umhverfi eru sjálfstæðar stillingar sem eru geymdar í aðskildum möppum. Venjulega notað í samsetningu með git, en þá er umhverfi búið til úr git greinum. Samkvæmt því er hver hnút staðsettur í einu eða öðru umhverfi. Þetta er hægt að stilla á hnútnum sjálfum, eða í ENC, sem ég mun tala um í næstu grein.

Í þriðju útgáfunni ("gamla puppet") var grunnskráin /etc/puppet. Notkun umhverfisins er valfrjáls - til dæmis notum við þau ekki með gömlu puppetunni. Ef umhverfi er notað eru þau venjulega geymd í /etc/puppet/environments, rótarskráin verður umhverfisskráin. Ef umhverfi er ekki notað verður rótarskráin grunnskráin.
Frá og með fjórðu útgáfunni („nýja puppet“) varð notkun umhverfisins skylda og grunnskráin var færð í /etc/puppetlabs/code. Í samræmi við það eru umhverfi geymd í /etc/puppetlabs/code/environments, rótarskrá er umhverfisskráin.

Það verður að vera undirskrá í rótarskránni manifests, sem inniheldur eitt eða fleiri birtingarmyndir sem lýsa hnútunum. Að auki ætti að vera undirskrá modules, sem inniheldur einingarnar. Ég skal segja þér hvaða einingar eru aðeins síðar. Að auki getur gamla puppet einnig verið með undirskrá files, sem inniheldur ýmsar skrár sem við afritum á hnútana. Í nýju Puppet eru allar skrár settar í einingar.

Manifest skrár hafa endinguna .pp.

Nokkur dæmi um bardaga

Lýsing á hnút og auðlind á honum

Á hnútnum server1.testdomain búa til skrá /etc/issue með innihaldi Debian GNU/Linux n l. Skráin verður að vera í eigu notanda og hóps root, aðgangsréttur verður að vera 644.

Við skrifum stefnuskrá:

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 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

Tengsl milli auðlinda á hnút

Á hnútnum server2.testdomain nginx verður að vera í gangi, vinna með áður tilbúna uppsetningu.

Við skulum sundurliða vandamálið:

Það þarf að setja upp pakkann nginx.
Nauðsynlegt er að stillingarskrárnar séu afritaðar af þjóninum.
Þjónustan þarf að vera í gangi nginx.
Ef uppsetningin er uppfærð verður að endurræsa þjónustuna.

Við skrifum stefnuskrá:

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 получает уведомление,
  # соответствующий сервис перезапускается.
}

Til að þetta virki þarftu um það bil eftirfarandi skráarstaðsetningu á brúðuþjóninum:

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

Auðlindategundir

Heildarlista yfir studdar auðlindagerðir má finna hér í skjölunum, hér mun ég lýsa fimm grunntegundum, sem í reynd minni duga til að leysa flest vandamál.

skrá

Heldur utan um skrár, möppur, tákntengla, innihald þeirra og aðgangsrétt.

Breytur:

heiti auðlindar — slóð að skránni (valfrjálst)
leið — slóð að skránni (ef hún er ekki tilgreind í nafninu)
tryggja - skráartegund:
- absent - eyða skrá
- present - það verður að vera skrá af hvaða gerð sem er (ef það er engin skrá verður venjuleg skrá búin til)
- file - venjuleg skrá
- directory - Skrá
- link - táknhlekkur
efni — innihald skráar (hentar aðeins fyrir venjulegar skrár, ekki hægt að nota með uppspretta eða miða)
uppspretta — hlekkur á slóðina sem þú vilt afrita innihald skrárinnar (ekki hægt að nota með efni eða miða). Hægt að tilgreina sem annað hvort URI með skema puppet: (þá verða skrár frá brúðuþjóninum notaðar), og með kerfinu http: (Ég vona að það sé ljóst hvað mun gerast í þessu tilfelli), og jafnvel með skýringarmyndinni file: eða sem alger slóð án skema (þá verður skráin frá staðbundnum FS á hnútnum notuð)
miða — þar sem tákntengillinn ætti að benda (ekki hægt að nota með efni eða uppspretta)
eigandi — notandinn sem ætti að eiga skrána
hópurinn — hópnum sem skráin ætti að tilheyra
ham - skráarheimildir (sem strengur)
endurgjalda - gerir endurkvæma skráarvinnslu kleift
hreinsa - gerir kleift að eyða skrám sem ekki er lýst í Puppet
þvinga - gerir kleift að eyða möppum sem ekki er lýst í Puppet

pakki

Setur upp og fjarlægir pakka. Geta séð um tilkynningar - setur pakkann upp aftur ef færibreytan er tilgreind reinstall_on_refresh.

Breytur:

heiti auðlindar — nafn pakka (valfrjálst)
nafn — pakkaheiti (ef það er ekki tilgreint í nafninu)
veitendur — pakkastjóra til að nota
tryggja — æskilegt ástand pakkans:
- present, installed - hvaða útgáfa sem er uppsett
- latest - nýjasta útgáfan uppsett
- absent - eytt (apt-get remove)
- purged - eytt ásamt stillingarskrám (apt-get purge)
- held - pakkaútgáfa er læst (apt-mark hold)
- любая другая строка — tilgreind útgáfa er uppsett
reinstall_on_refresh - ef að true, þá verður pakkinn settur upp aftur þegar tilkynningin berst. Gagnlegt fyrir dreifingu sem byggir á uppruna, þar sem endurbyggja pakka gæti verið nauðsynleg þegar skipt er um byggingarfæribreytur. Sjálfgefið false.

þjónusta

Stjórnar þjónustu. Getur unnið úr tilkynningum - endurræsir þjónustuna.

Breytur:

heiti auðlindar — þjónusta sem á að stjórna (valfrjálst)
nafn — þjónustan sem þarf að hafa umsjón með (ef það er ekki tilgreint í nafninu)
tryggja — æskilegt ástand þjónustunnar:
- running - hleypt af stokkunum
- stopped - hætt
gera — stjórnar getu til að hefja þjónustuna:
- true - sjálfvirk keyrsla er virkjuð (systemctl enable)
- mask - dulbúnir (systemctl mask)
- false — sjálfvirk keyrsla er óvirk (systemctl disable)
endurræsa - skipun til að endurræsa þjónustuna
Staða — skipun til að athuga þjónustustöðu
hefur endurræst — tilgreinið hvort þjónustuforritið styður endurræsingu. Ef false og færibreytan er tilgreind endurræsa — gildi þessarar færibreytu er notað. Ef false og breytu endurræsa ekki tilgreint - þjónustan er stöðvuð og byrjað að endurræsa (en systemd notar skipunina systemctl restart).
hasstatus — tilgreinið hvort þjónustutextinn styður skipunina status. Ef false, þá er færibreytugildið notað Staða. Sjálfgefið true.

exec

Keyrir ytri skipanir. Ef þú tilgreinir ekki breytur skapar, bara ef, nema eða hressandi, skipunin verður keyrð í hvert sinn sem Puppet er keyrt. Fær að vinna úr tilkynningum - keyrir skipun.

Breytur:

heiti auðlindar — skipun sem á að framkvæma (valfrjálst)
stjórn — skipunin sem á að framkvæma (ef hún er ekki tilgreind í nafninu)
leið — slóðir til að leita að keyrsluskránni
bara ef — ef skipuninni sem tilgreind er í þessari færibreytu er lokið með núllskilakóða verður aðalskipunin framkvæmd
nema — ef skipuninni sem tilgreind er í þessari færibreytu er lokið með skilakóða sem er ekki núll, verður aðalskipunin framkvæmd
skapar — ef skráin sem tilgreind er í þessari færibreytu er ekki til verður aðalskipunin keyrð
hressandi - ef að true, þá verður skipunin aðeins keyrð þegar þessi stjórnandi fær tilkynningu frá öðrum auðlindum
cwd — möppu sem á að keyra skipunina úr
notandi — notandinn sem á að keyra skipunina frá
veitendur - hvernig á að keyra skipunina:
- jákvætt — barnaferli er einfaldlega búið til, vertu viss um að tilgreina leið
- skel - skipunin er ræst í skelinni /bin/sh, má ekki tilgreina leið, þú getur notað globbing, pípur og aðra skel eiginleika. Finnst venjulega sjálfkrafa ef það eru einhverjir sérstafir (|, ;, &&, || etc).

cron

Stýrir cronjobs.

Breytur:

heiti auðlindar - bara einhvers konar auðkenni
tryggja - krúnuvinnu ástand:
- present - búa til ef er ekki til
- absent - eyða ef það er til
stjórn - hvaða skipun á að keyra
umhverfi - í hvaða umhverfi á að keyra skipunina (listi yfir umhverfisbreytur og gildi þeirra í gegnum =)
notandi — frá hvaða notanda á að keyra skipunina
mínútu, klukkustund, virka daga, mánuði, mánaðardagur — hvenær á að keyra cron. Ef einhver af þessum eiginleikum er ekki tilgreindur verður gildi hans í crontab *.

Í Puppet 6.0 cron eins og fjarlægð úr kassanum í puppetserver, svo það er engin skjöl á almennu síðunni. En hann er í kassanum í puppet-agent, svo það er engin þörf á að setja það upp sérstaklega. Þú getur séð skjölin fyrir það í skjölunum fyrir fimmtu útgáfuna af PuppetEða á GitHub.

Um auðlindir almennt

Kröfur um sérstöðu auðlindar

Algengustu mistökin sem við lendum í eru Tvítekin yfirlýsing. Þessi villa kemur upp þegar tvö eða fleiri tilföng af sömu gerð með sama nafni birtast í möppunni.

Þess vegna mun ég skrifa aftur: upplýsingaskrá fyrir sama hnút ætti ekki að innihalda tilföng af sömu gerð með sama titli!

Stundum er þörf á að setja upp pakka með sama nafni, en með mismunandi pakkastjórum. Í þessu tilviki þarftu að nota færibreytuna nametil að forðast villuna:

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

Aðrar auðlindagerðir hafa svipaða möguleika til að forðast tvíverknað - name у þjónusta, command у exec, og svo framvegis.

Metaparameters

Hver auðlindategund hefur nokkrar sérstakar færibreytur, óháð eðli hennar.

Fullur listi yfir meta breytur í Brúðuskjölunum.

Stutt listi:

krefjast — þessi færibreyta gefur til kynna hvaða auðlindir þessi auðlind er háð.
áður - Þessi færibreyta tilgreinir hvaða auðlindir eru háðar þessari auðlind.
áskrifandi — þessi færibreyta tilgreinir frá hvaða auðlindum þessi auðlind fær tilkynningar.
tilkynna — Þessi færibreyta tilgreinir hvaða auðlindir fá tilkynningar frá þessari auðlind.

Allar lýsifæribreytur sem skráðar eru samþykkja annað hvort einn tilfangstengil eða fylki tengla innan hornklofa.

Tenglar á auðlindir

Auðlindahlekkur er einfaldlega minnst á auðlindina. Þau eru aðallega notuð til að gefa til kynna ósjálfstæði. Tilvísun í tilföng sem ekki er til mun valda söfnunarvillu.

Setningafræði hlekksins er sem hér segir: tegund auðlindar með stórum staf (ef tegundarheitið inniheldur tvöfalda tvípunkta, þá er hver hluti nafnsins á milli tvípunktanna með stórum), síðan auðlindarnafnið í hornklofa (nafnið breytist ekki!). Það ætti ekki að vera bil; hornklofur eru skrifaðir strax á eftir tegundarheitinu.

Dæmi:

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

Ósjálfstæði og tilkynningar

Skjöl hér.

Eins og fyrr segir eru einföld ósjálfstæði milli auðlinda tímabundin. Við the vegur, vertu varkár þegar þú bætir við ósjálfstæði - þú getur búið til hringlaga ósjálfstæði, sem mun valda samsetningarvillu.

Ólíkt ósjálfstæði eru tilkynningar ekki tímabundnar. Eftirfarandi reglur gilda um tilkynningar:

Ef auðlindin fær tilkynningu er hún uppfærð. Uppfærsluaðgerðirnar eru háðar auðlindagerðinni - exec keyrir skipunina, þjónusta endurræsir þjónustuna, pakki setur pakkann upp aftur. Ef tilföngin er ekki með uppfærsluaðgerð skilgreind, þá gerist ekkert.
Meðan á einni keyrslu af Puppet stendur er tilfangið uppfært ekki oftar en einu sinni. Þetta er mögulegt vegna þess að tilkynningar innihalda ósjálfstæði og ósjálfstæðisgrafið inniheldur ekki lotur.
Ef Puppet breytir stöðu auðlindar sendir auðlindin tilkynningar til allra auðlinda sem eru áskrifendur að henni.
Ef auðlind er uppfærð sendir hún tilkynningar til allra auðlinda sem eru áskrifendur að henni.

Meðhöndlar ótilgreindar færibreytur

Að jafnaði, ef einhver tilfangsfæribreyta hefur ekki sjálfgefið gildi og þessi færibreyta er ekki tilgreind í upplýsingaskránni, mun Puppet ekki breyta þessum eiginleika fyrir samsvarandi tilföng á hnútnum. Til dæmis, ef tilföng af gerðinni skrá færibreyta ekki tilgreind owner, þá mun Puppet ekki breyta eiganda samsvarandi skráar.

Kynning á flokkum, breytum og skilgreiningum

Segjum sem svo að við höfum nokkra hnúta sem hafa sama hluta af stillingunni, en það er líka munur - annars gætum við lýst þessu öllu í einum blokk node {}. Auðvitað geturðu einfaldlega afritað eins hluta af uppsetningunni, en almennt séð er þetta slæm lausn - stillingarnar stækka og ef þú breytir almennum hluta stillingarinnar þarftu að breyta því sama á mörgum stöðum. Á sama tíma er auðvelt að gera mistök og almennt var DRY (ekki endurtaka sjálfan þig) meginreglan fundin upp af ástæðu.

Til að leysa þetta vandamál er svo hönnun eins og bekknum.

Námskeið

Class er nafngreindur blokk af popt kóða. Námskeið eru nauðsynleg til að endurnýta kóða.

Fyrst þarf að lýsa bekknum. Lýsingin sjálf bætir ekki við neinum heimildum neins staðar. Bekknum er lýst í upplýsingaskrám:

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

Eftir þetta er hægt að nota bekkinn:

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

Dæmi úr fyrra verkefni - við skulum færa uppsetningu og stillingu nginx í flokk:

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
}

Variables

Klassinn úr fyrra dæminu er alls ekki sveigjanlegur vegna þess að hann kemur alltaf með sömu nginx stillingarnar. Gerum leiðina að stillingarbreytu, þá er hægt að nota þennan flokk til að setja upp nginx með hvaða uppsetningu sem er.

Það er hægt að gera það með því að nota breytur.

Athugið: breytur í Puppet eru óbreytanlegar!

Að auki er aðeins hægt að nálgast breytu eftir að henni hefur verið lýst yfir, annars verður gildi breytunnar undef.

Dæmi um að vinna með breytur:

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

Brúða hefur nafnarými, og breyturnar, í samræmi við það, hafa sýnileikasvæði: Hægt er að skilgreina breytu með sama nafni í mismunandi nafnasvæðum. Þegar gildi breytu er leyst er leitað að breytunni í núverandi nafnrými, síðan í meðfylgjandi nafnrými, og svo framvegis.

Dæmi um nafnrými:

global - breytur utan flokks eða hnútalýsingu fara þangað;
hnútsnafnrými í hnútlýsingunni;
bekkjarnafnarými í bekkjarlýsingu.

Til að forðast tvíræðni þegar þú opnar breytu geturðu tilgreint nafnrýmið í breytuheitinu:

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

Við skulum vera sammála um að leiðin að nginx stillingunni liggur í breytunni $nginx_conf_source. Þá mun bekkurinn líta svona út:

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
}

Hins vegar er uppgefið dæmi slæmt vegna þess að það er einhver „leynileg vitneskja“ um að einhvers staðar inni í bekknum sé notuð breyta með slíku og slíku nafni. Það er miklu réttara að gera þessa þekkingu almenna - flokkar geta haft breytur.

Flokksbreytur eru breytur í flokksnafnarýminu, þær eru tilgreindar í flokkshausnum og hægt er að nota þær eins og venjulegar breytur í bekknum líkama. Færugildi eru tilgreind þegar flokkurinn er notaður í upplýsingaskránni.

Hægt er að stilla færibreytuna á sjálfgefið gildi. Ef færibreyta er ekki með sjálfgefið gildi og gildið er ekki stillt þegar það er notað, mun það valda söfnunarvillu.

Við skulum breyta bekknum úr dæminu hér að ofan og bæta við tveimur færibreytum: sú fyrsta, sem krafist er, er slóðin að uppsetningunni, og sú síðari, valfrjáls, er nafn pakkans með nginx (í Debian, til dæmis, eru pakkar 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',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Í Puppet eru breytur slegnar inn. Borða margar gagnategundir. Gagnategundir eru venjulega notaðar til að sannreyna færibreytugildi sem eru send í flokka og skilgreiningar. Ef færibreytan sem er samþykkt passar ekki við tilgreinda tegund mun uppsetningarvilla eiga sér stað.

Gerðin er skrifuð strax á undan færibreytuheitinu:

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

Classes: innihalda bekkjarnafn vs class{'classname':}

Hver flokkur er auðlind af gerðinni flokkur. Eins og með hverja aðra tegund af tilföngum geta ekki verið tvö tilvik af sama flokki á sama hnút.

Ef þú reynir að bæta flokki við sama hnút tvisvar með því að nota class { 'classname':} (enginn munur, með mismunandi eða eins breytur), það verður söfnunarvilla. En ef þú notar flokk í auðlindastílnum geturðu strax stillt allar færibreytur hans beint í upplýsingaskránni.

Hins vegar, ef þú notar include, þá er hægt að bæta við bekknum eins oft og þú vilt. Staðreyndin er sú include er idempotent fall sem athugar hvort flokki hafi verið bætt við möppuna. Ef flokkurinn er ekki í möppunni bætir hann honum við og ef hann er þegar til gerir hann ekkert. En ef um er að ræða notkun include Þú getur ekki stillt flokksfæribreytur meðan á flokksyfirlýsingu stendur - allar nauðsynlegar færibreytur verða að vera stilltar í ytri gagnagjafa - Hiera eða ENC. Við munum tala um þá í næstu grein.

Skilgreinir

Eins og sagt var í fyrri blokkinni getur sami flokkur ekki verið til staðar á hnút oftar en einu sinni. Hins vegar þarftu í sumum tilfellum að geta notað sama kóðablokk með mismunandi breytum á sama hnút. Með öðrum orðum, það er þörf fyrir eigin auðlindategund.

Til dæmis, til að setja upp PHP einingu, gerum við eftirfarandi í Avito:

Settu upp pakkann með þessari einingu.
Við skulum búa til stillingarskrá fyrir þessa einingu.
Við búum til tákntengil í stillinguna fyrir php-fpm.
Við búum til tákntengil í stillingar fyrir php cli.

Í slíkum tilfellum er hönnun eins og skilgreina (skilgreina, skilgreind tegund, skilgreind auðlindategund). Define er svipað flokki, en það er munur: Í fyrsta lagi er hver Define tegund auðlindar, ekki auðlind; í öðru lagi hefur hver skilgreining óbeina breytu $title, þar sem auðlindarheitið fer þegar það er lýst yfir. Rétt eins og þegar um flokka er að ræða þarf fyrst að lýsa skilgreiningu og síðan er hægt að nota hana.

Einfaldað dæmi með einingu fyrir PHP:

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' }
}

Auðveldasta leiðin til að ná tvíteknum yfirlýsingu villunni er í Define. Þetta gerist ef skilgreining hefur auðlind með föstu nafni og það eru tvö eða fleiri tilvik af þessari skilgreiningu á einhverjum hnút.

Það er auðvelt að verjast þessu: allar auðlindir innan skilgreiningarinnar verða að hafa nafn sem fer eftir $title. Annar valkostur er vanmáttug samlagning auðlinda; í einfaldasta tilfellinu er nóg að færa auðlindirnar sem eru sameiginlegar fyrir öll tilvik skilgreiningarinnar í sérstakan flokk og taka þennan flokk inn í skilgreininguna - fall include vanmáttugur.

Það eru aðrar leiðir til að ná ómagni þegar bætt er við auðlindum, nefnilega að nota aðgerðir defined и ensure_resources, en ég segi þér frá því í næsta þætti.

Ósjálfstæði og tilkynningar fyrir flokka og skilgreiningar

Flokkar og skilgreiningar bæta eftirfarandi reglum við meðhöndlun ósjálfstæðis og tilkynninga:

háð flokki/skilgreina bætir við ósjálfstæði á öllum tilföngum flokks/skilgreina;
flokkur/skilgreinir ósjálfstæði bætir ósjálfstæði við allar flokkar/skilgreinir auðlindir;
class/define tilkynning tilkynnir um allar auðlindir flokksins/define;
class/define áskrift gerist áskrifandi að öllum auðlindum flokksins/define.

Skilyrt yfirlýsingar og veljara

Skjöl hér.

if

Þetta er einfalt hér:

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

nema

nema ef er öfugt: kóðablokkinn verður keyrður ef tjáningin er ósönn.

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

ræða

Hér er heldur ekkert flókið. Þú getur notað regluleg gildi (strengi, tölur osfrv.), regluleg segð og gagnategundir sem gildi.

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

Valsmenn

Valur er málsmíði svipað og case, en í stað þess að keyra kóðablokk skilar það gildi.

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

Einingar

Þegar uppsetningin er lítil er auðvelt að geyma hana í einni upplýsingaskrá. En því fleiri stillingum sem við lýsum, því fleiri flokkar og hnútar eru í upplýsingaskránni, það stækkar og það verður óþægilegt að vinna með.

Að auki er vandamálið við endurnotkun kóða - þegar allur kóðinn er í einni upplýsingaskrá er erfitt að deila þessum kóða með öðrum. Til að leysa þessi tvö vandamál hefur Puppet aðila sem kallast einingar.

Einingar - þetta eru sett af flokkum, skilgreiningum og öðrum puppet-einingum sem eru settar í sérstaka skrá. Með öðrum orðum, eining er sjálfstætt stykki af puppet rökfræði. Til dæmis gæti verið eining til að vinna með nginx, og hún mun innihalda það og aðeins það sem þarf til að vinna með nginx, eða það gæti verið eining til að vinna með PHP, og svo framvegis.

Einingar eru útfærðar og háðir eininga hver öðrum eru einnig studdar. Það er opin geymsla eininga - Puppet Forge.

Á brúðuþjóninum eru einingar staðsettar í einingarundirskrá rótarskrárinnar. Inni í hverri einingu er staðlað möppukerfi - upplýsingaskrár, skrár, sniðmát, lib, og svo framvegis.

Skráarskipulag í einingu

Rót einingarinnar getur innihaldið eftirfarandi möppur með lýsandi nöfnum:

manifests - það inniheldur stefnuskrár
files - það inniheldur skrár
templates - það inniheldur sniðmát
lib - það inniheldur Ruby kóða

Þetta er ekki tæmandi listi yfir möppur og skrár, en það er nóg fyrir þessa grein í bili.

Nöfn auðlinda og nöfn skráa í einingunni

Skjöl hér.

Tilföng (flokkar, skilgreiningar) í einingu er ekki hægt að nefna hvað sem þú vilt. Að auki er bein samsvörun milli nafns auðlindar og nafns á skránni þar sem Puppet mun leita að lýsingu á auðlindinni. Ef þú brýtur í bága við nafngiftarreglurnar, þá finnur Puppet einfaldlega ekki auðlindalýsinguna og þú munt fá samsetningarvillu.

Reglurnar eru einfaldar:

Öll tilföng í einingu verða að vera í nafnrými einingarinnar. Ef einingin er kölluð foo, þá ætti að nefna allar heimildir í henni foo::<anything>, eða bara foo.
Tilfangið með heiti einingarinnar verður að vera í skránni init.pp.
Fyrir önnur úrræði er nafnakerfi skráa sem hér segir:
- forskeytinu með heiti einingarinnar er hent
- öllum tvípunktum, ef einhver er, er skipt út fyrir skástrik
- viðbót er bætt við .pp

Ég mun sýna það með dæmi. Segjum að ég sé að skrifa einingu nginx. Það inniheldur eftirfarandi úrræði:

bekknum nginx lýst í upplýsingaskránni init.pp;
bekknum nginx::service lýst í upplýsingaskránni service.pp;
skilgreina nginx::server lýst í upplýsingaskránni server.pp;
skilgreina nginx::server::location lýst í upplýsingaskránni server/location.pp.

Sniðmát

Þú veist örugglega sjálfur hvað sniðmát eru; ég mun ekki lýsa þeim í smáatriðum hér. En ég læt það bara eftir hlekkur á Wikipedia.

Hvernig á að nota sniðmát: Hægt er að útvíkka merkingu sniðmáts með aðgerð template, sem fer framhjá slóðinni að sniðmátinu. Fyrir auðlindir af gerðinni skrá notað ásamt færibreytunni content. Til dæmis, svona:

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

Skoða slóð <modulename>/<filename> felur í sér skrá <rootdir>/modules/<modulename>/templates/<filename>.

Að auki er það fall inline_template — það fær sniðmátstextann sem inntak, ekki skráarnafnið.

Innan sniðmáta geturðu notað allar Puppet breytur í núverandi umfangi.

Puppet styður sniðmát á ERB og EPP sniði:

Stuttlega um ERB

Stjórnarmannvirki:

<%= ВЫРАЖЕНИЕ %> — settu inn gildi tjáningarinnar
<% ВЫРАЖЕНИЕ %> — reiknaðu út gildi tjáningar (án þess að setja það inn). Skilyrt yfirlýsingar (ef) og lykkjur (hver) fara venjulega hér.
<%# КОММЕНТАРИЙ %>

Tjáningar í ERB eru skrifaðar í Ruby (ERB er í raun Embedded Ruby).

Til að fá aðgang að breytum úr upplýsingaskránni þarftu að bæta við @ til breytuheitisins. Til að fjarlægja línuskil sem birtist á eftir stjórnbyggingu þarftu að nota lokamerki -%>.

Dæmi um notkun sniðmátsins

Segjum að ég sé að skrifa einingu til að stjórna ZooKeeper. Bekkurinn sem ber ábyrgð á að búa til stillinguna lítur eitthvað svona út:

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'),
  }
}

Og samsvarandi sniðmát zoo.cfg.erb - Svo:

<% 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 -%>

Staðreyndir og innbyggðar breytur

Oft er sérstakur hluti stillingarinnar háður því sem er að gerast á hnútnum. Til dæmis, eftir því hvaða Debian útgáfa er, þarftu að setja upp eina eða aðra útgáfu af pakkanum. Þú getur fylgst með öllu þessu handvirkt, endurskrifað birtingarmyndir ef hnútar breytast. En þetta er ekki alvarleg nálgun; sjálfvirkni er miklu betri.

Til að fá upplýsingar um hnúta hefur Puppet kerfi sem kallast staðreyndir. Staðreyndir - þetta eru upplýsingar um hnútinn, fáanlegar í upplýsingaskrá í formi venjulegra breyta í hinu alþjóðlega nafnrými. Til dæmis hýsilheiti, útgáfu stýrikerfis, arkitektúr örgjörva, notendalisti, lista yfir netviðmót og heimilisföng þeirra og margt, margt fleira. Staðreyndir eru fáanlegar í upplýsingaskrám og sniðmátum sem venjulegar breytur.

Dæmi um að vinna með staðreyndir:

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

Formlega séð hefur staðreynd nafn (streng) og gildi (ýmsar gerðir eru til: strengir, fylki, orðabækur). Borða sett af innbyggðum staðreyndum. Þú getur líka skrifað þitt eigið. Staðreyndasafnara er lýst eins og aðgerðir í Rubyannað hvort sem keyranlegar skrár. Staðreyndir geta einnig komið fram á forminu textaskrár með gögnum á hnútunum.

Meðan á aðgerðinni stendur afritar brúðuþjónninn fyrst alla tiltæka staðreyndasafnara frá pappetservernum yfir á hnútinn, eftir það ræsir hann þá og sendir safnaðar staðreyndir til þjónsins; Eftir þetta byrjar þjónninn að setja saman vörulistann.

Staðreyndir í formi keyranlegra skráa

Slíkar staðreyndir eru settar í einingar í skránni facts.d. Auðvitað verða skrárnar að vera keyranlegar. Þegar þeir eru keyrðir verða þeir að gefa út upplýsingar í staðlað úttak annað hvort á YAML eða key=value sniði.

Ekki gleyma því að staðreyndirnar eiga við um alla hnúta sem stjórnað er af poppet þjóninum sem einingin þín er sett á. Þess vegna skaltu gæta þess í handritinu að athuga hvort kerfið hafi öll þau forrit og skrár sem nauðsynlegar eru til að staðreyndin þín virki.

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

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

Ruby staðreyndir

Slíkar staðreyndir eru settar í einingar í skránni 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

Texta staðreyndir

Slíkar staðreyndir eru settar á hnúta í skránni /etc/facter/facts.d í gamla Puppet eða /etc/puppetlabs/facts.d í nýju Brúðunni.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

Að komast að staðreyndum

Það eru tvær leiðir til að nálgast staðreyndir:

í gegnum orðabókina $facts: $facts['fqdn'];
nota staðreyndarheitið sem breytuheiti: $fqdn.

Best er að nota orðabók $facts, eða jafnvel betra, gefa til kynna alþjóðlegt nafnrými ($::facts).

Hér er viðeigandi hluti skjala.

Innbyggðar breytur

Fyrir utan staðreyndirnar er það líka nokkrar breytur, fáanlegt í hinu alþjóðlega nafnrými.

traustar staðreyndir — breytur sem eru teknar úr skírteini viðskiptavinarins (þar sem vottorðið er venjulega gefið út á poppet þjóni getur umboðsmaðurinn ekki bara tekið og breytt vottorðinu sínu, þannig að breytunum er „traust“): nafn skírteinisins, nafnið á gestgjafi og lén, viðbætur frá vottorðinu.
server staðreyndir — breytur sem tengjast upplýsingum um netþjóninn — útgáfu, nafn, IP-tala netþjóns, umhverfi.
staðreyndir umboðsmanns — breytum bætt við beint af brúðu-umboðsmanni, en ekki af staðreyndum — heiti skírteinis, útgáfa umboðsmanns, brúðuútgáfu.
meistarabreytur - Pappetmaster breytur (sic!). Það er svipað og í server staðreyndir, auk stillingarbreytugilda eru fáanleg.
þýðandabreytur — þýðandabreytur sem eru mismunandi í hverju umfangi: heiti núverandi einingarinnar og heiti einingarinnar þar sem aðgangur var að núverandi hlut. Þeir geta til dæmis verið notaðir til að athuga hvort einkatímar þínir séu ekki notaðir beint úr öðrum einingum.

Viðbót 1: hvernig á að keyra og kemba allt þetta?

Greinin innihélt mörg dæmi um brúðukóða en sagði okkur alls ekki hvernig ætti að keyra þennan kóða. Jæja, ég er að leiðrétta mig.

Umboðsmaður er nóg til að keyra Puppet, en í flestum tilfellum þarftu líka netþjón.

Umboðsmaður

Að minnsta kosti frá útgáfu XNUMX, puppet-agent pakkar frá opinbera Puppetlabs geymsla innihalda allar ósjálfstæðin (rúbín og samsvarandi gimsteina), þannig að það eru engir uppsetningarerfiðleikar (ég er að tala um Debian-undirstaða dreifingar - við notum ekki RPM-undirstaða dreifingar).

Í einfaldasta tilvikinu, til að nota brúðustillinguna, er nóg að ræsa umboðsmanninn í netþjónslausum ham: að því tilskildu að brúðukóðinn sé afritaður í hnútinn, ræstu 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

Það er auðvitað betra að setja upp netþjóninn og keyra umboðsmenn á hnútunum í púkaham - þá munu þeir einu sinni á hálftíma fresti beita stillingunum sem hlaðið er niður af netþjóninum.

Þú getur líkt eftir þrýstilíkaninu af vinnu - farðu á hnútinn sem þú hefur áhuga á og byrjaðu sudo puppet agent -t. Lykill -t (--test) inniheldur í raun nokkra valkosti sem hægt er að virkja hver fyrir sig. Þessir valkostir fela í sér eftirfarandi:

ekki keyra í púkaham (sjálfgefið byrjar umboðsmaðurinn í púkaham);
leggja niður eftir að vörulistinn hefur verið notaður (sjálfgefið mun umboðsmaðurinn halda áfram að vinna og nota uppsetninguna einu sinni á hálftíma fresti);
skrifa ítarlega vinnudagbók;
sýna breytingar á skrám.

Umboðsmaðurinn hefur rekstrarham án breytinga - þú getur notað hann þegar þú ert ekki viss um að þú hafir skrifað rétta uppsetningu og vilt athuga hvað nákvæmlega umboðsmaðurinn mun breyta meðan á aðgerð stendur. Þessi stilling er virkjuð með færibreytunni --noop á skipanalínunni: sudo puppet agent -t --noop.

Að auki geturðu virkjað kembiforrit verksins - í henni skrifar puppet um allar aðgerðir sem hún framkvæmir: um auðlindina sem hún er að vinna úr, um færibreytur þessarar auðlindar, um hvaða forrit hún ræsir. Auðvitað er þetta breytu --debug.

Server

Ég mun ekki íhuga alla uppsetningu pappetserversins og innleiðingu kóða á hann í þessari grein; Ég mun aðeins segja að úr kassanum er fullvirk útgáfa af þjóninum sem þarfnast ekki viðbótarstillingar til að vinna með fáum hnútar (segjum allt að hundrað). Stærri fjöldi hnúta mun krefjast stillingar - sjálfgefið, puppetserver ræsir ekki fleiri en fjóra starfsmenn, til að fá meiri afköst þarftu að fjölga þeim og ekki gleyma að auka minnismörkin, annars mun þjónninn safna sorpi að mestu leyti.

Kóðadreifing - ef þú þarft það fljótt og auðveldlega, skoðaðu þá (á r10k)[https://github.com/puppetlabs/r10k], fyrir litlar uppsetningar ætti það að vera alveg nóg.

Viðauki 2: Kóðunarleiðbeiningar

Settu alla rökfræði í flokka og skilgreiningar.
Haltu flokkum og skilgreiningum í einingum, ekki í upplýsingaskrám sem lýsa hnútum.
Notaðu staðreyndir.
Ekki búa til ef byggt á hýsilheitum.
Ekki hika við að bæta við breytum fyrir flokka og skilgreiningar - þetta er betra en óbein rökfræði falin í meginmáli flokks/skilgreiningar.

Ég mun útskýra hvers vegna ég mæli með að gera þetta í næstu grein.

Ályktun

Ljúkum við innganginn. Í næstu grein mun ég segja þér frá Hiera, ENC og PuppetDB.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Reyndar er miklu meira efni til - ég get skrifað greinar um eftirfarandi efni, kosið um það sem þú hefðir áhuga á að lesa um:

59,1%Háþróuð brúðusmíði - eitthvað næsta stigs skítkast: lykkjur, kortlagning og önnur lambda-tjáning, auðlindasafnarar, útfluttar auðlindir og samskipti milli gestgjafa í gegnum Puppet, merki, veitendur, óhlutbundnar gagnategundir.13
31,8%„Ég er stjórnandi móður minnar“ eða hvernig við í Avito eignuðumst vini við nokkra poppet netþjóna af mismunandi útgáfum og, í grundvallaratriðum, hlutinn um að stjórna poppet þjóninum.7
81,8%Hvernig við skrifum brúðukóða: tækjabúnaður, skjöl, prófun, CI/CD.18

22 notendur kusu. 9 notendur sátu hjá.

Heimild: www.habr.com

Kynning á puppet

Grunnupplýsingar

Kynning á stefnuskrám

Setningafræði og kóðastíll

Staðsetning skráa á pappetserver

Nokkur dæmi um bardaga

Lýsing á hnút og auðlind á honum

Tengsl milli auðlinda á hnút

Auðlindategundir

skrá

pakki

þjónusta

exec

cron

Um auðlindir almennt

Kröfur um sérstöðu auðlindar

Metaparameters

Tenglar á auðlindir

Ósjálfstæði og tilkynningar

Meðhöndlar ótilgreindar færibreytur

Kynning á flokkum, breytum og skilgreiningum

Námskeið

Variables

Classes: innihalda bekkjarnafn vs class{'classname':}

Skilgreinir

Ósjálfstæði og tilkynningar fyrir flokka og skilgreiningar

Skilyrt yfirlýsingar og veljara

if

nema

ræða

Valsmenn

Einingar

Skráarskipulag í einingu

Nöfn auðlinda og nöfn skráa í einingunni

Sniðmát

Stuttlega um ERB

Dæmi um notkun sniðmátsins

Staðreyndir og innbyggðar breytur

Staðreyndir í formi keyranlegra skráa

Ruby staðreyndir

Texta staðreyndir

Að komast að staðreyndum

Innbyggðar breytur

Viðbót 1: hvernig á að keyra og kemba allt þetta?

Umboðsmaður

Server

Viðauki 2: Kóðunarleiðbeiningar

Ályktun

Reyndar er miklu meira efni til - ég get skrifað greinar um eftirfarandi efni, kosið um það sem þú hefðir áhuga á að lesa um: