Pirms neilga laika žurnāla lappusēs mēs apskatījām sistēmu tālvadības pults UNIX iekārtu konfigurācija Cfengine, kas ievērojami vienkāršo sistēmas administratora dzīvi, automatizējot daudzu tīkla mezglu konfigurēšanas darbības. Bet neatkarīgi no tā, cik ērts ir Cfengine, tai ir daudz trūkumu, kuru sistēmai ar nosaukumu Puppet nav.

Iedomājieties sevi sistēmas administratora lomā, kas ir atbildīgs par simtiem iekārtu, kurās darbojas UNIX tipa operētājsistēmas, funkcionalitātes uzturēšanu. Katram no tiem ir nepieciešama konfigurācija, periodiska atjaunināšana un uzraudzība, un tiek pieņemts, ka daudzi no tiem veic līdzīgas funkcijas.

Divas trešdaļas ir darbstacijas, vēl dažas ir maršrutētāji, bet pārējās ir vairāki tīmekļa serveri un datu krātuve. Jautājums: kā vadīt visu šo biznesu? Vienkāršākā atbilde ir vienkārši izveidot savienojumu ar katru no tiem, izmantojot SSH, un veikt nepieciešamās izmaiņas. Tomēr šai metodei ir divas problēmas. Pirmkārt, tas ir ļoti darbietilpīgs. Otrkārt, administratoram pastāvīgi būs jāveic daudzas monotonas darbības (piemēram, lai atjauninātu OpenOffice.org visās darbstacijās, vienas un tās pašas komandas būs jāizpilda vairākus desmitus reižu). Varat mēģināt izvairīties no šīs problēmas, rakstot vairākus skriptus, kas paši izveidos savienojumu ar katru mašīnu un izpildīs iepriekš uzrakstītas komandas. Bet arī šeit jūs gaida problēmas.

Skripti būs pastāvīgi jāmaina, lai pielāgotu tos katram uzdevumam; Skriptos būs jāņem vērā atšķirības operētājsistēmās un versijās, un tie būs ilgu laiku jāatkļūdo, pirms tie tiks lietoti darbināmās iekārtās. Vispār ne comme il faut. Pareizā atbilde ir izmantot tā sauktās attālās konfigurācijas pārvaldības sistēmas, kuru slavenākie pārstāvji ir atvērtās sistēmas Cfengine un Lelle. Šādas sistēmas uzņemas visus pienākumus, lai nodrošinātu iekārtas konfigurāciju pareizais tips, pieprasot administratoram tikai speciālā valodā aprakstīt sistēmas galīgo stāvokli (piemēram, apraksts par to, kādas pakotnes jāinstalē OS, kādas rindas jāpievieno konfigurācijas failiem, kādas komandas jāizpilda utt.). ). Pēc tam visi mezgli paši saņems informāciju par nepieciešamo stāvokli no servera un veiks sistēmas automātisko konfigurāciju. Pateicoties šim mehānismam, jaunas mašīnas var pilnībā konfigurēt bez cilvēka iejaukšanās, un esošās var pārkonfigurēt, pievienojot tikai dažas rindiņas stāvokļa aprakstam.

Lelle?

Mēs jau esam veltījuši visu rakstu Cfengine sistēmai, tāpēc šodien mēs pievērsīsimies Leļļu sistēmai, kuru var droši saukt par tās ideoloģisko pēcteci. Puppet izstrādāja Lūks Kanijs, kuram apnika Cfengine ierobežojumi un viņš nolēma izveidot labāku versiju no nulles. Ja jau esat izmantojis Cfenfine, jūs, iespējams, atradīsit Puppet par ērtāku un jaudīgāku sistēmu. Leļļu valsts valoda ir augstāka līmeņa un elastīgāka, kas nozīmē, ka administratoram nav jāuztraucas par tādām lietām kā atsevišķu noteikumu rakstīšana katram OS tipam vai detalizēts apraksts veicot triviālas darbības. Lelle ļauj savam saimniekam koncentrēties uz to, ko viņš vēlas darīt, nevis uz to, kā to darīt (piemēram, lai instalētu noteiktu pakotni jebkurā no sistēmas atbalstītajām operētājsistēmām, jums tikai burtiski jāuzraksta dažas rindiņas ar tekstu "Instalējiet šo programmu " tā vietā, lai aprakstītu komandas, kas nepieciešamas tā instalēšanai). Puppet ir uzrakstīts vienkāršā Ruby valodā, kas ļauj to viegli pielāgot konkrētam uzdevumam un paplašināt funkcionalitāti (tiek nodrošināta elastīga spraudņu sistēma).

Turklāt atšķirībā no Cfengine izstrādes modeļa, kas būtībā griežas ap vienu cilvēku, Puppet ir liela entuziastu kopiena, kas veic koda uzlabojumus, kopīgo konfigurācijas piemērus un raksta dokumentāciju.

Kopumā šķiet, ka Puppet ir modernāka un izsmalcinātāka sistēma labs dizains. Tāpat kā Cfengine, tas atbalsta gandrīz visas mūsdienu UNIX līdzīgās operētājsistēmas (ieskaitot MacOS X), kā arī var darboties Cygwin vidē virs Windows. Tā atkarību sarakstā ir tikai Ruby tulks un rīks Factor, tāpēc ar instalēšanu nevajadzētu rasties problēmām (taisnības labad jāsaka, ka Cfengine atkarību saraksts ir vēl īsāks).

Uzstādīšana

Tāpat kā Cfengne, Puppet ir klienta-servera sistēma, kas sastāv no vadības servera un vergu mezgliem. Serveris saglabā mezglu galīgo stāvokļu aprakstu (ko leļļu valodā sauc par manifestu) un gaida, līdz tie izveidos savienojumu. Ik pēc pusstundas (pēc noklusējuma) klients izveido savienojumu ar serveri, saņem no tā gala stāvokļa aprakstu, salīdzina to ar pašreizējo un, ja tas un/vai aprakstītais stāvoklis ir mainījies, pārkonfigurē sistēmu un pēc tam iet gulēt. Komunikācija tiek veikta caur šifrētu kanālu, tāpēc uzbrukumi, kuru pamatā ir stāvokļa apraksta aizstāšana, tiek izslēgti (bet, ja uzbrucējs pārņems serveri, tad visi mezgli būs viņa kontrolē).

