Leļļu meistars: Leļļu attālās konfigurācijas pārvaldības sistēmas uzstādīšana un konfigurēšana. Leļļu meistars: Leļļu attālās konfigurācijas pārvaldības sistēmas uzstādīšana un konfigurēšana Leļļu uzstādīšana
Lai efektīvāk izmantotu Puppet, jums ir jāsaprot, kā tiek veidoti moduļi un manifesti. Šajā rokasgrāmatā tiks parādīts, kā darbojas šie leļļu komponenti, iestatot LAMP skursteni Ubuntu 14.04 serverī.
Prasības
- Leļļu uzstādīšana (meistars un aģents). Vairāk par šo -.
- Iespēja izveidot vismaz vienu Ubuntu 14.04 virtuālo serveri, lai apkalpotu Puppet aģenta mezglu.
Leļļu koda pamati
Resursi
Leļļu kods lielākoties sastāv no resursiem. Resurss ir koda daļa, kas apraksta sistēmas stāvokli un nosaka tai nepieciešamās izmaiņas. Piemēram:
lietotājs ("mitchell":
nodrošināt => klāt,
uid => "1000",
gid => "1000",
apvalks => "/bin/bash",
mājas => "/home/mitchell"
}
Resursu deklarācijai ir šāds formāts:
resursa_veids("resursa_nosaukums"
atribūts => vērtība
...
}
Lai skatītu visus leļļu resursu veidus, ievadiet komandu:
leļļu resurss -- veidi
Uzziniet vairāk par resursu veidiem šajā rokasgrāmatā.
manifesti
Manifests ir orķestrēšanas skripts. Leļļu programmas ar paplašinājumu .pp sauc par manifestiem. Noklusējuma Leļļu manifests ir /etc/puppet/manifests/site.pp.
Klases
Tāpat kā ar jebkuru parasto programmēšanas valodu, klases ir atbildīgas par orķestrēšanas daļu organizēšanu un atkārtotu izmantošanu.
Klases definīcija satur koda bloku, kas apraksta, kā klase darbojas. Kad esat definējis klasi, varat to izmantot manifestos.
Klases definīcijai ir šāds formāts:
class example_class(
...
kodu
...
}
Šis kods definē klasi example_class. Leļļu kods būs iekavās.
Klases deklarācija ir vieta kodā, kur tiek izsaukta noteikta klase. Deklarējot klasi, Puppet apstrādā tās kodu.
Klases deklarācija ir parasta un pēc resursa veida.
Parasta klases deklarācija tiek pievienota kodam, izmantojot atslēgvārdu iekļaut.
iekļaut example_class
Deklarējot pēc resursa veida, klase tiek deklarēta resursa formātā:
klase ( "example_class": )
Šāda deklarācija ļauj kodam pievienot klases parametrus, kas ignorē klases atribūtu noklusējuma vērtības. Piemēram:
mezgls "host2" (
class ( "apache": ) # izmantojiet apache moduli
apache::vhost( "example.com": # definējiet vhost resursu
ports => "80",
docroot => "/var/www/html"
}
}
Moduļi
Modulis ir manifestu un citu failu grupa, kas sakārtota iepriekš noteiktā veidā, kas ļauj viegli koplietot un atkārtoti izmantot atsevišķas orķestrācijas daļas. Moduļi palīdz sakārtot leļļu kodu, jo tos var izmantot, lai kodu sadalītu vairākos manifestos.
Leļļu moduļi tiek glabāti direktorijā /etc/puppet/modules.
Manifesta rakstīšana
Varat praktizēt Puppet manifestu, moduļu un klašu rakstīšanu, izmantojot piemēru par LAMP steka instalēšanu Ubuntu serverī (rezultāts būs ).
Tātad, lai organizētu Ubuntu 14.04 serveri un instalētu tajā LAMP steku, jums ir nepieciešami resursi, lai veiktu šādas darbības:
- instalējot apache2 pakotni.
- sāciet apache2 pakalpojumu.
- pakotnes uzstādīšana MySQL serveri, mysql-serveris.
- sākt mysql pakalpojumu.
- php5 pakotnes instalēšana
- PHP testa skripta izveide, info.php.
- apt indeksa atjaunināšana pirms katras pakotnes instalēšanas.
Tālāk ir norādīti trīs leļļu koda piemēri, kurus var izmantot, lai sasniegtu šo LAMP kaudzes iestatījumu.
Pirmais piemērs iemācīs jums rakstīt pamata manifestus vienā failā. Otrais piemērs palīdzēs jums izveidot un izmantot klasi un moduli, pamatojoties uz iepriekš rakstītiem manifestiem. Trešajā piemērā jūs uzzināsit, kā izmantot iepriekš izveidotus publiskos moduļus, lai instalētu LAMP steku.
Piezīme: Testēšanai labāk izmantot jaunu virtuālo serveri.
1. piemērs: LAMP instalēšana ar vienu manifestu
Leļļu manifestu var uzrakstīt aģenta mezglā un pēc tam izpildīt ar komandu marionet apply (šim nolūkam nav nepieciešams instalēt galveno un aģentu).
Šajā sadaļā jūs uzzināsit, kā rakstīt manifestus, kuros tiks izmantotas šāda veida resursu deklarācijas:
- exec: izpildiet komandas.
- pakotne: instalējiet pakotnes.
- pakalpojums: pakalpojumu vadība.
- fails: failu pārvaldība.
Izveidojiet manifestu
Izveidojiet jaunu manifestu:
sudo vi /etc/puppet/manifests/lamp.pp
Pievienojiet tam šādu kodu, lai deklarētu nepieciešamos resursus.
# palaist komandu "apt-get update"
exec("apt-update": # resurss exec "apt-update"
komanda => "/usr/bin/apt-get update" # komanda šis resurss darbosies
}
# instalējiet apache2 pakotni
pakotne ("apache2":
prasīt => Izpildīt["apt-update"], # pieprasiet "apt-update" pirms pakotnes instalēšanas
nodrošināt => uzstādīts,
}
# sākt apache2 pakalpojumu
pakalpojums ("apache2":
nodrošināt => skriešanu,
}
# instalējiet mysql-serveri
pakotne ("mysql-serveris":
prasīt => Izpildīt["apt-update"], # pirms instalēšanas pieprasiet "apt-update"
nodrošināt => uzstādīts,
}
# sākt mysql pakalpojumu
pakalpojums ("mysql":
nodrošināt => skriešanu,
}
# instalējiet php5 pakotni
pakotne ("php5":
prasīt => Izpildīt["apt-update"], # pirms instalēšanas pieprasiet "apt-update"
nodrošināt => uzstādīts,
}
# sākt pakalpojumu info.php
fails ("/var/www/html/info.php":
nodrošināt => failu
saturs => "", # phpinfo kods
prasīt => pakotne["apache2"], # pieprasījuma pakotne "apache2"
}
Manifests pieteikums
Lai izmantotu jauno manifestu, ievadiet komandu:
sudo puppet pieteikties --tests
Tas izvadīs apjomīgu rezultātu, kas parāda visas izmaiņas vides stāvoklī. Ja izvadē nav kļūdu, jums vajadzētu būt iespējai pārlūkprogrammā atvērt savu ārējo IP adresi vai domēna nosaukumu. Ekrānā parādīsies PHP testa lapa ar steku informāciju. Tas nozīmē, ka darbojas Apache un PHP.
LAMP steks tagad ir instalēts serverī, izmantojot Puppet.
Tas ir diezgan vienkāršs manifests, jo to var izpildīt aģentam. Ja jums nav leļļu meistara, citi aģenta mezgli nevarēs izmantot šo manifestu.
Leļļu galvenais serveris ik pēc 30 minūtēm pārbauda servera stāvokļa izmaiņas.
2. piemērs: LAMP kaudzes instalēšana, izmantojot moduli
Tagad mēģiniet izveidot vienkāršu moduli, pamatojoties uz LAMP manifestu, kuru rakstījāt iepriekšējā sadaļā.
Lai izveidotu moduli, moduļu direktorijā izveidojiet jaunu direktoriju (tā nosaukumam jāsakrīt ar moduļa nosaukumu). Šajā direktorijā ir jāietver manifestu direktorijs un fails init.pp. Fails init.pp norāda Puppet klasi (tā nosaukumam arī jāsakrīt ar moduļa nosaukumu).
Moduļa izveide
Dodieties uz Puppet master serveri un izveidojiet moduļa direktoriju struktūru:
cd /etc/puppet/modules
sudo mkdir -p lampa/manifesti
Izveidojiet un atveriet failu init.pp redaktorā:
sudo vi lamp/manifests/init.pp
Failā ievietojiet lampas klasi:
klases lampa (
}
Kopējiet manifesta saturu no 1. sadaļas un ielīmējiet to lampas klases blokā. Tagad jums ir lampas klases definīcija. Citi manifesti varēs izmantot šo klasi kā moduli.
Saglabājiet un aizveriet failu.
Moduļa izmantošana galvenajā manifestā
Tagad varat iestatīt galveno manifestu un izmantot lampas moduli, lai instalētu LAMP steku serverī.
Galvenā leļļu serverī rediģējiet šādu failu:
sudo vi /etc/puppet/manifests/site.pp
Visticamāk ieslēgts Šis brīdis fails ir tukšs. Pievienojiet tai šādas rindas:
node default ()
mezgls "lampa-1" (
}
Piezīme: nomainiet lampu-1 ar sava leļļu aģenta resursdatora nosaukumu, kurā vēlaties instalēt steku.
Mezglu bloks ļauj norādīt Puppet kodu, kas attieksies tikai uz noteiktiem mezgliem.
Noklusējuma bloks attiecas uz visiem aģenta mezgliem, kuriem nav atsevišķa bloka (atstājiet to tukšu). Lamp-1 bloks tiks piemērots aģenta mezglam lamp-1.
Pievienojiet šim blokam šādu rindu, kurā tiek izmantots lampas modulis:
Saglabājiet un aizveriet failu.
Tagad Puppet aģenta mezgls varēs lejupielādēt iestatījumus no galvenā servera un instalēt LAMP steku. Ja vēlaties veikt izmaiņas tūlīt, aģentā palaidiet šādu komandu:
sudo leļļu aģents --tests
Moduļi ir ērtākais veids, kā atkārtoti izmantot Leļļu kodu. Turklāt moduļi palīdz loģiski sakārtot kodu.
3. piemērs: LAMP instalēšana, izmantojot publiskos moduļus
MySQL modulis tiek izmantots līdzīgi. Pievienojiet mezgla blokam šādas rindas:
class ("mysql::serveris":
root_password => "parole",
}
Varat arī nodot MySQL moduļa opcijas.
Pievienojiet resursu, kas kopēs info.php uz pareizo vietu. Izmantojiet avota parametru. Pievienojiet mezgla blokam šādas rindas:
file( "info.php": # resursa faila nosaukums
ceļš => "/var/www/html/info.php", # mērķa ceļš
nodrošināt => failu
prasīt => Klase ["apache"], # izmantojamā apache klase
source => "puppet:///modules/apache/info.php", # kur kopēt failu
}
Šajā klases deklarācijā satura vietā tiek izmantots avota parametrs. Šī opcija ne tikai izmanto faila saturu, bet arī to kopē.
Puppet kopēs failu puppet:///modules/apache/info.php uz /etc/puppet/modules/apache/files/info.php.
Saglabājiet un aizveriet failu.
Izveidojiet info.php failu.
sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"
Tagad Puppet aģenta mezgls varēs lejupielādēt iestatījumus no galvenā servera un instalēt LAMP steku. Ja vēlaties veikt izmaiņas aģenta vidē tieši tagad, palaidiet šo komandu šajā mezglā:
sudo leļļu aģents --tests
Šī komanda lejupielādēs visus pašreizējā mezgla atjauninājumus un instalēs tajā esošo steku. Lai pārliecinātos, ka darbojas Apache un PHP, pārlūkprogrammā atveriet mezgla IP adresi vai domēnu:
http://lamp_1_public_IP/info.php
Secinājums
Tagad jums ir pamatzināšanas par Leļļu moduļiem un manifestiem. Mēģiniet pats izveidot vienkāršu manifestu un moduli.
Puppet ir lieliski piemērots lietojumprogrammu konfigurācijas failu pārvaldīšanai.
Birkas: ,Daži dziesmu teksti.Šķiet, ka viss cikls jāsāk ar šo rakstu, bet tomēr mērķauditorija ir pieredzējušāki Puppet Labs Open Source produktu lietotāji, kuri nav apmierināti ar atsevišķiem slikti integrētiem moduļiem ar Puppet Forge. Tāpat kā jebkurā gadījumā "bibliotēka pret ietvaru", atmaksāšanās ir integrētā risinājuma autora pasaules skatījuma ievērošana.
Mazliet par to, kā darbojas Lelle
Lelle galvenokārt ir īpaša valoda sistēmas galīgā stāvokļa deklaratīvai precizēšanai. Salīdzinājumam ārkārtīgi piemērots ir GNU Makefile, kur papildus tiešam atkarību aprakstam iespējams krāpties līdz galam.Leļļu abstrakcija ir aptuveni šāda ( modeļu laušana – aizmirsti visu, ko zināji par terminiem programmēšanā!).
- Mezgls ir noteiktas mērķa sistēmas konfigurāciju kolekcija. Patiesībā šis ir īpašs klases gadījums.
- klasē ir deklaratīvās loģikas kopa, kas ir iekļauta resursdatora konfigurācijā vai citās klasēs. Klasei nav gadījumu vai metožu, bet loģikā ir definēti parametri un mainīgie. Faktiski tā drīzāk ir procedūra, kas var mantot citu procedūru ar triviālu kodu un ne visai banālu mainīgo lielumu.
- veids- bet šī jau vairāk izskatās pēc klasiskas klases - pieņem gadījumus ar nosaukumu un noteikti dotie parametri, bet nekas vairāk. Konkrēta 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.
- resursu- patiesībā tie ir nosaukti tipu gadījumi. Katra resursa nosaukums ir unikāls konkrēta tipa mezgla (direktorija) konfigurācijā.
- Mainīgie lielumi- nu, īsi sakot, tās ir konstantes... Pirms Lelles 4 to apjoms vēl bija sliktāks. Tagad tas ir adekvāti: lietošanai ārpus definīcijas vietas ir nepieciešams pilnībā kvalificēts identifikators, izņemot klases mantojuma gadījumā.
Ideoloģiski pareizā veidā 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 izsniedz 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 verifikāciju klienta sertifikāts.
Vienkāršotā veidā izvietošanas procedūra izskatās apmēram šādi:
- Apstrāde, izmantojot TLS un X.509 (savienojuma izveide, CRL atjaunināšana, sertifikātu ierobežojumu pārbaude utt.)
- Aģents saņem faktu ģeneratorus no servera ar kešatmiņu un visiem gadījumiem (precīzāk, viss tiek izvilkts no lib/ mapēm moduļos). Ir viegli pievienot savu Ruby skriptu, lai apkopotu interesējošo informāciju.
- Aģents apkopo faktus par mērķa sistēmu un nosūta to serverim. Visus faktus var viegli pārskatīt manuāli, izsaucot leļļu faktus. Šie fakti ir pieejami kā globālie mainīgie.
- Serveris katalogē resursus un nosūta aģentam. Zem tā slēpjas vesels dažādu jēdzienu slānis.
- Aģents izvelk visu nepieciešamo no servera un nogādā sistēmu norādītajā formā. Tajā pašā laikā aģents pats nezina, kā rīkoties ar resursiem, tas paļaujas uz noteikta veida resursu nodrošinātāju "s (semantiskais tulkojums būs "ieviesējs", nevis nodrošinātājs) ieviešanu. Daži nodrošinātāji ir standarta un ir iekļauti Puppet pakotnēs, bet pārējie tiek izvilkti no moduļiem.
- Modulis- Deklarējošu 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 kolekcija. Sarežģīto infrastruktūru neizbēgami bija nepieciešams nodalīt konfigurāciju tālāk par standarta sadalījumu mezglos. 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 sastāv no iespējas iestatīt secību, kādā tiek nolasīti vairāki konfigurācijas faili - t.i. šo failu hierarhija/prioritāte.
- Papildus datu iegūšanai funkcijas izsaukumā, Puppet pēc noklusējuma izvelk klases parametrus, kas ir galvenais akcents.
- Protams, Hiera atbalsta faktu interpolāciju un pat speciālo funkciju izsaukšanu.
- Programmā Puppet 4.3 tā pati funkcionalitāte tika ieviesta vēlreiz, lai atbalstītu ne tikai globālo datu bāzi, bet arī lokālo vidi un moduli, lai gan autors jau ir atradis vairākas problēmas to ieviešanā (PUP-5983 , PUP-5952 un PUP-5899), kuras nekavējoties novērsa Puppet Labs.
- Vērtības 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 — savieno visu atrasto YAML Hash. Dublētas atslēgas tiek atlasītas pēc prioritātes.
- deep - būtībā rekursīva hash versija
- Skaistums ir tāds, ka ielādes stratēģiju var iestatīt kā tad, kad tiek izsaukta funkcija lookup(), jo un jebkurā hierarhijas failā, izmantojot īpašo lookup_options atslēgu, kas tiek aktīvi izmantota cfnetwork modulī.
- PuppetDB- faktiski biznesa loģikas slānis ap relāciju datu bāzi (PostgreSQL), kas ļauj saglabāt atskaites par faktiem un izvietošanu un eksportēt resursus, lai pēc tam importētu uz direktorijiem citos mezglos vai atlasēs, izmantojot īpašas funkcijas. Ir arī tīmekļa seja leļļu informācijas paneļa formā.
- 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āms pārliecības trūkums par konkrēta risinājuma drošību.
- Leļļu kalve- atvērta platforma moduļu publicēšanai un lejupielādei.
- dažas citas funkcijas kontroles veidā ārējās ierīces Cisco aprīkojuma veids un izvietošana uz tukša metāla, bet tas ir cits stāsts
Piezīmes par drošību un pieejamību
Ir jāsaprot, ka Puppet Server kļūst par neaizsargātu visas IT infrastruktūras punktu, jo nosaka visu sistēmu galīgo konfigurāciju. Īpašos gadījumos ir jēga veikt atdalīšanu - atsevišķu serveri kritiskās infrastruktūras elementiem ar ārkārtīgi ierobežota piekļuve un manuāls atjauninājums un otrs visam pārējam.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ā tas ir pieejams. 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, kas jums palīdzēs.
Multi-master (vairāki atsevišķi leļļu serveri)
- Š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ā jums nav piemērota.
- Visa konfigurācija (vide) ir jāsaglabā versiju kontrolē un jāizvieto katrā serverī vienlaikus.
- Vienīgais, kas kopīgs, ir PostgreSQL bāze, kuras organizācija ir ļoti pieejama, šī raksta ietvaros.
- 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
Pilns apraksts ir pieejams no ražotāja.- Visi pakalpojumi ir pārvietoti uz JVM, JRuby un Jetty. Aiz acīmredzamajām integrācijas priekšrocībām slēpjas arī trūkumi atmiņas patēriņa ziņā.
- Pievienotas lambda funkcijas kolekciju apstrādei — tagad nav nepieciešams griezt Ruby kruķus vai pervert, izmantojot create_resources()
- Parādījās EPP veidņu apstrādes rīks — būtībā tas pats ERB, bet ar Puppet DSL, nevis Ruby,
- Noklusējuma konfigurācijas failu direktoriju struktūra ir daudz mainījusies
- Pievienots atbalsts datu nodrošinātājiem vidēm un moduļiem (nav nepieciešami vairāk uzlaušanas).
- Globālās Hiera lomas noniecināšana. Jauna saistīta komanda ir leļļu meklēšana.
Uzstādīšana
Šis process ir diezgan primitīvs, bet prasa noteiktu darbību secību. Tā kā to izdarīt manuāli ir nepateicīgs uzdevums, autors iemācīs jums slikto lietu, proti, lejupielādēt nesaprotamus skriptus no interneta un palaist kā root savā sistēmā.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 atteices mezgls. PostgeSQL replikācijai un klasterēšanai ir dažādas pieejas.Primāro un sekundāro serveru gadījumā ērta pieeja būtu Master + Read-Only Slave, kas tiek atbalstīts pašā PuppetDB kā primārais un tikai lasāms datu bāzes mezgls, taču šīs iestatīšanas automatizācija prasa laiku un tāpēc vēl nav iekļauta cfpuppetserver modulī.
Jūs varat vienkārši saglabāt konfigurāciju tieši 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 ar nosaukumu "ražošana", nevis "master".
Sistēmas prasības
Attiecībā uz dzelzi to apraksta ražotājs. Cfpuppetserver modulis pašlaik atbalsta tikai Debian Jessie+ un Ubuntu Trusty+.Konfigurācija programmā Git
Pašam r10k repozitorija atrašanās vietai nav lielas nozīmes - galvenais ir tā pieejamība. Piemēram, testēšanas nolūkos repozitoriju var mitināt tajā pašā sistēmā, kurai var piekļūt, izmantojot failu:// . Labs sākums būtu codingfuture/puppet-exampleenv konfigurācijas piemērs.- Klonēt repozitoriju: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
- Iestatiet vispārīgos administratora piekļuves iestatījumus, izmantojot ieteikumus komentāros:
- $EDITOR dati/common.yaml
- Izveidosim mezgla konfigurāciju:
- $MY_DOMAIN — saknes domēna nosaukums (piemēram, 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, kā ieteikts 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 saskaņā ar ieteikumiem komentāros
- Mēs pārsūtām uz mūsu pašu Git serveri vai padarām to pieejamu lokāli Puppet Server mezglā, izmantojot rsync vai scp. Vietējā repozitorija ir noderīga kā starpposms, līdz Git serveris tiek izvietots no paša Puppet. Savā ziņā tas ir kā kompilatora izveide vairākos posmos.
Mēs uzstādām no nulles uz tīras sistēmas
Cfpuppetserver modulis ļauj instalēt visu, izmantojot pašu Puppet, bet sākotnējai instalēšanai pamatdarbības tiek dublētas ar Bash skriptu.Mērķa sistēmā:
- Lejupielādējiet iestatīšanas skriptu: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
- Pārskatām skriptu un saraucam pieri: less setup_puppetserver.sh
- Palaist: bash setup_puppetserver.sh
marionete.$(MY_DOMAIN) . - Attālās krātuves piemērs: bash setup_puppetserver.sh ssh:// [aizsargāts ar e-pastu]/puppet-conf
- Piemērs ar lokālo: bash setup_puppetserver.sh file:///root/puppetconf/
- Mēs skatāmies, kā sistēma uzpūš un neinstalē visu ļoti ātri.
- Ja attālā repozitorija:
- Izveidojiet SSH atslēgu saknei "a: ssh-keygen -t rsa -b 2048
- Mēs reģistrējam publisko atslēgu /root/.ssh/id_rsa.pub attālajā Git serverī...
- ... un tajā pašā vietā mēs uzstādījām Git āķi ar šādu komandu: /usr/bin/ssh -T [aizsargāts ar e-pastu].$(MY_DOMAIN) ./puppetdeploy.sh
- Palaidiet konfigurācijas izvietošanu manuāli: /etc/puppetlabs/deploy.sh
- Pamēģināsim, kā tas darbojas pašā serverī: /opt/puppetlabs/bin/puppet agent --test
- Pārbaudiet tīkla iestatījumus, tīkla filtrs un SSH piekļuve
Pārvaldīto mezglu pievienošana
- Pilnībā kvalificētam Puppet Server nosaukumam ir jābūt pieejamam, izmantojot DNS pārvaldītajā resursdatorā, vai ar vadu savienotam mapē /etc/hosts.
- Piemērs: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
- Puppet Server resursdatorā palaidiet šādu skriptu /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
- Rezultāts tiek pilnībā kopēts un ielīmēts komandrinda mērķa sistēmā.
- Mēs gaidām izpildes pabeigšanu un izpildām /opt/puppetlabs/bin/puppet agent --test . Pirmo reizi palaižot to, tiks ģenerēts sertifikāta parakstīšanas pieprasījums.
- Mēs ejam uz Puppet Server mezglu, lai parakstītu sertifikātu.
- leļļu sertifikātu saraksts — pārbaudiet sertifikāta parakstu, vai nav lielākas paranojas.
- marionetes sertifikāta zīme $(HOST_NAME).$(MY_DOMAIN) - patiesībā mēs parakstām sertifikātu.
- 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.
- Mēs gaidām izvietošanas pabeigšanu, izmantojot Puppet Agent.
- Tas ir viss, jums ir gatava minimālā Leļļu infrastruktūra!
Izvades paraugs no /root/genclientinit.sh
bash<
Moduļa apraksts
Pilns Bash skripta opciju saraksts sākotnējai instalēšanai
~# ./setup_puppetserver.sh Lietojums: ./setup_puppetserver.sh- r10k_repo_url — Git repozitorija URI
- certname ir pilnībā kvalificēts mezgla domēna nosaukums
- cflocation — fakta cf_location inicializācija
- cflocationpool — fakta cf_location_pool inicializācija
- http_proxy — starpniekserveris HTTP un HTTPS pieprasījumiem
Pilns Bash parametru saraksts Puppet klienta sākuma skriptam
~# /root/genclientinit.sh Lietojums: ./genclientinit.shParametra vērtība ir tāda pati kā iepriekšējā skriptā.
cfpuppetserver klase
- deployuser = "deploypuppet" — lietotājvārds, lai automātiski izvietotu konfigurācijas atjauninājumus
- deployuser_auth_keys = undef — $deployuser atslēgu saraksts
- repo_url = undef — repozitorija URI (piemērs: ssh:// [aizsargāts ar e-pastu]/repo vai fails:///some/path)
- puppetserver = true — vai šajā mezglā instalēt Puppet Server komponentu
- puppetdb = true — vai šajā mezglā instalēt PuppetDB komponentu
- puppetdb_port = 8081 — PuppetDB ports
- setup_postgresql = true — vai šajā mezglā instalēt PostgreSQL komponentu (tikai tad, ja ir iespējota PuppetDB instalēšana)
- service_face = "jebkurš" — cfnetwork::iface resursa nosaukums ienākošo savienojumu pieņemšanai
- puppetserver_mem = automātiski — RAM leļļu serverim megabaitos (vismaz 192 MB)
- puppetdb_mem = auto - RAM PuppetDB megabaitos (vismaz 192 MB)
- postgresql_mem = automātiski — PostgreSQL operatīvā atmiņa megabaitos (vismaz 128 MB)
klases cfpuppetserver::puppetdb
- postgresql_host = "localhost" — datu bāzes adrese
- postgresql_listen = $postgresql_host — vērtība nonāk tieši klausīšanās_addresses PostgreSQL direktīvā
- postgresql_port = 5432 — datu bāzes ports
- postgresql_user = "puppetdb" — PuppetDB lietotājs datu bāzē
- postgresql_pass = "puppetdb" - PuppetDB lietotāja parole datu bāzē
- postgresql_ssl = false — iespējot savienojuma šifrēšanu, pamatojoties uz Puppet PKI sertifikātiem
klases cfpuppetserver::puppetserver
- autosign = false — NEDRĪKST izmantot ražošanas vidē, izņemot DMZ. Pastāv tikai testēšanas automatizācijai.
- global_hiera_config = "cfpuppetserver/hiera.yaml" - ceļš uz noklusējuma Hiera konfigurācijas failu saskaņā ar Puppet canons (pirmais komponents ir moduļa nosaukums, pārējais ir ceļš zem failiem/mapes modulī)
Jūs varat palīdzēt un pārskaitīt dažus līdzekļus vietnes attīstībai
Pārvaldīt lielu skaitu Unix sistēmu nav ērti. Lai mainītu vienu parametru, administratoram ir jāpiekļūst katrai mašīnai, skripti var palīdzēt tikai daļēji, un ne visās situācijās.
Jāatzīst, ka Windows tīkla administratori joprojām atrodas labākā situācijā. Pietiek nomainīt grupas politikas iestatījumus un pēc kāda laika visi tīklā esošie datori, arī tie, kuros ir nesen instalēta operētājsistēma, “uzzinās” par jauninājumu, ja tie, protams, uz tiem attiecas. Atskatoties uz Unix ilgo vēsturi, nekas tāds nekad nav izdevies. Ir tādi risinājumi kā kickstart, kas palīdz sākotnējā instalācijā. operētājsistēma, taču turpmāka precizēšana prasīs ievērojamas pūles. Komerciālie risinājumi, piemēram, BladeLogic un OpsWare, tikai daļēji atrisina iestatījumu automatizācijas problēmu, to galvenā priekšrocība ir klātbūtne. GUI, un tikai lielas organizācijas var atļauties tos iegādāties. Protams, ir projekti, kas piedāvā bezmaksas risinājumus, taču visu pastāvēšanas laiku tie nav spējuši izveidot lielu kopienu. Piemēram, Cfengine nav īpaši populārs administratoru vidū, lai gan to var izmantot *BSD, Windows un Mac OS X bez Linux. Varbūt tas ir saistīts ar relatīvo sarežģītību konfigurāciju veidošanā. Aprakstot uzdevumus, ir jāņem vērā katras konkrētās sistēmas iezīmes un manuāli jākontrolē darbību secība, izpildot komandas. Tas nozīmē, ka administratoram ir jāatceras, ka dažām sistēmām jāraksta adduser citām useradd, jāņem vērā failu atrašanās vieta dažādās sistēmās utt. Tas par lielumu sarežģī komandu rakstīšanas procesu, ir ļoti grūti izveidot pareizo konfigurāciju, atrodoties ceļā, un pēc kāda laika ir gandrīz neiespējami nolasīt izveidotās konfigurācijas. Neskatoties uz GPL licenci, Cfengine patiesībā ir viena cilvēka projekts, kas kontrolē visas izmaiņas un nav īpaši ieinteresēts atvērtas sabiedrības veidošanā. Rezultātā cfengine iespējas ir diezgan apmierinošas izstrādātājam, un citiem administratoriem tas vairāk sagādā papildu galvassāpes. Lai uzlabotu cfengine, trešo pušu izstrādātāji radīja dažādus papildinājumus, kas bieži vien tikai pasliktināja situāciju. Vairāku šādu cfengine moduļu autors Lūks Kanijs galu galā nolēma izstrādāt līdzīgu rīku, taču tam nebija daudz cfengine trūkumu.
Leļļu funkcijas
Puppet, tāpat kā cfengine, ir klienta-servera sistēma, kas izmanto deklaratīvu, tas ir, obligātu valodu, lai aprakstītu uzdevumus un bibliotēkas to ieviešanai. Klienti periodiski (pēc noklusējuma 30 minūtes) izveido savienojumu ar centrālo serveri un saņem jaunāko konfigurāciju. Ja saņemtie iestatījumi neatbilst sistēmas stāvoklim, tie tiks izpildīti, nepieciešamības gadījumā serverim tiek nosūtīta atskaite par veiktajām darbībām. Ziņojumu serveris var saglabāt syslog vai failā, izveidot RRD grafiku, nosūtīt to uz norādīto e-pastu. Papildu abstrakcijas slāņi Transaction un Resource nodrošina maksimālu savietojamību ar esošajiem iestatījumiem un lietojumprogrammām, ļaujot koncentrēties uz sistēmas objektiem, neuztraucoties par atšķirībām ieviešanā un detalizēto komandu un failu formātu aprakstos. Administrators darbojas tikai ar objekta tipu, par pārējo rūpējas Lelle. Tā kā pakotņu tips zina apmēram 17 pakotņu sistēmas, nepieciešamā tiks automātiski atpazīta, pamatojoties uz informāciju par izplatīšanas komplekta vai sistēmas versiju, lai gan nepieciešamības gadījumā pakotņu pārvaldnieku var piespiest.
Atšķirībā no skriptiem, kurus bieži nevar izmantot citās sistēmās, trešo pušu administratoru rakstītās leļļu konfigurācijas lielākoties nevainojami darbosies jebkurā citā tīklā. Leļļu pavārgrāmatā[ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] ir jau trīs desmiti gatavu recepšu. Puppet pašlaik oficiāli atbalsta šādas operētājsistēmas un pakalpojumus: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo un MySQL, LDAP.
Leļļu valoda
Lai iet tālāk, vispirms ir jāsaprot valodas pamatelementi un iezīmes. Valoda ir viena no stiprās puses Lelle. Ar tās palīdzību tiek aprakstīti resursi, kurus administrators plāno pārvaldīt, un darbības. Atšķirībā no vairuma līdzīgu risinājumu, programmā Puppet valoda ļauj viegli piekļūt visiem līdzīgiem resursiem jebkurā sistēmā neviendabīgā vidē. Resursa apraksts parasti sastāv no nosaukuma, veida un atribūtiem. Piemēram, norādiet uz /etc/passwd failu un iestatiet tā atribūtus:
fails ("/etc/passwd":
īpašnieks => sakne,
grupa => sakne,
Tagad klienti, kas savienojas ar serveri, kopēs /etc/passwd failu un iestatīs norādītos atribūtus. Vienā noteikumā varat definēt vairākus resursus vienlaikus, atdalot tos ar semikolu. Bet ko darīt, ja serverī izmantotais konfigurācijas fails atšķiras no klienta failiem vai netiek izmantots vispār? Piemēram, šī situācija var rasties, iestatot VPN savienojumus. Šajā gadījumā varat norādīt uz failu ar avota direktīvu. Šeit ir divas iespējas, kā parasti, lai norādītu ceļu uz citu failu, tiek atbalstīti arī divi protokola URI: fails un marionete. Pirmajā gadījumā tiek izmantota saite uz ārēju NFS serveri, otrajā gadījumā uz Puppet servera tiek palaists NFS līdzīgs pakalpojums, kas eksportē resursus. Pēdējā gadījumā ceļš pēc noklusējuma ir saistīts ar leļļu saknes direktoriju - /etc/puppet. Tas nozīmē, ka saite puppet://server.domain.com/config/sshd_config atbilst failam /etc/puppet/config/sshd_config. Šo direktoriju var ignorēt, izmantojot direktīvu filebucket, lai gan pareizāk ir izmantot tāda paša nosaukuma sadaļu /etc/puppet/fileserver.conf failā. Šajā gadījumā jūs varat ierobežot piekļuvi pakalpojumam tikai no noteiktām adresēm. Piemēram, aprakstīsim konfigurācijas sadaļu.
ceļš /var/puppet/config
atļaut *.domain.com
atļaut 192.168.0.*
atļaut 192.168.1.0/24
noliegt *.wireless.domain.com
Un tad mēs atsaucamies uz šo sadaļu, aprakstot resursu.
avots => "puppet://server.domain.com/config/sshd_config"
Pirms kola ir resursa nosaukums. Vienkāršākajos gadījumos nosaukumu var vienkārši norādīt, labāk izmantot aizstājvārdu vai mainīgos. Pseidonīms tiek iestatīts, izmantojot aizstājvārdu direktīvu. pilns ceļš uz failu. Sarežģītākās konfigurācijās
fails ("/etc/passwd":
alias => passwd
Vēl viena aizstājvārda izveides iespēja ir piemērota, ja jums ir jārisina dažādas operētājsistēmas. Piemēram, izveidosim resursu, kas apraksta failu sshd_config:
fails (sshdconfig:
nosaukums => $operētājsistēma? (
solaris => "/usr/local/etc/ssh/sshd_config",
noklusējuma => "/etc/ssh/sshd_config"
Šajā piemērā mēs esam izvēles priekšā. Solaris fails ir norādīts atsevišķi, visiem pārējiem tiks atlasīts fails /etc/ssh/sshd_config. Tagad šim resursam var piekļūt kā sshdconfig, atkarībā no operētājsistēmas tiks izvēlēts vēlamais ceļš. Piemēram, mēs norādām, ka, ja darbojas sshd dēmons un tiek saņemts jauns fails, pakalpojums ir jārestartē.
nodrošināt => taisnība,
abonēt => Fails
Strādājot ar lietotāja datiem, bieži tiek izmantoti mainīgie. Piemēram, mēs aprakstām lietotāja mājas direktoriju atrašanās vietu:
$homeroot = "/home"
Tagad lietotāja specifiskiem failiem var piekļūt kā
$(homeroot)/$name
Parametrs $name tiks aizstāts ar lietotāja konta nosaukumu. Dažos gadījumos ir ērti definēt kāda veida noklusējuma vērtību. Piemēram, exec tipam bieži tiek norādīti direktoriji, kuros jāmeklē izpildāmais fails:
Exec (ceļš => "/usr/bin:/bin:/usr/sbin:/sbin")
Ja jums jānorāda uz vairākiem ligzdotiem failiem un direktorijiem, varat izmantot atkārtošanas parametru.
fails ("/etc/apache2/conf.d":
avots => "puppet://puppet://server.domain.com/config/apache/conf.d",
atkārtojums => "patiess"
Vairākus resursus var grupēt klasēs vai definīcijās. Klases ir pilnīgs sistēmas vai pakalpojuma apraksts un tiek izmantotas atsevišķi.
"/etc/passwd": īpašnieks => sakne, grupa => sakne, režīms => 644;
"/etc/shadow": īpašnieks => sakne, grupa => sakne, režīms => 440
Tāpat kā objektorientētās valodās, klases var definēt no jauna. Piemēram, FreeBSD grupa, kurai pieder šie faili, ir ritenis. Tāpēc, lai resurss netiktu pilnībā pārrakstīts, izveidosim jaunu freebsd klasi, kas pārmantos linux klasi:
klase freebsd manto Linux (
Fails["/etc/passwd"] ( grupa => ritenis );
Fails["/etc/shadow"] ( grupa => ritenis )
Ērtības labad visas klases var ievietot atsevišķā failā, kuru var savienot ar iekļaut direktīvu. Definīcijas var izmantot vairākus parametrus kā argumentus, taču tās neatbalsta pārmantošanu un tiek izmantotas, ja nepieciešams aprakstīt atkārtoti lietojamus objektus. Piemēram, definēsim lietotāja mājas direktoriju un komandas, kas nepieciešamas, lai izveidotu jaunu kontu.
definēt user_homedir ($group, $fullname, $ingroups) (
lietotājs("$nosaukums":
nodrošināt => klāt,
komentārs => "$fullname",
gid => "$grupa",
grupas => $grupas,
dalība => minimums,
apvalks => "/bin/bash",
mājas => "/mājas/$nosaukums",
prasīt => grupa[$grupa],
exec("$name homedir":
komanda => "/bin/cp -R /etc/skel /home/$nosaukums; /bin/chown -R $nosaukums:$grupa /mājas/$nosaukums",
rada => "/home/$name",
prasīt => Lietotājs[$vārds],
Tagad, lai izveidotu jaunu konts vienkārši skatiet user_homedir.
user_homedir("sergej":
grupa => "Sergejs",
pilns vārds => "Sergejs Jaremčuks",
ingroups => ["media", "admin]
Atsevišķi ir apraksti mezgliem (mezgliem), kas atbalsta mantošanu, piemēram, klases. Kad klients izveido savienojumu ar Puppet serveri, tas meklēs atbilstošo mezgla sadaļu un atgriezīs iestatījumus, kas ir raksturīgi tikai šim datoram. Varat izmantot mezgla noklusējumu, lai aprakstītu visas pārējās sistēmas. Visu veidu apraksts ir dots dokumentā “Tipa atsauce”, kuru vajadzētu izlasīt jebkurā gadījumā, vismaz, lai saprastu visas Leļļu valodas iespējas. Dažādi veidiļauj izpildīt noteiktas komandas, tostarp, ja ir izpildīti noteikti nosacījumi (piemēram, mainīt konfigurācijas failu), strādāt ar cron, lietotāja akreditācijas datiem un grupām, datoriem, montēt resursus, sākt un apturēt pakalpojumus, instalēt, atjaunināt un noņemt pakotnes, strādāt ar SSH atslēgas, Solaris zonas un tā tālāk. Tas ir tik vienkārši, ka izplatījumos esošo pakotņu sarakstu, izmantojot apt, var atjaunināt katru dienu no pulksten 2 līdz 4.
grafiks (katru dienu:
periods => katru dienu,
diapazons =>
exec ("/usr/bin/apt-get update":
grafiks => katru dienu
Atjaunināšanu par šo periodu katra sistēma veiks tikai vienu reizi, pēc tam uzdevums tiek uzskatīts par pabeigtu un tiks dzēsts no klienta datora. Leļļu valoda atbalsta citas pazīstamas struktūras: nosacījumus, funkcijas, masīvus, komentārus un tamlīdzīgus.
Leļļu uzstādīšana
Puppet nepieciešama Ruby (>= 1.8.1) ar OpenSSL atbalstu un XMLRPC bibliotēkām, kā arī Faster bibliotēka [ http://reductivelabs.com/projects/facter]. Ubuntu 7.04 repozitorijā, kas tika izmantota testa instalācijā, jau ir iekļauta kucēna pakotne.
$ sudo apt-cache meklēšanas lelle
marionete - centralizēta konfigurācijas pārvaldība tīkliem
puppetmaster - centralizēts konfigurācijas pārvaldības kontroles dēmons
Instalēšana instalēs visas nepieciešamās pakotņu atkarības: facter libopenssl-ruby libxmlrpc-ruby.
$ sudo apt-get instalēt puppet puppetmaster
Ruby bibliotēku pieejamību var pārbaudīt ar komandu.
$ rubīns -ropenssl -e "puts:yep"
~$ rubīns -rxmlrpc/client -e "puts:yep"
Ja kļūdas netiek saņemtas, tad viss nepieciešamais jau ir iekļauts. Failus, kas apraksta vēlamo sistēmu konfigurāciju Puppet terminoloģijā, sauc par manifestiem (manifestiem). Palaižot, dēmons mēģina nolasīt /etc/puppet/manifests/site.pp failu, ja tā trūkst, tas izdod brīdinājuma ziņojumu. Pārbaudot, varat likt dēmonam strādāt bezsaistes režīmā, kurā manifests nav nepieciešams
$ sudo /usr/bin/puppetmasterd --nonodes
Ja nepieciešams, vietnē site.pp var iekļaut citus failus, piemēram, ar klašu aprakstiem. Lai veiktu testa darbību, šim failam varat pievienot vienkāršāko instrukciju.
fails ("/etc/sudoers":
īpašnieks => sakne,
grupa => sakne,
Visi servera un klientu konfigurācijas faili atrodas mapē /etc/puppet. Fails fileserver.conf, par kuru mēs runājām iepriekš, nav obligāts un tiek izmantots tikai tad, ja Puppet darbosies arī kā failu serveris. Uz Ubuntu šis fails eksportē apakšdirektoriju /etc/puppet/files. SSL apakšdirektorijā ir sertifikāti un atslēgas, kas tiks izmantotas klientu savienojumu šifrēšanai. Atslēgas tiek ģenerētas automātiski, kad pirmo reizi palaižat puppetmasterd, jūs varat tos izveidot manuāli, izmantojot komandu.
$ sudo /usr/bin/puppetmasterd --mkusers.
Faili puppetd.conf un puppetmasterd.conf ir līdzīgi. Tie norāda dažus dēmonu parametrus klienta sistēmā un serverī. Klienta fails atšķiras tikai ar servera parametra klātbūtni, kas norāda uz datoru, kurā darbojas puppetmasterd.
serveris=grinder.com
logdir = /var/log/puppet
vardir=/var/lib/puppet
rundir = /var/run
# nosūtīt ziņojumu serverim
Tā vietā, lai visu rakstītu ar roku, varat izveidot veidni, izmantojot pašu funkciju puppetd.
$ puppetd --genconfig > /etc/puppet/puppetd.conf
Tāpat serverī varat izveidot vietni.pp.
$ puppetd --genmanifest > /etc/puppet/manifests/site.pp
Cits fails tagmail.conf ļauj norādīt e-pasta adreses, uz kurām tiks nosūtīti pārskati. Vienkāršākajā gadījumā var izmantot vienu līniju.
visi: [aizsargāts ar e-pastu]
Ar konfigurācijas failiem nepietiek, lai klients varētu izveidot savienojumu ar serveri. Lai to izdarītu, jums joprojām ir jāparaksta sertifikāti. Pirmkārt, lai serveris uzzinātu par jauno datoru klienta sistēmā, ievadiet komandu:
$ sudo puppetd --serveris grinder.com --waitforcert 60 --test
info: Pieprasīt sertifikātu
brīdinājums: vienādranga sertifikāts netiks pārbaudīts šajā SSL sesijā
paziņojums: nesaņēmu sertifikātu
Ja tiek atgriezta cita virkne, serveris ir jāpārbauda.
$ ps aux | grep marionete
marionete 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd
Ugunsmūrim ir jāatļauj savienojumi 8140. portā.
Serverī tiek parādīts saraksts ar sertifikātiem, kas jāparaksta.
$ sudo puppetca --list
nomad.grinder.com
Un mēs parakstām klienta sertifikātu.
$ sudo puppetca --sign nomad.grinder.com
Tagad klients var brīvi izveidot savienojumu ar serveri un saņemt iestatījumus.
Diemžēl raksta ietvaros vienkārši nav iespējams parādīt visas Leļļu iespējas. Bet, kā redzat, šis ir funkcionāls un elastīgs rīks, kas ļauj atrisināt lielāko daļu uzdevumu, vienlaikus administrējot lielu skaitu sistēmu. Ja jums ir jāizveido vairākas sistēmas atbilstoši jūsu darba veidam. Un pats galvenais, projektam izdevās pulcēt nelielu, bet pastāvīgi augošu kopienu. Tāpēc cerēsim, ka labai idejai netiks ļauts nomirt vai aiziet uz sāniem.
Lelle ir starpplatformu struktūra, kas ļauj sistēmas administratori veikt parastos uzdevumus, izmantojot kodu. Kods ļauj veikt dažādus uzdevumus, sākot no jaunu programmu instalēšanas līdz failu atļauju pārbaudei vai lietotāju kontu atjaunināšanai. Lelle teicami ne tikai sistēmas sākotnējās uzstādīšanas laikā, bet visā sistēmas dzīves ciklā. Vairumā gadījumu marionete izmanto klienta/servera konfigurācijā.
Šajā sadaļā ir parādīta instalēšana un konfigurācija Lelle klienta/servera konfigurācijā. Šis vienkāršais piemērs parāda, kā instalēt Apache izmantojot Lelle.
Uzstādīšana
Uzstādīšanai Lelle ierakstiet terminālī:
sudo apt-get install puppetmaster
Klienta mašīnā (vai iekārtās) ievadiet:
sudo apt-get install marionet
Iestatījums
Pirms marionetes iestatīšanas, iespējams, vēlēsities pievienot ierakstu DNS CNAME Priekš marionete.example.com, Kur example.com ir jūsu domēns. Noklusējuma klienti Lelle pārbaudiet DNS vietnei puppet.example.com kā leļļu servera nosaukumu ( Leļļu meistars). Papildinformāciju par DNS izmantošanu skatiet sadaļā Domēna vārdu pakalpojums.
Ja neplānojat izmantot DNS, varat pievienot ierakstus failam /etc/hosts serverī un klientā. Piemēram, failā /etc/hosts Lelle servera pievienošana:
127.0.0.1 localhost.localdomain localhost marionet 192.168.1.17 meercat02.example.com meercat02
Uz katra Lelle klientam pievienojiet ierakstu serverim:
192.168.1.16 meercat.example.com meercat marionet
Mainiet IP adreses un domēna vārdi no piemēra līdz jūsu faktiskajām adresēm un servera un klientu nosaukumiem.
Tagad iestatīsim dažus resursus apache2. Izveidojiet failu /etc/puppet/manifests/site.pp, kurā ir:
Package ( "apache2": nodrošināt => instalēts) pakalpojums ( "apache2": nodrošināt => true, enable => true, prasīt => pakotne["apache2"])
Mezgls "meercat02.example.com" (ietver apache2)
Aizvietot meercat02.example.com uz savu pašreizējo vārdu Lelle klients.
Pēdējais solis šim vienkāršajam Lelle serverim ir jārestartē pakalpojums:
sudo /etc/init.d/puppetmaster restart
Tagad tālāk Lelle serveris ir iestatīts, un ir pienācis laiks iestatīt klientu.
Vispirms iestatīsim pakalpojumu Lelle aģents palaist. Rediģējiet /etc/default/puppet un mainiet vērtību SĀKT ieslēgts Jā:
sudo /etc/init.d/puppet start
Atpakaļ uz Lelle serveri, lai parakstītu klienta sertifikātu, izmantojot komandu:
Sudo puppetca — parakstīt meercat02.example.com
Pārbaudiet /var/log/syslog par jebkādām konfigurācijas kļūdām. Ja viss noritēja labi, paka apache2 un tā atkarības tiks instalētas Lelle klients.
Šis piemērs ir ļoti vienkāršs un nerāda daudzas funkcijas un priekšrocības. Lelle. Priekš Papildus informācija skat
Sergejs Jaremčuks
Centralizēta UNIX sistēmu konfigurācija ar Puppet
Pārvaldīt lielu skaitu UNIX sistēmu nav ērti. Lai mainītu vienu parametru, administratoram ir jāpiekļūst katrai mašīnai, skripti var palīdzēt tikai daļēji, un ne visās situācijās.
Jāatzīst, ka Windows tīkla administratori galu galā atrodas labākā situācijā. Pietiek nomainīt grupas politikas iestatījumus, un pēc kāda laika visi tīklā esošie datori, arī tie, kuriem ir nesen instalēta operētājsistēma, “uzzinās” par jauninājumu, ja tie, protams, uz tiem attiecas. Atskatoties uz UNIX ilgo vēsturi, nekas tāds nekad nav izdevies. Ir tādi risinājumi kā kickstart, kas palīdz sākotnējā operētājsistēmas instalācijā, taču turpmāka precizēšana prasīs ievērojamas pūles. Komerciālie risinājumi, piemēram, BladeLogic un OpsWare, tikai daļēji atrisina iestatījumu automatizācijas problēmu, to galvenā priekšrocība ir grafiskā interfeisa klātbūtne, un tikai lielas organizācijas var atļauties tos iegādāties. Protams, ir projekti, kas piedāvā bezmaksas risinājumus, taču visu pastāvēšanas laiku tie nav spējuši izveidot lielu kopienu. Piemēram, Cfengine nav īpaši populārs administratoru vidū, lai gan, papildus Linux, to var izmantot *BSD, Windows un Mac OS X. Iespējams, tas ir saistīts ar relatīvo sarežģītību konfigurāciju veidošanā. Aprakstot uzdevumus, jāņem vērā katras konkrētās sistēmas īpatnības un manuāli jākontrolē darbību secība, izpildot komandas. Tas ir, administratoram jāatceras, ka dažām sistēmām jāraksta adduser citām - useradd, jāņem vērā failu atrašanās vieta dažādās sistēmās utt. Tas par lielumu sarežģī komandu rakstīšanas procesu, ir ļoti grūti izveidot pareizo konfigurāciju, atrodoties ceļā, un pēc kāda laika ir gandrīz neiespējami nolasīt izveidotās konfigurācijas. Neskatoties uz GPL licenci, Cfengine patiesībā ir viena cilvēka projekts, kurš kontrolē visas izmaiņas un nav īpaši ieinteresēts atvērtas sabiedrības veidošanā. Rezultātā Cfengine iespējas pilnībā apmierina izstrādātāju, un citiem administratoriem tas vairāk sagādā papildu galvassāpes. Lai uzlabotu Cfengine, trešo pušu izstrādātāji radīja dažādus papildinājumus, kas bieži vien tikai pasliktināja situāciju. Vairāku šādu Cfengine moduļu autors Lūks Kanijs beidzot nolēma izstrādāt līdzīgu rīku, taču tam nebija daudz Cfengine trūkumu.
Leļļu funkcijas
Puppet, tāpat kā Cfengine, ir klienta-servera sistēma, kas izmanto deklaratīvu, t.i., obligātu valodu, lai aprakstītu uzdevumus un bibliotēkas, lai tos īstenotu. Klienti periodiski (pēc noklusējuma ik pēc 30 minūtēm) izveido savienojumu ar centrālo serveri un saņem jaunāko konfigurāciju. Ja saņemtie iestatījumi neatbilst sistēmas stāvoklim, tie tiks izpildīti, nepieciešamības gadījumā serverim tiek nosūtīta atskaite par veiktajām darbībām. Ziņojumu serveris var saglabāt syslog vai failā, izveidot RRD grafiku, nosūtīt to uz norādīto e-pastu. Papildu abstrakcijas slāņi Transaction un Resource nodrošina maksimālu savietojamību ar esošajiem iestatījumiem un lietojumprogrammām, ļaujot koncentrēties uz sistēmas objektiem, neuztraucoties par atšķirībām ieviešanā un detalizēto komandu un failu formātu aprakstos. Administrators darbojas tikai ar objekta tipu, par pārējo rūpējas Lelle. Tātad pakotņu tips zina apmēram 17 pakotņu sistēmas, nepieciešamā tiks automātiski atpazīta, pamatojoties uz informāciju par izplatīšanas komplekta vai sistēmas versiju, lai gan nepieciešamības gadījumā pakotņu pārvaldnieku var piespiest.
Atšķirībā no skriptiem, kurus bieži nevar izmantot citās sistēmās, trešo pušu administratoru rakstītās leļļu konfigurācijas lielākoties bez problēmām darbosies jebkurā citā tīklā. Leļļu pavārgrāmatā jau ir trīs desmiti gatavu recepšu. Puppet pašlaik oficiāli atbalsta šādas operētājsistēmas un pakalpojumus: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo un MySQL, LDAP.
Leļļu valoda
Lai iet tālāk, vispirms ir jāsaprot valodas pamatelementi un iezīmes. Valoda ir viena no Lelles stiprajām pusēm. Tajā ir aprakstīti resursi, kurus administrators plāno pārvaldīt, un darbības, kas jāveic. Atšķirībā no vairuma līdzīgu risinājumu, programmā Puppet valoda ļauj viegli piekļūt visiem līdzīgiem resursiem jebkurā sistēmā neviendabīgā vidē. Resursa apraksts parasti sastāv no nosaukuma, veida un atribūtiem. Piemēram, norādiet uz /etc/passwd failu un iestatiet tā atribūtus:
fails ("/etc/passwd":
Īpašnieks => sakne,
grupa => sakne,
režīms => 644,
Klienti, kas izveido savienojumu ar serveri, tagad kopēs /etc/passwd failu un iestatīs norādītos atribūtus. Vienā noteikumā varat definēt vairākus resursus vienlaikus, atdalot tos ar semikolu. Bet ko darīt, ja serverī izmantotais konfigurācijas fails atšķiras no klienta failiem vai netiek izmantots vispār? Piemēram, šī situācija var rasties, iestatot VPN savienojumus. Šādā gadījumā jānorāda uz failu ar avota direktīvu. Šeit ir divas iespējas, jūs, kā parasti, varat norādīt ceļu uz citu failu, kā arī izmantot divus atbalstītos URI protokolus: failu un marioneti. Pirmajā gadījumā tiek izmantota saite uz ārēju NFS serveri, otrajā gadījumā uz Puppet servera tiek palaists NFS līdzīgs pakalpojums, kas eksportē resursus. Pēdējā gadījumā noklusējuma ceļš ir saistīts ar leļļu saknes direktoriju - /etc/puppet. Tas nozīmē, ka saite puppet://server.domain.com/config/sshd_config atbilst failam /etc/puppet/config/sshd_config. Šo direktoriju var ignorēt ar direktīvu filebucket, lai gan pareizāk ir izmantot tāda paša nosaukuma sadaļu /etc/puppet/fileserver.conf failā. Šajā gadījumā jūs varat ierobežot piekļuvi pakalpojumam tikai noteiktām adresēm. Piemēram, aprakstīsim konfigurācijas sadaļu:
Ceļš /var/puppet/config
Atļaut *.domain.com
Atļaut 127.0.0.1
Atļaut 192.168.0.*
Atļaut 192.168.1.0/24
Aizliegt *.wireless.domain.com
Un tad mēs atsaucamies uz šo sadaļu, aprakstot resursu:
avots => "puppet://server.domain.com/config/sshd_config"
Pirms kola ir resursa nosaukums. Vienkāršākajos gadījumos kā nosaukumu varat vienkārši norādīt pilnu ceļu uz failu. Sarežģītākās konfigurācijās labāk izmantot aizstājvārdu vai mainīgos. Pseidonīms tiek iestatīts, izmantojot aizstājvārda direktīvu:
fails ("/etc/passwd":
Alias => passwd
Vēl viena aizstājvārda izveides iespēja darbojas labi, ja jums ir jārisina dažādas operētājsistēmas. Piemēram, izveidosim resursu, kas apraksta failu sshd_config:
fails (sshdconfig:
Vārds => $operētājsistēma? (
Solaris => "/usr/local/etc/ssh/sshd_config",
Noklusējums => "/etc/ssh/sshd_config"
Šajā piemērā mēs esam izvēles priekšā. Solaris fails ir norādīts atsevišķi, visiem pārējiem tiks atlasīts fails /etc/ssh/sshd_config. Tagad šim resursam var piekļūt kā sshdconfig, atkarībā no operētājsistēmas tiks izvēlēts vēlamais ceļš. Piemēram, mēs norādām, ka, ja darbojas sshd dēmons un tiek saņemts jauns fails, pakalpojums ir jārestartē:
pakalpojums (sshd:
nodrošināt => taisnība,
Abonēt => Fails
Strādājot ar lietotāja datiem, bieži tiek izmantoti mainīgie. Piemēram, mēs aprakstām lietotāja mājas direktoriju atrašanās vietu:
$homeroot = "/home"
Tagad lietotāja specifiskiem failiem var piekļūt kā:
$(homeroot)/$name
Parametrs $name tiks aizstāts ar lietotāja konta nosaukumu. Dažos gadījumos ir ērti definēt kāda veida noklusējuma vērtību. Piemēram, ļoti bieži exec tips norāda direktorijus, kuros tam jāmeklē izpildāmais fails:
Exec (ceļš => "/usr/bin:/bin:/usr/sbin:/sbin")
Ja jums jānorāda uz vairākiem ligzdotiem failiem un direktorijiem, varat izmantot atkārtošanas parametru:
fails ("/etc/apache2/conf.d":
Avots => "puppet://puppet://server.domain.com/config/apache/conf.d",
Atkārtot => "patiess"
Vairākus resursus var apvienot klasēs vai definīcijās. Klases ir pilnīgs sistēmas vai pakalpojuma apraksts un tiek izmantotas atsevišķi:
klases linux (
Fails(
"/etc/passwd": īpašnieks => sakne, grupa => sakne, režīms => 644;
"/etc/shadow": īpašnieks => sakne, grupa => sakne, režīms => 440
Tāpat kā objektorientētās valodās, klases var definēt no jauna. Piemēram, FreeBSD grupa, kurai pieder šie faili, ir ritenis. Tāpēc, lai resurss netiktu pilnībā pārrakstīts, izveidosim jaunu freebsd klasi, kas pārmantos linux klasi:
klase freebsd manto Linux (
Fails["/etc/passwd"] ( grupa => ritenis );
Fails["/etc/shadow"] ( grupa => ritenis )
Ērtības labad visas klases var ievietot atsevišķā failā, kas jāiekļauj iekļautajā direktīvā. Definīcijas var izmantot vairākus parametrus kā argumentus, taču tās neatbalsta pārmantošanu un tiek izmantotas, ja vēlaties aprakstīt atkārtoti lietojamus objektus. Piemēram, definēsim lietotāja mājas direktoriju un komandas, kas nepieciešamas, lai izveidotu jaunu kontu:
definēt user_homedir ($group, $fullname, $ingroups) (
lietotājs("$nosaukums":
nodrošināt => klāt,
Komentārs => "$fullname",
gid => "$grupa",
Grupas => $ingroups,
Dalība => minimums,
Shell => "/bin/bash",
Sākums => "/mājas/$nosaukums",
Prasība => Grupa[$grupa],
Exec("$name homedir":
Komanda => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $nosaukums:$grupa /home/$nosaukums",
Izveido => "/home/$name",
Pieprasīt => Lietotājs[$vārds],
Tagad, lai izveidotu jaunu kontu, vienkārši skatiet user_homedir:
user_homedir("sergej":
Grupa => "Sergej",
Pilns vārds => "Sergejs Jaremčuks",
Ingroups => ["media", "admin]
Atsevišķi ir apraksti mezgliem (mezgliem), kas atbalsta pārmantošanu, piemēram, klases. Kad klients izveido savienojumu ar Puppet serveri, tas meklēs atbilstošo mezgla sadaļu un atgriezīs iestatījumus, kas ir raksturīgi tikai šai iekārtai. Varat izmantot mezgla noklusējumu, lai aprakstītu visas pārējās sistēmas. Visu veidu apraksts ir sniegts Type Reference dokumentā, kuru vajadzētu izlasīt jebkurā gadījumā, vismaz lai saprastu visas Leļļu valodas iezīmes. Dažādi veidi ļauj izpildīt noteiktas komandas, tostarp, ja ir izpildīti noteikti nosacījumi (piemēram, mainīt konfigurācijas failu), strādāt ar cron, lietotāja akreditācijas datiem un grupām, datoriem, mount resursus, sākt un apturēt pakalpojumus, instalēt, atjaunināt un noņemt pakotnes, strādāt ar SSH atslēgām, Solaris zonām utt. Tādā veidā jūs varat viegli atjaunināt pakotņu sarakstu izplatījumos, izmantojot apt, lai tas tiktu atjaunināts katru dienu no pulksten 2 līdz 4:
grafiks (katru dienu:
Periods => katru dienu,
diapazons =>
exec ("/usr/bin/apt-get update":
Grafiks => katru dienu
Atjaunināšanu par šo periodu katra sistēma veiks tikai vienu reizi, pēc tam uzdevums tiek uzskatīts par pabeigtu un tiks dzēsts no klienta datora. Leļļu valoda atbalsta citas pazīstamas struktūras: nosacījumus, funkcijas, masīvus, komentārus un tamlīdzīgus.
Leļļu uzstādīšana
Puppet nepieciešama Ruby (versija 1.8.1 un jaunāka) ar OpenSSL atbalstu un XMLRPC bibliotēkām, kā arī Faster bibliotēka. Ubuntu 7.04 repozitorijā, kas tika izmantota testa instalācijā, jau ir iekļauta kucēna pakotne:
$ sudo apt-cache meklēšanas lelle
~$ rubīns -rxmlrpc/client -e "puts:yep"
| jā |
Ja kļūdas netiek saņemtas, tad viss nepieciešamais jau ir iekļauts. Failus, kas apraksta vēlamo sistēmu konfigurāciju, Puppet terminoloģijā sauc par manifestiem. Palaižot, dēmons mēģina nolasīt /etc/puppet/manifests/site.pp failu, ja tā trūkst, tas izdod brīdinājuma ziņojumu. Pārbaudot, varat likt dēmonam darboties bezsaistes režīmā, kam nav nepieciešams manifests:
$ sudo /usr/bin/puppetmasterd --nonodes
Ja nepieciešams, vietnē site.pp var iekļaut citus failus, piemēram, ar klašu aprakstiem. Lai veiktu testa darbību, šim failam varat pievienot vienkāršāko instrukciju.
klases sudo (
Fails ("/etc/sudoers":
Īpašnieks => sakne,
grupa => sakne,
režīms => 440,
node default (
Iekļauts sudo
Visi konfigurācijas faili, gan servera, gan klienta, atrodas mapē /etc/puppet. Fails fileserver.conf, par kuru mēs jau runājām, nav obligāts un tiek izmantots tikai tad, ja Puppet darbosies arī kā failu serveris. Uz Ubuntu šis fails eksportē apakšdirektoriju /etc/puppet/files. SSL apakšdirektorijā ir sertifikāti un atslēgas, kas tiks izmantotas klientu savienojumu šifrēšanai. Atslēgas tiek ģenerētas automātiski, kad pirmo reizi palaižat puppetmasterd, tās var izveidot manuāli, izmantojot komandu:
$ sudo /usr/bin/puppetmasterd --mkusers
Faili puppetd.conf un puppetmasterd.conf ir līdzīgi. Tie norāda dažus parametrus dēmonu darbībai klienta sistēmā un serverī. Klienta fails atšķiras tikai ar servera parametra klātbūtni, kas norāda uz datoru, kurā darbojas puppetmasterd:
serveris=grinder.com
logdir = /var/log/puppet
vardir=/var/lib/puppet
rundir = /var/run
# nosūtīt ziņojumu serverim
report=true
Tā vietā, lai visu rakstītu ar roku, varat izveidot veidni, izmantojot pašu funkciju puppetd:
$ puppetd --genconfig > /etc/puppet/puppetd.conf
Līdzīgi varat izveidot vietni site.pp serverī:
$ puppetd --genmanifest > /etc/puppet/manifests/site.pp
Cits fails tagmail.conf ļauj norādīt e-pasta adreses, uz kurām tiks nosūtīti pārskati. Vienkāršākajā gadījumā var izmantot vienu rindu:
visi: [aizsargāts ar e-pastu]
Ar konfigurācijas failiem nepietiek, lai klients varētu izveidot savienojumu ar serveri. Lai to izdarītu, jums joprojām ir jāparaksta sertifikāti.
Pirmkārt, lai serveris uzzinātu par jauno datoru, klienta sistēmā ievadiet komandu:
$ sudo puppetd --serveris grinder.com --waitforcert 60 --test
Ugunsmūrim ir jāatļauj savienojumi 8140. portā.
Serverī tiek parādīts saraksts ar sertifikātiem, kas jāparaksta:
$ sudo puppetca --list
| nomad.grinder.com |
Un parakstiet klienta sertifikātu:
$ sudo puppetca --sign nomad.grinder.com
Tagad klients var brīvi izveidot savienojumu ar serveri un saņemt iestatījumus.
Diemžēl visas Lelles iespējas nav iespējams parādīt raksta robežās. Bet, kā redzat, šis ir funkcionāls un elastīgs rīks, kas ļauj atrisināt lielāko daļu uzdevumu, vienlaikus administrējot lielu skaitu sistēmu. Un pats galvenais, projektam izdevās pulcēt nelielu, bet pastāvīgi augošu kopienu. Tāpēc cerēsim, ka labai idejai netiks ļauts nomirt vai aiziet uz sāniem.
Veiksmi!
- BladeLogic projekta vietne ir http://www.bladelogic.com.
- OpsWare projekta vietne ir http://www.opsware.com.
- Cfengine projekta vietne ir http://www.cfengine.org.
- Leļļu projekta vietne ir http://reductivelabs.com/projects/puppet.
- Leļļu pavārgrāmata — http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
- Ātrāka bibliotēka —
