mājas › Padoms › 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

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. Šī apmācība palīdzēs jums uzzināt, kā darbojas šie Puppet komponenti, iestatot LAMP steku Ubuntu 14.04 serverī.

Prasības

Leļļu uzstādīšana (saimnieks 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 galvenokārt 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, izdodiet komandu:

leļļu resurss -- veidi

Šajā rokasgrāmatā jūs uzzināsit vairāk par resursu veidiem.

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ā jebkurā parastajā programmēšanas valodā, klases ir atbildīgas par orķestrēšanas daļu organizēšanu un atkārtotu izmantošanu.

Klases definīcijā ir koda bloks, 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. Izmantojot klases deklarāciju, Puppet apstrādā savu kodu.

Klases deklarācija var būt parasta un pēc resursa veida.

Parasta klases deklarācija tiek pievienota kodam, izmantojot atslēgvārdu iekļaut.

iekļaut example_class

Kad klase ir deklarēta kā resursa veids, tā tiek deklarēta resursa formātā:

class("example_class":)

Šī deklarācija ļauj kodam pievienot klases parametrus, kas ignorē klases atribūtu noklusējuma vērtības. Piemēram:

mezgls "host2" (
klase ("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 ērti 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 steku 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 šādām darbībām:

instalējot apache2 pakotni.
palaižot apache2 pakalpojumu.
pakotnes uzstādīšana MySQL serveris, mysql-serveris.
sāk 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 lelles koda piemēri, ko var izmantot, lai panāktu šādu LAMP steka iestatīšanu.

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šais piemērs parādīs, 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, izmantojot komandu marionet apply (lai to izdarītu, nav nepieciešama galvenā un aģenta iestatīšana).

Šajā sadaļā jūs iemācīsities 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.

Manifesta izveide

Izveidojiet jaunu manifestu:

sudo vi /etc/puppet/manifests/lamp.pp

Pievienojiet tam šādu kodu, lai deklarētu nepieciešamos resursus.

# palaidiet komandu "apt-get update".
exec("apt-update": # resurss exec "apt-update"
komanda => "/usr/bin/apt-get update" # komanda, kuru š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
pakete ("mysql-serveris":
prasīt => Exec["apt-update"], # pieprasiet "apt-update", atkārtoti instalējot
nodrošināt => uzstādīts,
}
# sāciet mysql pakalpojumu
pakalpojums ("mysql":
nodrošināt => skriešanu,
}
# instalējiet php5 pakotni
pakotne ("php5":
prasīt => Izpildīt["apt-update"], # pieprasījums "apt-update" pirms instalēšanas
nodrošināt => uzstādīts,
}
# sāciet pakalpojumu info.php
fails ("/var/www/html/info.php":
nodrošināt => failu,
saturs => "", # phpinfo kods
prasīt => pakotne["apache2"], # pieprasījums pakotnei "apache2"
}

Manifesta piemērošana

Lai izmantotu jauno manifestu, ievadiet komandu:

sudo puppet pieteikties --tests

Tas parādīs apjomīgu rezultātu, kas parāda visas vides stāvokļa izmaiņas. 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 Apache un PHP darbojas.

Tagad LAMP kaudze ir instalēta 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, ko 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 konfigurēt galveno manifestu un izmantot lampas moduli, lai instalētu LAMP steku serverī.

Puppet master 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:

mezgla noklusējuma ( )
mezgls "lampa-1" (
}

Piezīme: nomainiet lampu-1 ar sava leļļu aģenta resursdatora nosaukumu, uz kura jāinstalē steks.

Mezglu bloks ļauj norādīt leļļu kodu, kas attieksies tikai uz dažiem 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 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 parametrus.

Pievienojiet resursu, kas kopēs info.php uz vēlamo 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"], # lietojamā apache klase
avots => "puppet:///modules/apache/info.php", # vieta, 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 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 Apache un PHP darbojas, 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 darbu ar Puppet 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: ,
Mazliet dzejas.Šķiet, ka šim rakstam vajadzētu būt sākumpunktam visai sērijai, taču mērķauditorija joprojām ir pieredzējušāki Open Source Puppet Labs 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”, cena, kas jāmaksā, ir ievērot integrētā risinājuma autora pasaules uzskatu.

Mazliet par to, kā darbojas Lelle

Lelle galvenokārt ir specifiska 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 ir iespējams līdz galam kļūt dīvaini.

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 dotie parametri, 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.

Puppet var izmantot vietējai izvietošanai bez tīkla vai saistītās infrastruktūras. To var izmantot, lai izveidotu konteinera attēlus. Ir pat vesela kustība, kas iestājas par atteikšanos no centralizēta servera.

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 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 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.
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.
Serveris sastāda resursu katalogu un nosūta to 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ā. Aģents pats nezina, ko darīt ar resursiem, tas paļaujas uz konkrētu resursu veidu nodrošinātāju (semantiskais tulkojums būs “ieviesējs, nevis piegādātājs”) ieviešanu. Daži nodrošinātāji ir standarta un ir iekļauti Puppet pakotnēs, savukārt pārējie tiek izvilkti no moduļiem.

Lai izbaudītu visus priekus, ir pieejamas papildu maizītes šādās formās:

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 iegūš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, izmantojot funkciju izsaukumu, Puppet iegūst noklusējuma klases parametrus, kas ir galvenais izcēlums.
- Protams, Hiera atbalsta faktu interpolāciju un pat speciālo funkciju izsaukšanu.
- Programmā Puppet 4.3 mēs atkal ieviesām to pašu funkcionalitāti, lai atbalstītu ne tikai globālo datubāzi, bet arī lokālo Videi un Modulim, lai gan autors jau ir atradis vairākas problēmas to ieviešanā (PUP-5983, PUP-5952 un PUP -5899), kuras uzreiz izlaboja 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 norādīt gan izsaucot funkciju lookup(), jo un jebkurā hierarhijas failā, izmantojot īpašo lookup_options atslēgu, 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 direktorijos citos mezglos vai atlasēs, 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 Cisco aprīkojuma veids un izvietošana uz tukša metāla, taču tas ir cits stāsts

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

Jums jāsaprot, ka Puppet Server kļūst par visas IT infrastruktūras neaizsargātu 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āla atjaunināšana un otrais 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ā jūsu 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)

Š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.
Modulis cfpuppetserver atbalsta instalācijas kā primāro (ar CA) un kā sekundāro serveri.

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

Ražotājam ir pilns apraksts.

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

Šis process ir diezgan primitīvs, taču tam ir jāievēro noteikta darbību secība. Tā kā to izdarīt manuāli ir nepateicīgs uzdevums, autors jums iemācīs kaut ko sliktu, proti, lejupielādēt no interneta nesaprotamus skriptus un palaist tos 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 neveiksmes punkts. PostgeSQL replikācijai un klasterēšanai ir dažādas pieejas Ē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

Aparatūru apraksta pats 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 repozitorijs var tikt mitināts tajā pašā sistēmā un tam var piekļūt, izmantojot failu:// . Laba vieta, kur sākt, ir codingfuture/puppet-exampleenv konfigurācijas piemērs.

Repozitorija klonēšana: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Mēs iestatām vispārīgus administratora piekļuves iestatījumus, izmantojot komentāros sniegtos padomus:
- $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 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
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

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 instalācijas 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) .
- Piemērs ar attālo repozitoriju: 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 redzam, kā sistēma uzpūšas un neinstalē visu ļoti ātri.
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
Mēs sākam manuāli izvietot konfigurāciju: /etc/puppetlabs/deploy.sh
Pamēģināsim, kā tas darbojas pašā serverī: /opt/puppetlabs/bin/puppet agent --test
Pārbaudiet tīkla iestatījumus, pārsprieguma aizsargs un SSH piekļuve

Pārvaldīto mezglu pievienošana

Puppet Server pilnībā kvalificētajam nosaukumam ir jābūt pieejamam pārvaldītajā resursdatorā, izmantojot DNS, vai tas ir jāiekodēts mapē /etc/hosts.
- Piemērs: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
Mezglā ar Puppet Server palaidiet šādu skriptu /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Kopējiet visu rezultātu un ielīmējiet to komandrinda mērķa sistēmā.
Mēs gaidām izpildes beigas un palaižam /opt/puppetlabs/bin/puppet agent --test . Pirmajā palaišanas reizē tiks ģenerēts sertifikāta parakstīšanas pieprasījums.
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.
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ā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 resursdatora 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

~# ./setup_puppetserver.sh Lietojums: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url — Git repozitorija URI
certname — resursdatora pilnībā kvalificēts domēna nosaukums
cflocation - fakta cf_location inicializācija
cflocationpool — fakta inicializācija cf_location_pool
http_proxy — starpniekserveris HTTP un HTTPS pieprasījumiem

Pilns Bash parametru saraksts Puppet klienta inicializācijas skriptam

~# /root/genclientinit.sh Lietojums: ./genclientinit.sh [ [ []]]
Parametru nozīme ir tāda pati kā iepriekšējā skriptā.

cfpuppetserver klase

deployuser = "deploypuppet" — lietotājvārds konfigurācijas atjauninājumu automātiskai izvietošanai
deployuser_auth_keys = undef — $deployuser atslēgu saraksts
repo_url = undef — repozitorija URI (piemērs: ssh://user@host/repo vai file:///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 kaujas vidē, izņemot varbūt 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

Liela skaita Unix sistēmu pārvaldību nevar saukt par ērtu. Lai mainītu vienu parametru, administratoram ir jāsazinās ar katru mašīnu; 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 ir izdevīgākā stāvoklī. Pietiek nomainīt grupas politikas iestatījumus un pēc kāda laika visi tīklā esošie datori, arī tie ar nesen instalētu operētājsistēmu, “uzzinās” par jauninājumu, ja tas, protams, uz tiem attiecas. Atskatoties uz ilgo Unix izstrādes periodu, jūs ievērosiet, ka 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 pilnveidoš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 pieejamība GUI, un tos var iegādāties tikai no lielām organizācijām. Protams, ir projekti, kas piedāvā bezmaksas risinājumus, taču visā to pastāvēšanas laikā tie nekad 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. Tas var būt saistīts ar relatīvo konfigurāciju izveides sarežģītību. 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 ir jāatceras, ka dažām sistēmām ir 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 lidojuma laikā, un izveidotās konfigurācijas pēc kāda laika ir gandrīz neiespējami nolasīt. 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 izstrādātāju ir diezgan apmierinošas, bet citiem administratoriem tās drīzā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 situāciju tikai pasliktināja. Vairāku šādu cfengine moduļu autors Lūks Kanijs galu galā nolēma izstrādāt līdzīgu rīku, taču bez daudziem cfengine trūkumiem.

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, un nepieciešamības gadījumā serverim tiks nosūtīta atskaite par veiktajām darbībām. Serveris var saglabāt ziņojumus syslog vai failā, izveidot RRD grafiku un nosūtīt tos uz noteiktu e-pastu. Papildu transakciju un resursu abstrakcijas slāņi 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 detalizētu komandu un failu formātu ieviešanā un aprakstā. Administrators darbojas tikai ar objekta tipu, par pārējo rūpējas Lelle. Tādējādi pakotņu tips zina apmēram 17 pakotņu sistēmas, vajadzīgā tiks automātiski atpazīta, pamatojoties uz informāciju par distribūcijas vai sistēmas versiju, lai gan, ja nepieciešams, pakotņu pārvaldnieku var piespiest.

Atšķirībā no skriptiem, kurus bieži vien nav iespējams izmantot citās sistēmās, trešo pušu administratoru rakstītās leļļu konfigurācijas lielākoties darbosies bez problēmām 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 virzītos uz priekšu, vispirms ir jāsaprot valodas pamatelementi un iespējas. 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, Puppet ļauj valodai vienkāršot piekļuvi 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ādīsim uz /etc/passwd failu un iestatīsim tā atribūtus:

fails ("/etc/passwd":

īpašnieks => sakne,

grupa => sakne,

Tagad klienti, izveidojuši savienojumu ar serveri, kopēs /etc/passwd failu un instalēs norādītos atribūtus. Vienā noteikumā varat definēt vairākus resursus, atdalot tos, izmantojot semikolu. Ko darīt, ja serverī izmantotais konfigurācijas fails atšķiras no klienta vai netiek izmantots vispār? Piemēram, šī situācija var rasties, iestatot VPN savienojumus. Šajā gadījumā failu var norādīt, izmantojot avota direktīvu. Šeit, kā parasti, ir divas iespējas, lai norādītu ceļu uz citu failu; tiek atbalstīti arī divi URI protokoli: fails un marionete. Pirmajā gadījumā tiek izmantota saite uz ārēju NFS serveri, otrajā variantā 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 atbildīs 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 pievēršamies šai sadaļai, 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 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 atlasī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āju mājas direktoriju atrašanās vietu:

$homeroot = "/home"

Tagad konkrēta lietotāja failiem var piekļūt kā

$(homeroot)/$name

Parametrs $name tiks aizpildī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 tie bieži norāda direktorijus, kuros jāmeklē izpildāmais fails:

Exec (ceļš => "/usr/bin:/bin:/usr/sbin:/sbin")

Ja 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 apvienot 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 ignorēt. Piemēram, FreeBSD šo failu grupas īpašnieks 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, izmantojot direktīvu iekļaut. 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āju 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 sazinieties ar user_homedir.

user_homedir("sergej":

grupa => "Sergejs",

pilns vārds => "Sergejs Jaremčuks",

ingroups => ["media", "admin]

Ir atsevišķi apraksti mezgliem, kas atbalsta mantošanu, piemēram, klases. Kad klients izveido savienojumu ar Puppet serveri, tiks meklēta atbilstošā mezgla sadaļa un tiks nodrošināti tikai šim datoram raksturīgi iestatījumi. Lai aprakstītu visas pārējās sistēmas, varat izmantot node default. Visu veidu apraksts ir dots dokumentā “Tipa atsauce”, kas jebkurā gadījumā ir jāizlasa, lai vismaz izprastu 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āžas resursiem, pakalpojumu palaišanu un apturēšanu, pakotņu instalēšanu, atjaunināšanu un noņemšanu, darbu ar SSH atslēgas, Solaris zonas un tā tālāk. Tas ir, cik vienkārši ir piespiest pakotņu sarakstu izplatījumos, izmantojot apt, atjaunināt katru dienu no 2 līdz 4 stundām.

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 instalēš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ēšanai, jau bija kucēna pakotne.

$ sudo apt-cache meklēšanas lelle

marionete — centralizēta tīklu konfigurācijas pārvaldība

puppetmaster - centralizēts konfigurācijas pārvaldības kontroles dēmons

Instalēšanas laikā tiks instalētas visas nepieciešamās atkarības pakotnes: 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. Palaižot, dēmons mēģina nolasīt failu /etc/puppet/manifests/site.pp; ja tā trūkst, tiek parādīts brīdinājuma ziņojums. Pārbaudot, varat likt dēmonam darboties bezsaistes režīmā, un tādā gadījumā manifests nav nepieciešams

$ sudo /usr/bin/puppetmasterd --nonodes

Ja nepieciešams, vietnei site.pp varat pievienot citus failus, piemēram, ar klašu aprakstiem. Lai veiktu testa darbību, šajā failā varat ievadīt vienkāršākos norādījumus.

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 šifrēšanai, savienojot klientus. Taustiņi tiek izveidoti automātiski, pirmo reizi palaižot puppetmasterd; 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 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

Lai nerakstītu visu manuāli, varat izveidot veidni, izmantojot pašu 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ā varat izmantot vienu līniju.

visi: [aizsargāts ar e-pastu]

Ar konfigurācijas failiem nepietiek, lai klients izveidotu savienojumu ar serveri. Lai to izdarītu, jums arī jāparaksta sertifikāti. Pirmkārt, lai ļautu serverim uzzināt par jauno datoru klienta sistēmā, ievadiet komandu:

$ sudo puppetd --serveris grinder.com --waitforcert 60 --test

info: Sertifikāta pieprasīšana

brīdinājums: vienādranga sertifikāts netiks pārbaudīts šajā SSL sesijā

paziņojums: nesaņēmu sertifikātu

Ja tiek atgriezta cita rinda, jums jāpārbauda servera darbība.

$ 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ī mēs saņemam sarakstu ar sertifikātiem, kas jāparaksta.

$ sudo puppetca --list

nomad.grinder.com

Un mēs parakstām klienta sertifikātu.

$ sudo puppetca — zīme nomad.grinder.com

Tagad klients var brīvi izveidot savienojumu ar serveri un saņemt iestatījumus.

Diemžēl rakstā vienkārši nav iespējams parādīt visas Puppet iespējas. Bet, kā redzat, šis ir funkcionāls un elastīgs rīks, kas ļauj atrisināt lielāko daļu problēmu, kas saistītas ar daudzu sistēmu vienlaicīgu administrēšanu. Ja jūsu darba jomā ir jāiestata vairākas sistēmas. Un pats galvenais, projektam izdevās pulcēt nelielu, bet pastāvīgi augošu kopienu. Tāpēc cerēsim, ka labai idejai neļaus nomirt vai aiziet malā.

Lelle ir starpplatformu struktūra, kas ļauj sistēmas administratori Veiciet 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 pārāks 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ēšana 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 ievadiet terminālī:

Sudo apt-get install puppetmaster

Klienta iekārtā(-ēs) ievadiet:

Sudo apt-get install marionet

Iestatījumi

Pirms marionetes iestatīšanas, iespējams, vēlēsities pievienot ierakstu DNS CNAME Priekš marionete.example.com, Kur example.com- tas 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ļā Domain Name Service.

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 katru Lelle Klientā pievienojiet ierakstu serverim:

192.168.1.16 meercat.example.com meercat marionet

Aizstāt IP adreses un domēna vārdi no piemēra līdz jūsu pašreizējām adresēm un servera un klientu nosaukumiem.

Tagad iestatīsim dažus resursus apache2. Izveidojiet failu /etc/puppet/manifests/site.pp kas satur sekojošo:

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 viss ir konfigurēts serverī, un ir pienācis laiks konfigurēt klientu.

Vispirms konfigurēsim pakalpojumu Lelle aģents palaišanai. Rediģējiet /etc/default/puppet, aizstājot vērtību SĀKT ieslēgts Jā:

Sudo /etc/init.d/puppet start

Atgriezīsimies pie 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 tajā nav parādītas daudzas funkcijas un priekšrocības. Lelle. Priekš Papildus informācija Skaties

Sergejs Jaremčuks

Centralizēta UNIX sistēmu konfigurēšana, izmantojot Puppet

Liela skaita UNIX sistēmu pārvaldību nevar saukt par ērtu. Lai mainītu vienu parametru, administratoram ir jāsazinās ar katru mašīnu; 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 ir izdevīgākā stāvoklī. 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 tas, protams, attiecas uz viņiem. Atskatoties uz ilgu UNIX izstrādes periodu, jūs varat redzēt, ka 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ākā attīstība 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 tos var atļauties iegādāties tikai lielas organizācijas. Protams, ir projekti, kas piedāvā bezmaksas risinājumus, taču visā to pastāvēšanas laikā 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. Tas var būt saistīts ar relatīvo konfigurāciju izveides sarežģītību. Aprakstot uzdevumus, ir jāņem vērā katras konkrētās sistēmas īpašības un manuāli jākontrolē darbību secība, izpildot komandas. Tas ir, administratoram jāatceras, ka dažām sistēmām ir 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 lidojuma laikā, un izveidotās konfigurācijas pēc kāda laika ir gandrīz neiespējami nolasīt. Neskatoties uz GPL licenci, Cfengine būtībā ir viena cilvēka projekts, kas kontrolē visas izmaiņas un nav īpaši ieinteresēts veidot atvērtu sabiedrību. Rezultātā Cfengine iespējas izstrādātāju ir diezgan apmierinošas, bet citiem administratoriem tās drīzā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 situāciju tikai pasliktināja. Vairāku šādu Cfengine moduļu autors Lūks Kanijs galu galā nolēma izstrādāt līdzīgu rīku, taču bez daudziem Cfengine trūkumiem.

Leļļu funkcijas

Puppet, tāpat kā Cfengine, ir klienta-servera sistēma, kas izmanto deklaratīvu valodu, lai aprakstītu uzdevumus un bibliotēkas to ieviešanai. 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, un nepieciešamības gadījumā serverim tiks nosūtīta atskaite par veiktajām darbībām. Ziņojumu serveris var to saglabāt syslog vai failā, izveidot RRD grafiku un nosūtīt to uz norādīto e-pastu. Papildu transakciju un resursu abstrakcijas slāņi 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ādējādi pakotņu tips zina apmēram 17 pakotņu sistēmas, nepieciešamā tiks automātiski atpazīta, pamatojoties uz informāciju par distribūcijas vai sistēmas versiju, lai gan, ja nepieciešams, pakotņu pārvaldnieku var iestatīt piespiedu kārtā.

Atšķirībā no skriptiem, kurus bieži nav iespējams izmantot citās sistēmās, trešo pušu administratoru rakstītās leļļu konfigurācijas lielākoties darbosies bez problēmām 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 virzītos uz priekšu, vispirms ir jāsaprot valodas pamatelementi un iespējas. Valoda ir viena no Lelles stiprajām pusēm. Tajā ir aprakstīti resursi, kurus administrators plāno pārvaldīt, un veiktās darbības. Atšķirībā no vairuma līdzīgu risinājumu, Puppet ļauj valodai vienkāršot piekļuvi 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ādīsim uz /etc/passwd failu un iestatīsim tā atribūtus:

fails ("/etc/passwd":

Īpašnieks => sakne,

Grupa => sakne,

režīms => 644,

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, atdalot tos, izmantojot 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ā jums jānorāda uz failu, izmantojot avota direktīvu. Šeit ir divas iespējas; jūs, kā parasti, varat norādīt ceļu uz citu failu, kā arī izmantojot divus atbalstītos URI protokolus: failu un marioneti. Pirmajā gadījumā tiek izmantota saite uz ārēju NFS serveri, otrajā variantā Puppet serverī 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 atbildīs 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 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 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:

Vārds => $operētājsistēma? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Noklusējums => "/etc/ssh/sshd_config"

pakalpojums (sshd:

Pārliecinieties, ka => 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āju mājas direktoriju atrašanās vietu:

$homeroot = "/home"

Tagad konkrēta lietotāja failiem var piekļūt kā:

$(homeroot)/$name

Parametrs $name tiks aizpildī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 ļoti bieži tiek norādīti direktoriji, kuros jāmeklē izpildāmais fails:

Exec ( ceļš => "/usr/bin:/bin:/usr/sbin:/sbin")

Ja 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

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, izmantojot direktīvu iekļaut. 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("$name":

Pārliecinieties => 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",

Prasīt => Lietotājs[$vārds],

Tagad, lai izveidotu jaunu kontu, vienkārši sazinieties ar user_homedir:

user_homedir("sergej":

Grupa => "Sergej",

Pilns vārds => "Sergejs Jaremčuks",

Ingroups => ["media", "admin]

Ir atsevišķi mezglu apraksti, kas atbalsta mantošanu, kā arī klases. Kad klients izveido savienojumu ar Puppet serveri, tiks meklēta atbilstošā mezgla sadaļa un tiks nodrošināti tikai šim datoram raksturīgi iestatījumi. Lai aprakstītu visas pārējās sistēmas, varat izmantot node default. Visu veidu apraksts ir dots dokumentā “Tipa atsauce”, kas jebkurā gadījumā ir jāizlasa, lai vismaz izprastu 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āžas resursiem, pakalpojumu palaišanu un apturēšanu, pakotņu instalēšanu, atjaunināšanu un noņemšanu. , strādājot ar SSH taustiņiem, Solaris zonām un tā tālāk. Tādā veidā jūs varat viegli piespiest pakešu sarakstu izplatījumos, izmantojot apt, atjaunināt katru dienu no 2 līdz 4 stundām:

grafiks (katru dienu:

Periods => katru dienu,

Diapazons =>

exec ("/usr/bin/apt-get update":

Grafiks => katru dienu

Leļļu instalēš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ēšanai, 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 failu /etc/puppet/manifests/site.pp; ja tā trūkst, tiek parādīts brīdinājuma ziņojums. Pārbaudot, varat likt dēmonam darboties savrupajā režīmā, kam nav nepieciešams manifests:

$ sudo /usr/bin/puppetmasterd --nonodes

Ja nepieciešams, vietnei site.pp var pievienot citus failus, piemēram, ar klašu aprakstiem. Lai veiktu testa darbību, šajā failā varat ievadīt vienkāršākos norādījumus.

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 šifrēšanai, savienojot klientus. Taustiņi tiek izveidoti automātiski, pirmo reizi palaižot puppetmasterd; varat tos izveidot manuāli, izmantojot komandu:

$ sudo /usr/bin/puppetmasterd --mkusers

serveris = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# nosūtīt ziņojumu serverim

ziņojums = patiess

Lai nerakstītu visu manuāli, varat izveidot veidni, izmantojot pašu 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ā varat izmantot vienu rindiņu:

visi: [aizsargāts ar e-pastu]

Ar konfigurācijas failiem nepietiek, lai klients izveidotu savienojumu ar serveri. Lai to izdarītu, jums arī jāparaksta sertifikāti.

Pirmkārt, lai ļautu serverim uzzināt 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 — zīme nomad.grinder.com

Tagad klients var brīvi izveidot savienojumu ar serveri un saņemt iestatījumus.

Diemžēl rakstā nav iespējams parādīt visas Puppet iespējas. Bet, kā redzat, tas ir funkcionāls un elastīgs rīks, kas ļauj atrisināt lielāko daļu problēmu, kas saistītas ar liela skaita sistēmu vienlaicīgu administrēšanu. Un pats galvenais, projektam izdevās pulcēt nelielu, bet pastāvīgi augošu kopienu. Tāpēc cerēsim, ka labai idejai neļaus nomirt vai aiziet malā.

Veiksmi!

BladeLogic projekta vietne – 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 -