Puppet ir iekļauts visu populāro izplatījumu krātuvēs, tāpēc tā instalēšana nedrīkst būt sarežģīta. Piemēram, Debian/Ubuntu Puppet klientu var instalēt šādi:

$ sudo apt-get install lelle

Un serveris ir šāds:

$ sudo apt-get instalēt puppet puppetmaster

Klienta un servera konfigurācijas faili tiek glabāti direktorijā /etc/puppet. Vissvarīgākais no tiem ir fails /etc/puppet/manifests/site.pp, kas satur manifestu.

Tas saglabā stāvokļu aprakstu, un tam vajadzētu pastāvēt tikai serverī. Lai atvieglotu atkļūdošanu, pievienosim tai vienkāršu konfigurāciju:

klases passwd(
fails ("/etc/passwd":
īpašnieks => sakne,
grupa => sakne,
režīms => 644,
}
}
node default (
iekļaut passwd
}

Šajās rindās ir aprakstīts stāvoklis, kurā faila /etc/passwd īpašniekam ir jābūt root, un tā atļaujas ir iestatītas uz 644. Nākamajā sadaļā mēs sīkāk aplūkosim manifesta faila formātu. Otrs svarīgākais fails ir /etc/puppet/puppet.conf. Tas iestata servera un klientu konfigurāciju, tāpēc tai ir jābūt visās Leļļu tīklā organizētajās iekārtās. Ubuntu šis fails satur minimālos nepieciešamos un vairumā gadījumu pietiekamus iestatījumus. Zemāk tie ir sniegti ar komentāriem:

# vi /etc/puppet/puppet.conf
# Standarta direktoriju ceļi
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Faktoru rīka atrašanās vieta,
# izmanto, lai iegūtu informāciju par OS
factpath=$vardir/lib/facter
# Sinhronizējiet spraudņus
# (instalēti spraudņi serverī - tie tiek kopēti klientiem)
pluginsync=true
# Katalogs ar veidnēm (par tām lasiet tālāk)
templatedir=$confdir/templates
# Sinhronizācija ar etckeeper
# (kas zin, tas sapratīs, citiem nevajag)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Konfigurācijas fails var ietvert liels skaits dažādas opcijas, par kurām informāciju var iegūt, ģenerējot noklusējuma konfigurāciju:

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

Noklusējuma klienta konfigurācija tiek ģenerēta, izmantojot citu komandu:

$ sudo puppet -genconfig > /etc/puppet/puppetd.conf.default

Konfigurācijai tiek izmantoti faili Fileserver.conf un auth.conf failu serveris(par to lasiet sadaļā “Failu serveris”) un autentifikāciju. Pagaidām nav jēgas tiem pieskarties. Kad konfigurācija ir pabeigta, Puppet serveris ir jārestartē:

$ sudo /etc/init.d/puppetmaster restart

Pēc tam viņš būs gatavs pieņemt klientu pieprasījumus. Tomēr bez parakstīta sertifikāta neviens klients nevarēs saņemt manifestu no servera un konfigurēt iekārtu.

Tāpēc mums ir jāpalaiž Puppet klienti testa režīmā, lai viņi varētu iesniegt savus sertifikātus serverī parakstīšanai (starp citu, to var izdarīt visās mašīnās vienlaikus, izmantojot shmux rīku):

$ sudo puppetd -server puppet-server.com -verbose -test

Mēs atgriežamies serverī un saņemam parakstīšanai gatavu sertifikātu sarakstu:

$ sudo puppetca --list

Sarakstā atlasiet resursdatoru un parakstiet tā sertifikātu:

$ sudo puppetca --sign nomad.grinder.com

Vai arī mēs parakstām visu uzreiz:

$ sudo puppetca --sign --all

Tagad jūs varat palaist klientus kaujas režīmā. Bet vispirms konfigurācijas failā jāievada Puppet servera nosaukums (pēc noklusējuma tā nosaukums ir vienkārši marionete):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
# izeja

Klientu palaišana:

$ sudo /etc/init.d/puppet start

Valsts apraksta valoda

Kā minēts iepriekš, Puppet izmanto savu valodu, lai aprakstītu galīgo stāvokli operētājsistēma, ar kuras palīdzību sistēmas administrators norāda, kādā formā jānoved OS komponenti, lai tā sasniegtu vēlamo stāvokli. Šī ir diezgan sarežģīta valoda, kas tomēr ir daudz vienkāršāka nekā jebkura programmēšanas valoda. Ja esat vismaz virspusēji pazīstams ar bash skriptu valodu, jūs viegli sapratīsit Leļļu valodu. Valodas galvenais elements ir resursi, kas tiek izmantoti, lai aprakstītu, kādā formā ir jāpārvērš kāds no OS komponentiem. Piemēram, šāds vienkāršais resurss apraksta vēlamo /etc/passwd faila stāvokli:

# vi /etc/puppet/manifests/site.pp
fails ("/etc/passwd":
īpašnieks => "sakne"
}

Šeit fails ir resursa veids. Kopumā to ir vairāki desmiti, sākot no resursiem, kas pārvalda failus, kā šajā piemērā, līdz pakotnēm un pakalpojumiem. Rinda /etc/passwd ir resursa nosaukums.

Faila tipa gadījumā nosaukums ir tāds pats kā faila ceļš, bet dažos citos veidos nosaukums var būt patvaļīgs. Rindas īpašnieks => "root" apraksta īpašnieka atribūta iestatīšanu uz root, tas ir, tas saka, ka īpašnieks norādītais fails tur jābūt administratoram.

Katram resursa veidam ir savs modificēšanai pieejams atribūtu kopums, kā arī ir īpaši meta atribūti, ko var izmantot jebkurā resursā. Viena no svarīgākajām resursu īpašībām ir spēja saistīt ar tiem. To var izmantot, lai izveidotu atkarības ķēdes. Ar šādu ierakstu tiek izveidots /etc/group resurss, kas ir atkarīgs no /etc/passwd resursa (atkarības tiek norādītas, izmantojot prasīt meta atribūtu):

# vi /etc/puppet/manifests/site.pp
fails ("/etc/group":
prasīt => Fails["/etc/passwd"],
īpašnieks => "sakne",
}

Tas nozīmē, ka /etc/group resursu var konfigurēt (atnest aprakstītajā formā) tikai tad, kad ir konfigurēts /etc/passwd resurss. Resursus var grupēt resursu kolekcijās, ko sauc par klasēm. Tas nepieciešams, lai vienā abstraktā resursā apvienotu resursus, kas pēc nozīmes un uzdevuma veida ir līdzīgi. Piemēram, ērtības labad mēs varētu apvienot nginx tīmekļa servera instalēšanu un palaišanu vienā abstraktā resursā ar tādu pašu nosaukumu:

# vi /etc/puppet/manifests/site.pp
klase nginx (
pakotne ("nginx":
nodrošināt => uzstādīts
}
pakalpojums ("nginx":
nodrošināt => skriešanu,
prasīt => pakotne ["nginx"],
}
}

Šeit pakotnes resursa veids tiek izmantots, lai instalētu nginx pakotni sistēmā, un pakalpojums tiek izmantots, lai palaistu tāda paša nosaukuma pakalpojumu. Ar prasību mēs piespiežam sistēmu sākt pakalpojumu tikai tad, ja pakotne ir veiksmīgi instalēta. Nodarbību ērtības ir tādas, ka tās var iekļaut arī atkarībā no:

# vi /etc/puppet/manifests/site.pp
pakalpojums ("kalmārs":
nodrošināt => skriešanu,
prasīt => klase ["nginx"],
}

Tāpat kā īstās OOP valodās, klases var mantot viena no otras un ignorēt atribūtus:

# vi /etc/puppet/manifests/site.pp
klases passwd(
fails ("/etc/passwd":
īpašnieks => "sakne",
grupa => "sakne",
}
}
klase passwd-bsd manto passwd (
Fails ["/etc/passwd"] ( grupa => "ritenis")
}

Šeit passwd-bsd klase manto no passwd, lai ignorētu /etc/passwd resursa grupas atribūtu (BSD sistēmās /etc/passwd pieder riteņu grupai, tāpēc mēs izveidojām atsevišķu klasi šādām sistēmām). Vēlāk mēs apskatīsim pareizāku un acīmredzamāku veidu, kā izvēlēties alternatīvas atribūtu vērtības, izmantojot nosacījumus.

Mainīgie ir viena no jebkuras programmēšanas valodas neatņemamām sastāvdaļām, un arī Puppet tādi ir. Mainīgie sākas ar $ zīmi un var saturēt jebkuru skaitli, virkni vai Būla vērtība(patiess, nepatiess):

$want_apache = taisnība
$apache_version = "2.2.14"

Viena no jaudīgākajām Puppet funkcijām, kas saistītas ar mainīgajiem, ir tās integrācija ar Faktoru mašīnas informācijas rīku. Šī utilīta atgriež visu mašīnai raksturīgo informāciju atslēgu un vērtību pāru veidā, kas programmā Puppet tiek pārvērsti par tāda paša nosaukuma mainīgajiem. Kopā ar nosacījuma instrukcijām leļļu valodā tos var izmantot, lai mainītu resursu atribūtus atkarībā no iekārtas īpašībām.

Piemēram, iepriekš aprakstīto passwd klasi var viegli pārrakstīt, lai automātiski atlasītu atribūtu atkarībā no OS veida (bez pašas klases):

# vi /etc/puppet/manifests/site.pp
fails ("/etc/passwd":
īpašnieks => "sakne",
grupa => $kernel ? (
Linux => "sakne",
FreeBSD => "ritenis",
},
}

Atkarībā no tā, kurā operētājsistēmā šis manifesta fragments tiks analizēts, grupas atribūta vērtība būs sakne vai ritenis. Izņemot nosacīts operators, Leļļu valoda atbalsta arī gadījuma atlases operatoru, ko var izmantot, lai izveidotu konkrētu resursu atkarībā no mainīgā vērtības:

# vi /etc/puppet/manifests/site.pp
gadījums $operētājsistēma (
redhat: (service ("httpd": nodrošināt => darbojas))
debian: (service ("apache": nodrošina => darbojas))
noklusējuma: ( pakalpojums ( "apache2": nodrošina =>
skrien))
}

Šis kods nosaka dažādas iespējas pakalpojuma veida resurss atkarībā no operētājsistēmas (pakalpojumu nosaukumi dažādos Linux izplatījumos var atšķirties, tāpēc, kurš pakalpojums Puppet jādarbina, ir jānorāda katram atsevišķi).

Noklusējuma opcija tiek izmantota, ja mainīgā vērtība neatbilst nevienai no iepriekšējām opcijām. Papildus iepriekš apspriestajiem failu, pakotņu un pakalpojumu resursu veidiem, Puppet atbalsta lielu skaitu citu resursu veidu, tostarp trešo pušu izstrādātāju izveidotos. To detalizēts apraksts, ieskaitot piemērus, atbalstītos atribūtus un līdzekļus, ir atrodams oficiālajā dokumentācijā - http://docs.puppetlabs.com/references/stable/type.html. Zemāk ir saraksts un īss apraksts visbiežāk lietotie ir:

Populāri leļļu resursu veidi

• cron - pārvaldīt cron darbus
• exec - palaidiet skriptus un komandas
• fails - failu pārvaldība
• failu kopa - dublējums failus
• grupa - grupas vadība
• resursdators — pārvalda ierakstus failā /etc/hosts
• interfeiss - tīkla saskarņu konfigurācija
• mount - montāžas failu sistēmas
• paziņot - nosūtiet ziņojumu uz Puppet žurnāla failu
• pakete - pakotņu pārvaldība
• serviss - servisa vadība
• sshkey - pārvaldiet SSH atslēgas
• kārtīgs - failu dzēšana atkarībā no apstākļiem
• lietotājs - lietotāju pārvaldība
• zonas - Solaris zonas pārvaldība

Otrs svarīgākais Leļļu valodas elements pēc resursiem ir mezgli. Ar viņu palīdzību administrators var aprakstīt, kurām mašīnām ir jāpiemēro noteikti resursi un klases. Citiem vārdiem sakot, tas ir veids, kā norādīt individuālu konfigurāciju katrai iekārtai, kas piedalās Puppet tīklā. Vienkāršākais mezgla piemērs ir dots raksta sākumā sadaļā “Instalēšana”:

# vi /etc/puppet/manifests/site.pp
node default (
iekļaut passwd
}

Šī ir noklusējuma mezgla definīcija, kas ietver passwd resursu/klasi. Nosaukums noklusējuma nozīmē "visi pārējie mezgli", tāpēc kaut kur iepriekš definētais passwd resurss/klase tiks konfigurēta katrā no tiem. Ērtības labad šeit tiek izmantots iekļauts atslēgvārds. Faktiski visas klases un resursus var aprakstīt tieši mezgla aprakstā, taču tas nav ieteicams. Papildus noklusējuma mezgla nosaukumā varat norādīt iekārtas tīkla nosaukumu (tad visi mezglā aprakstītie resursi tiks konfigurēti tikai šajā mašīnā) vai patvaļīgu nosaukumu (tad šo mezglu var mantot cits mezgls) . Lai saprastu, kā tas viss darbojas kopā ar klasēm un resursiem, apskatīsim gatavā Puppet manifesta piemēru, ko izmanto divu tīkla iekārtu (tīmekļa servera un NTP servera) konfigurēšanai:

# vi /etc/puppet/manifests/site.pp
# SSH servera instalēšana un palaišana
klase sshd (
pakotne (openssh-server: nodrošināt => instalēta)
pakalpojums (sshd:
nosaukums => $operētājsistēma? (
fedora => "sshd",
debian => "ssh",
noklusējuma => "sshd",
},
iespējot => taisnība,
nodrošināt => skriešanu,
}
}
# Instalējiet un palaidiet Apache
klase httpd(
pakotne ( httpd: nodrošināt => instalēta)
pakalpojums (httpd:
iespējot => taisnība,
nodrošināt => skriešanu,
}
}
# NTP servera instalēšana un palaišana
klase ntpd(
pakotne (ntp-serveris: nodrošināt => instalēta)
pakalpojums (
ntp-serveris:
iespējot => taisnība,
nodrošināt => skriešanu,
}
}
# Pamatmezgls, kas tiek izmantots tikai kā visu pārējo vecāks
mezglu bāze (
ietver sshd
}
# Mezgls, kurā atradīsies tīmekļa serveris
mezgls web.server.com manto bāzi (
ietver httpd
}
# NTP servera mezgls
mezgls ntp.server.com manto bāzi (
iekļaut ntpd
}

Šī šķietami vienkāršā konfigurācija nodrošina diezgan daudz: tā iekārtā vietnē web.server.com instalē un palaiž Apache, un iekārtā tiek instalēts un darbojas NTP serveris. ntp.server.com. Turklāt abas mašīnas instalē SSH serveri. Šī konfigurācija, visticamāk, nebūs piemērota pat vienam administratoram; tas būs nopietni jāuzlabo, lai iemācītu pareizi konfigurēt serverus, saņemt svaigas konfigurācijas un citus failus no galvenā Puppet servera.

Tomēr tas skaidri parāda Leļļu spēku. Izmantojot vienkāršu konfigurāciju, mēs likām mašīnām pašām instalēt un palaist nepieciešamo programmatūru un uzturēt to darba kārtībā (ja serveris avarē, Puppet pats pārkonfigurēs, lai sistēmas nonāktu vajadzīgajā stāvoklī).

Failu serveris

Daudzus attālās administrēšanas uzdevumus nevar atrisināt bez kopēšanas uz mašīnām papildu faili. Tās var būt iepriekš sagatavotas konfigurācijas, Apache tīmekļa lapas, pakotnes, kas nav oficiālajā repozitorijā, un daudz kas cits. Lai atvieglotu šo failu pārsūtīšanu uz attāliem saimniekiem, Puppet ietver failu serveri.

Failu servera iestatījumi tiek saglabāti /etc/puppet/fileserver.conf failā. Lai piespiestu Puppet apkalpot konkrēta direktorija saturu klientiem, tajā jāievieto dažas rindiņas:

# vi /etc/puppet/fileserver.conf
ceļš = /var/puppet/files
atļaut *.server.com

Šīs divas rindiņas norāda, ka direktorijam /var/puppet/files jābūt pieejamam visiem server.com domēna saimniekiem. Turklāt mēs varam norādīt pilnu atļautās mašīnas domēna nosaukumu vai tās IP adresi, kā arī nogriezt nevēlamos, izmantojot aizlieguma direktīvu. Pēc tam jebkuru failu šajā direktorijā var pārvietot uz klientu, izmantojot faila resursu. Piemēram:

# vi /etc/puppet/manifests/site.pp
fails ("/etc/httpd/conf/httpd.conf":
avots => "puppet://httpd/httpd.conf",
režīms => 644,
}

Fails httpd.conf, kas atrodas serverī direktorijā /var/puppet/files/httpd, tiks kopēts uz mērķa mašīnu pa ceļu, kas norādīts resursa nosaukumā.

Secinājumi

Šajā rakstā mēs esam apskatījuši ļoti nelielu daļu no Lelles iespējām. Patiesībā tas ir sarežģīta sistēma, ko pilnībā var aprakstīt tikai grāmatas lappusēs. Tajā pašā laikā Puppet ir ļoti viegli konfigurēt un uzturēt, jo īpaši tāpēc, ka internetā var atrast daudz tā konfigurācijas piemēru.

Informācija

• Puppet izmanto HTTP protokolu, tāpēc to var palaist tīmekļa serverī, lai uzlabotu veiktspēju.
• Leļļu var izmantot, lai automātiski konfigurētu un uzturētu vienu lokālo mašīnu.
• Apvienojot Puppet, tīkla OS instalāciju (pxe-install) un pašizveidojošus instalācijas attēlus, varat izveidot pilnībā paškonfigurējošu iekārtu tīklu, ko var izvietot tikai ar vienu komandu.
• Puppet savā darbā izmanto daudzi lieli uzņēmumi, piemēram, Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution un SugarCRM.

Saites

• http://docs.puppetlabs.com — Leļļu dokumentācija
• http://docs.puppetlabs.com/guides/language_tutorial.html - Pilns apraksts Leļļu valoda
• http://docs.puppetlabs.com/references/stable/type.html — resursu veidi

Ja jūsu pārvaldīto serveru skaits ir mazāks par desmit, reti kurš domā par savu centralizēto pārvaldību, tas var nebūt vajadzīgs. Ja ir desmitiem serveru, centralizēta programmatūra un konfigurācijas pārvaldība ir ārkārtīgi noderīga. Ja ir simtiem un tūkstošiem serveru, tas ir ļoti svarīgi. Ir daudz šāda veida programmu, piemēram: šefpavārs, CFEngine, Puppet... Tieši pēdējā tiks apspriesta šajā ierakstā.

Lelle pelnīti tiek uzskatīta par vienu no labākie risinājumi tāpat. To izmanto tādi uzņēmumi kā Google, Citrix un Red Hat. Šī ir klienta-servera lietojumprogramma, kas rakstīta Ruby programmēšanas valodā, kas tiek izplatīta divās versijās:

• Puppet Open Source - pilnībā bezmaksas versija
• Puppet Enterprise — bez maksas līdz 10 serveriem, pēc tam nepieciešamas licences

Apsvērsim Puppet Open Source servera un aģenta instalēšanu, kas ir iekļauti modernāko izplatījumu pakotnēs. Tālāk mēs runāsim par Ubuntu 12.04 Precise Pangolin.

Leļļu aizmugures galu sauc leļļu meistars, sāksim instalēšanu no turienes:

Un tagad klients:

Klienta konfigurācijas failā /etc/puppet/puppet.conf jums jārunā par serveri, pievienojot šādu sadaļu:

Server=puppet.local report=true pluginsync=false

Sākotnējā posmā labāk ir izslēgt spraudņu sinhronizāciju.

Palaidīsim leļļu klientu tā, lai tas izveidotu sertifikāta pieprasījumu:

Serverī ir jāpārbauda, ​​vai sertifikāta pieprasījums ir saņemts, un, ja tā, jāizsniedz sertifikāts:

Atkārtojiet iepriekšējo darbību klientam:

Lieliski, viss darbojas. Pāriesim pie pirmā manifesta izveides. Manifesti jeb konfigurācijas ir aprakstītas īpašā deklaratīvā valodā. Mēs uzreiz pieradīsim pie labām lietām, izmantosim moduļu struktūru un nodarbības. Piemēram, uzrakstīsim moduli, kas atjauninās failu /etc/hosts visos mūsu serveros.

Pārbaudīsim, kur lelle meklē moduļus:

Izveidojiet direktorijus savam modulim

Jāizsauc pirmais manifests, kas pazīstams arī kā galvenā moduļa fails init.pp

Klases saimnieki ( # puppet.local host ( "puppet.local": nodrošināt => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "lelle", ) # linux.local resursdators ("linux.local": nodrošināt => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ))

Pēc noklusējuma marionete meklē failu /etc/puppet/manifests/site.pp lai ielādētu konfigurāciju, izveidosim to šādā formā:

Mezgls pēc noklusējuma (ietver saimniekdatorus)

Mēs pārbaudām manifestu serverī:

Par klientu:

Kad esam pārliecinājušies, ka viss darbojas, ļaujam pakalpojumam startēt /etc/default/puppet mainīt:

# Vai sākt marioneti sāknēšanas laikā? START=jā

Pakalpojuma sākšana

Puppet ik pēc 30 minūtēm aptaujās puppetmaster serveri par konfigurācijas izmaiņām un, ja nepieciešams, attiecīgi pielāgos sistēmu.

Pirms kāda laika manās grāmatzīmēs esošo serveru saraksts pārsniedza 200. Pieaugot serveru skaitam, jebkuras jaunas konfigurācijas izvietošana vai jaunu pakotņu instalēšana patērē milzīgu laiku. Tāpēc es nolēmu izmantot lelli.
Lelle(angļu marionete) ir starpplatformu klienta-servera lietojumprogramma, kas ļauj centralizēti pārvaldīt vairākos datoros instalēto operētājsistēmu un programmu konfigurāciju. Lelle ir uzrakstīta Ruby programmēšanas valodā.

Viņi arī saka, ka lelle ir attālināta konfigurācijas pārvaldības sistēma, kuras slavenākie pārstāvji ir atvērtās sistēmas Cfengine un Puppet.

Izlasot atsauksmes, es nolēmu izmantot leļļu.

Leļļu servera uzstādīšana un konfigurēšana:
Leļļu servera uzstādīšana:
Instalējiet leļļu serveri vietnē OpenSuSE 11.4:

rāvējslēdzējs leļļu serverī

Mainīsim servera nosaukumu uz marioneti:
/etc/HOSTNAME:

DNS ierakstam ir jāatrisina 127.0.0.2
kaķis /etc/hosts:

127.0.0.2 lelle.vietne marionete

Dosim lietotājam tiesības marionete:

Sāksim pakalpojumu Leļļu meistars:

rcpuppetmasterd start

Pievienosim leļļu dēmona palaišanu startēšanai:

chkconfig - leļļu meistars

Leļļu servera iestatīšana:
Definēsim direktoriju, kurā tiks glabāti faili, kurus leļļu serveris pārsūtīs uz klienta mašīnām faila tipa manifestos.

vim /etc/puppet/fileserver

ceļš /etc/puppet/files
atļaut *

mkdir /etc/puppet/files

chown -R marionet:lelle /etc/puppet/files

Mēs izveidosim jebkura satura failu izvietošanai un testēšanai klientiem

pieskarieties /etc/puppet/files/puppettetesting

Restartējam leļļu serveri:

rcpuppetmasterd restartēt

Lelle izmanto savu valodu operētājsistēmas galīgā stāvokļa aprakstīšanai, ar kuras palīdzību sistēmas administrators norāda, kādā formā OS komponenti ir jāpārnes, lai tā sasniegtu vēlamo stāvokli. Stāvoklis var nozīmēt konkrēta faila, mapes, darbojošos pakalpojumu, instalēto pakotņu, atjauninājumu un daudz ko citu. Visi stāvokļa iestatījumi ir aprakstīti failos vai manifestos, kas atrodas direktorijā: /etc/puppet/manifests. Šiem failiem ir tādi nosaukumi kā *.pp.

Izveidosim vienkāršāko manifests:
/etc/puppet/manifests/1.file.pp:

file ("/tmp/puppettetesting":
avots => "puppet:///files/puppettesting",
}

Lai izmantotu šo manifestu:
marionet app 1.file.pp

Leļļu klienta instalēšana un konfigurēšana:

rāvējslēdzējs lellē

Piešķirsim leļļu tiesības lietotājam:

chown -R puppet.puppet /var/lib/puppet/

Lai izveidotu savienojumu ar leļļu serveri, leļļu klients nosūta pieprasījumu apstiprināt sertifikātu pēc šī pieprasījuma apstiprināšanas serverī, leļļu klients sāks izmantot tam paredzētos manifestus. Mēs nosūtīsim pieprasījumu apstiprināt sertifikātu:

Serverī mēs varam redzēt, kādi apstiprinājuma pieprasījumi tiek gaidīti:

"puppet-client.localdomain" (B5:12 :69 :63 :DE:19 :E9:75 :32 :2B:AA:74 :06:F6:8E:8A)

Mēs apstiprinām:

puppetca — zīme "leļļu klients.localdomain"

Ir pienācis laiks apskatīt vienkāršākos manifestu izveides piemērus:
izveidojiet failu /etc/puppet/manifests/site.pp:

node default (
file ("/tmp/puppettetesting":
avots => "puppet:///files/leļļu testēšana",
}
pakalpojums ("ntp":
nodrošināt => skriešanu,
iespējot => patiess,
}
pakete ("htop":
nodrošināt => uzstādīts,
}
}

noklusējuma - attiecas uz visiem klientiem
fails - šajā sadaļā ir norādīts izveidot vai pārrakstīt /tmp/puppettetesting failu, kas atrodas serverī direktorijā /etc/puppet/files
pakalpojums: pārbaudiet, vai pakalpojums darbojas, ja nedarbojas, tad palaidiet to un arī pievienojiet to startēšanai
pakotne: pārbaudiet, vai klientam ir instalēta htop pakotne, un, ja nē, instalējiet to.

Lai pārbaudītu, palaidiet klientam:

Kā redzat, klientā startēšanai tika pievienots ntp, tika palaists ntp dēmons, instalēta htop pakotne un leļļu testēšanas fails tika kopēts direktorijā /tmp/.

info: Caching katalogs marionet-client.localdomain
info: tiek lietota konfigurācijas versija "1370163660"
paziņojums: / Stage[ galvenais] // Mezgls [ noklusējums] / Pakalpojums[ ntp] / nodrošināt: nodrošināt, ka "apturēts" ir mainīts uz "darbojas"
paziņojums: / Stage[ galvenais] // Mezgls[ noklusējuma] / Package[ htop ] / nodrošināt: izveidots
paziņojums: / Stage[ galvenais] // Mezgls[ noklusējuma] / Fails[ / tmp/ leļļu testēšana] / nodrošināt: definēts saturs kā "(md5)f2171ac69ba86781bea2b7c95d1c8e67"
paziņojums: Pabeigts katalogs tiek palaists 3,95 sekundēs

Nākamajā rakstā es aprakstīšu sarežģītākus manifestu un leļļu paneļa tīmekļa saskarnes izveides piemērus.

Populāri leļļu resursu veidi
cron- cron darbu vadīšana
izpild- skriptu un komandu palaišana
failu- failu pārvaldība
failu kauss- failu dublējums
grupai- grupas vadība
saimnieks- ierakstu pārvaldība failā /etc/hosts
saskarne- tīkla saskarņu konfigurācija
mount- failu sistēmu montāža
paziņot- ziņojuma nosūtīšana uz Puppet log failu
iepakojums- pakotņu pārvaldība
pakalpojumu- pakalpojumu vadība
sshkey- SSH atslēgu pārvaldība
kārtīgs- failu dzēšana atkarībā no apstākļiem
lietotājs- lietotāju pārvaldība
zonām- Solaris zonas vadība

Mazliet par to, kā darbojas Lelle

Leļļu abstrakcija ir kaut kas līdzīgs šim ( laužot modeļus - aizmirstiet visu, ko zinājāt par programmēšanas terminiem!).

• Mezgls ir konfigurāciju kopa noteiktai mērķa sistēmai. Patiesībā šis ir īpašs klases gadījums.
• Klase ir deklaratīvās loģikas kopa, kas ir iekļauta mezgla konfigurācijā vai citās klasēs. Klasei nav ne gadījumu, ne metožu, bet tai ir loģikas ietvaros definēti parametri un mainīgie. Faktiski tā drīzāk ir procedūra, kas var mantot citu procedūru, vienkārši pievienojot kodu un tai ir ne tik banāls mainīgo lielumu apjoms.
• Tips- bet šī vairāk izskatās pēc klasiskas klases - tā pieņem gadījumus ar nosaukumu un noteikti noteiktiem parametriem, bet nekas vairāk. Konkrētu tipa implementāciju var uzrakstīt kā Puppet skriptu, izmantojot define , kas izveido citu tipu gadījumus, vai kā Ruby paplašinājumu ar brīnišķīgu lidojumu.
• Resurss- tie faktiski ir nosaukti tipu gadījumi. Katrs resursa nosaukums ir unikāls noteiktā tipa mezgla (direktorija) konfigurācijā.
• Mainīgie lielumi- nu, īsi sakot, tās ir konstantes... Pirms 4. lelles lietas bija vēl sliktākas ar to vērienu. Tagad tas ir adekvāti: lietošanai ārpus definīcijas vietas ir jānorāda pilnībā kvalificēts identifikators, izņemot klases mantojuma gadījumu.

Ideoloģiski pareizi Puppet infrastruktūra sastāv no aģenta - priviliģēta pakalpojuma mērķa sistēmā - un servera, kas pēc aģentu pieprasījuma izplata vērtīgas instrukcijas deklaratīvu resursu direktoriju veidā. Drošība tiek īstenota privātās publiskās atslēgas infrastruktūras līmenī (X.509). Vienkārši sakot, tie paši mehānismi kā HTTPS, bet ar savu CA un obligātu klienta sertifikāta pārbaudi.

Vienkāršotā veidā izvietošanas procedūra izskatās apmēram šādi:

1. Apstrāde, izmantojot TLS un X.509 (savienojuma izveide, CRL atjaunināšana, sertifikātu ierobežojumu pārbaude utt.)
2. Aģents saņem faktu ģeneratorus no servera ar kešatmiņu un visām lietām (precīzāk, viss tiek izvilkts no lib/ mapēm moduļos). Nav grūti pievienot savu Ruby skriptu, lai savāktu interesējošo informāciju.
3. Aģents apkopo faktus par mērķa sistēmu un nosūta to serverim. Visus faktus var viegli apskatīt manuāli, izmantojot leļļu faktu zvanu. Šie fakti ir pieejami kā globālie mainīgie.
4. Serveris sastāda resursu katalogu un nosūta to aģentam. Zem tā slēpjas vesels dažādu jēdzienu slānis.
5. Aģents izvelk visu nepieciešamo no servera un nogādā sistēmu norādītajā formā. Aģents pats nezina, ko darīt ar resursiem, tas paļaujas uz pakalpojumu sniedzēju ieviešanu (semantisks tulkojums būs “ieviesējs”, nevis piegādātājs) daži nodrošinātāji ir standarta un ir iekļauti Puppet pakotnēs pārējie tiek izvilkti no moduļiem.

• Modulis- deklaratīvo leļļu skriptu kolekcija, Ruby paplašinājumi programmai Puppet, faili, failu veidnes, Hiera dati un daudz kas cits. Pareizāks termins būtu "paka".
• Vide- skriptu, moduļu un Hiera datu kopums. Tā kā infrastruktūra kļuva sarežģītāka, neizbēgami radās nepieciešamība sadalīt konfigurāciju tālāk par standarta sadalījumu pa mezgliem. Būtībā tas ir nepieciešams izmēģinājuma jauninājumiem un banālai piekļuves kontrolei (kad ne visiem administratoriem ir piekļuve visiem IT infrastruktūras mezgliem).
• Hiera- hierarhiskā datu bāze. Šis formulējums var būt ļoti biedējošs. Iespējams, tāpēc tas tika mainīts vēlāko versiju dokumentācijā. Faktiski tas ir ārkārtīgi vienkāršs un ērts mehānisms konfigurācijas izvilkšanai no YAML vai JSON failiem. Hierarhija ir iespēja norādīt vairāku konfigurācijas failu lasīšanas secību – t.i. šo failu hierarhija/prioritāte.
  • Papildus datu iegūšanai funkciju izsaukumos, Puppet iegūst arī noklusējuma klases parametrus, kas ir galvenais akcents.
  • Protams, Hiera atbalsta faktu interpolāciju un pat speciālo funkciju izsaukšanu.
  • Programmā Puppet 4.3 viņi atkal ieviesa to pašu funkcionalitāti, lai atbalstītu ne tikai globālo datubāzi, bet arī lokālo vides un moduļa datubāzi, lai gan autors jau ir atradis vairākas problēmas to ieviešanā (PUP-5983, PUP-5952 un PUP-5899), kurus uzreiz salaboja Puppet Labs.
  • Vērtību iegūšanai no visiem hierarhijas failiem tiek atbalstītas vairākas stratēģijas:
    • pirmais - tiek atgriezta pirmā pēc prioritātes atrastā vērtība
    • unikāls - apkopo visas vērtības viendimensijas masīvā un noņem dublikātus
    • hash — apvieno visu atrasto YAML hash. Dublētas atslēgas tiek atlasītas pēc prioritātes.
    • deep būtībā ir rekursīva hash versija
  • Skaistums ir tāds, ka izlases stratēģiju var iestatīt, vai nu izsaucot funkciju lookup(), jo un jebkurā hierarhijas failā, izmantojot īpašo atslēgu lookup_options, kas tiek aktīvi izmantota cfnetwork modulī.
• PuppetDB- būtībā biznesa loģikas slānis ap relāciju datu bāzi (PostgreSQL), kas ļauj saglabāt atskaites par faktiem un veiktajām izvietošanām un eksportēt resursus turpmākai importēšanai uz direktorijiem citos mezglos vai atlasei, izmantojot īpašas funkcijas. Ir arī tīmekļa saskarne leļļu paneļa veidā.
• X.509 PKI- jau pieminētā sertifikātu infrastruktūra, kuru ir ārkārtīgi ērti izmantot citiem pakalpojumiem bez nepieciešamības pārvaldīt atsevišķu infrastruktūru.
• Mkolektīvs- šķiet noderīga lieta uz notikumiem balstītai uzdevumu palaišanai serveru fermā, taču autoram ir zināma neuzticēšanās konkrēta risinājuma drošībai.
• Leļļu kalve- atvērta platforma moduļu publicēšanai un lejupielādei.
• dažas citas funkcijas vadības ierīču veidā ārējās ierīces piemēram, Cisco aprīkojums un izvietošana uz tukša metāla, bet tas ir cits stāsts

Piezīmes par drošību un pieejamību

Puppet Server pieejamība nosaka spēju pārvaldīt visu infrastruktūru. Ir lietderīgi mitināt Puppet Server virtuālajā mašīnā uzticamākā un ātrāk atkopjamākā trešās puses mākonī nekā pašas iespējas. Vai arī jāinstalē vairāki serveri.

Jebkurā gadījumā sistēmā, kurā tiks izvietots Puppet Server ar zvaniņiem un svilpēm, nevajadzētu instalēt citus pakalpojumus. Virtualizācija un konteinerizācija var jums palīdzēt.

Multi-master (vairāki atsevišķi leļļu serveri)

• IN šajā gadījumā tikai viens serveris darbojas kā CA (sertifikācijas iestāde) — tā nepieejamība nozīmē, ka nav iespējams pievienot jaunus mezglus.
  • Puppet ļauj izmantot trešās puses X.509 infrastruktūru, ja iebūvētā tā nav apmierinoša.
• Visa konfigurācija (vide) ir jāsaglabā versiju kontroles sistēmā un jāizvieto katrā serverī vienlaicīgi.
• Vienīgais kopīgais ir PostgreSQL datu bāze, kuras augstas pieejamības organizēšana ir ārpus šī raksta darbības jomas.
• Cfpuppetserver modulis atbalsta gan primāro (ar CA), gan sekundāro servera instalāciju.

Kas būtiski ir mainījies kopš vecākām versijām

• Visi pakalpojumi ir pārvietoti uz JVM, JRuby un Jetty. Neskatoties uz acīmredzamajām integrācijas priekšrocībām, atmiņas patēriņa ziņā ir arī trūkumi.
• Ir pievienotas Lambda funkcijas kolekciju apstrādei - tagad nav nepieciešams griezt kruķus Ruby vai pervert, izmantojot create_resources()
• Ir parādījies rīks EPP veidņu apstrādei - būtībā tas pats ERB, bet ar Puppet DSL, nevis Ruby,
• Konfigurācijas failu noklusējuma direktoriju struktūra ir būtiski mainījusies
• Pievienots atbalsts datu nodrošinātājiem vidēm un moduļiem (uzlaušana vairs nav nepieciešama).
• Globālās Hiera lomas mazināšana. Jauna un ar to saistītā komanda ir leļļu meklēšana.

Uzstādīšana

Trīs galvenie servera komponenti ir pats Puppet Server, PuppetDB un PostgreSQL. Tos visus var saspiest vienā mezglā vai sadalīt divās vai trīs sistēmās. Puppet Server un Puppet DB var palaist vairākas reizes, taču PostgeSQL ir viens neveiksmes punkts. Ir dažādas pieejas PostgeSQL replikācijai un klasterēšanai Ērta pieeja galveno un sekundāro serveru gadījumā būtu Master + Read-Only Slave, kas tiek atbalstīts pašā PuppetDB kā galvenais un tikai lasāms datu bāzes mezgls, bet automatizējot šādus. iestatīšana prasa laiku, tāpēc tā vēl nav pieejama cfpuppetserver modulī.

Pati konfigurācija var vienkārši saglabāt vismaz failu sistēma kopā ar Puppet Server, bet tas ir kā skriptu rakstīšana uz ražošanas tīmekļa servera. Vispiemērotākais risinājums ir git repozitorijs. R10k utilīta var izvilkt visus repozitorija atzarus un izvietot tos Puppet Server kā atsevišķas vides. r10k diezgan slikti velk atkarības, tāpēc tiek izmantots bibliotekārs-lelle. Tūlīt ir vērts atzīmēt, ka galvenā kanoniskā Leļļu vide ir "ražošana". Tāpēc konfigurācijas repozitorijā ir jāizmanto filiāle, ko sauc par "produkciju", nevis "master".

Sistēmas prasības

Konfigurācija programmā Git

1. Repozitorija klonēšana: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. Mēs iestatām vispārīgus administratora piekļuves iestatījumus, izmantojot komentāros sniegtos padomus:
   • $EDITOR dati/common.yaml
3. Izveidosim mezgla konfigurāciju:
   • $MY_DOMAIN — sakne domēna vārds(piem., example.org)
   • $HOST_NAME — klienta resursdatora nosaukums bez domēna
   • mkdir dati/$MY_DOMAIN
   • cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
   • $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - mezgla iestatīšana ar Puppet Server saskaņā ar ieteikumiem komentāros
   • cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
   • $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml — patvaļīga mezgla iestatīšana, pamatojoties uz ieteikumiem komentāros
4. Mēs pārsūtām uz mūsu pašu Git serveri vai padarām to pieejamu lokāli mezglā ar Puppet Server, izmantojot rsync vai scp. Vietējā repozitorija ir ērta kā starpposma darbība, līdz Git serveris tiek izvietots no paša Puppet. Savā ziņā tas atgādina kompilatora salikšanu vairākos posmos.

Uzstādīšana no nulles uz tīras sistēmas

Mērķa sistēmā:

1. Lejupielādējiet instalācijas skriptu: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Pārskatām skriptu un saraucam pieri: less setup_puppetserver.sh
3. Palaist: bash setup_puppetserver.sh marionete.$(MY_DOMAIN) .
   • Piemērs ar attālo repozitoriju: bash setup_puppetserver.sh ssh:// [e-pasts aizsargāts]/puppet-conf
   • Piemērs ar lokālo: bash setup_puppetserver.sh file:///root/puppetconf/
4. Mēs redzam, kā sistēma uzpūšas un neinstalē visu ļoti ātri.
5. Ja repozitorijs ir attāls:
   • Izveidojiet SSH atslēgu saknei: ssh-keygen -t rsa -b 2048
   • Mēs reģistrējam publisko atslēgu /root/.ssh/id_rsa.pub attālajā Git serverī...
   • ... un tur mēs uzstādījām Git āķi, izsaucot šādu komandu: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
6. Mēs sākam manuāli izvietot konfigurāciju: /etc/puppetlabs/deploy.sh
7. Izmēģināsim, kā tas darbojas pašā serverī: /opt/puppetlabs/bin/puppet agent --test
8. Pārbaudiet tīkla, tīkla filtra un SSH piekļuves iestatījumus

Pārvaldīto mezglu pievienošana

1. Puppet Server pilnībā kvalificētajam nosaukumam ir jābūt pieejamam, izmantojot DNS pārvaldītajā resursdatorā, vai arī jāiekodētam mapē /etc/hosts.
   • Piemērs: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
2. Mezglā ar Puppet Server palaidiet šādu skriptu /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
3. Kopējiet visu rezultātu un ielīmējiet to mērķa sistēmas komandrindā.
4. Mēs gaidām izpildes beigas un palaižam /opt/puppetlabs/bin/puppet agent --test . Pēc pirmās palaišanas tiks ģenerēts sertifikāta parakstīšanas pieprasījums.
5. Mēs ejam uz Puppet Server mezglu, lai parakstītu sertifikātu.
   • marionet cert list - mēs pārbaudām sertifikāta parakstu par papildu paranoju.
   • marionetes sertifikāta paraksts $(HOST_NAME).$(MY_DOMAIN) — patiesībā mēs parakstām sertifikātu.
6. Mēs atgriežamies pārvaldītajā mezglā un vēlreiz izpildām: /opt/puppetlabs/bin/puppet agent --test`. Tas liks sākt izvietošanas procedūru.
7. Mēs gaidām izvietošanas pabeigšanu, izmantojot Puppet Agent.
8. Tas ir viss, jums ir gatava minimāla Leļļu infrastruktūra!

Izvades piemērs no /root/genclientinit.sh

bash</etc/cflocation fi ja tests ! -z ""; tad echo -n >/etc/cflocationpool fi ja tests! -z "\$http_starpniekserveris"; pēc tam eksportēt http_proxy eksportēt https_proxy="\$http_proxy" eksportēt HTTP_PROXY="\$http_proxy" eksportēt HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname saimniekdatora nosaukums host.example.com ja ! kas lsb-release | lasīt; tad apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; pēc tam atkārtojiet "Neizdevās noteikt pareizo koda nosaukumu" iziet 1. fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(koda nosaukums).deb dpkg -i puppetlabs-release-pc1-\$(koda nosaukums) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<marionet cert sign host.example.com" atbalss "Izmantojiet CTRL+C, lai apturētu ciklu, ja neizdodas dažādu iemeslu dēļ" miegs 5 pabeigts EOT

Moduļa apraksts

Pilns Bash parametru saraksts sākotnējās instalēšanas skriptam