Acasă › Sfat › Master of puppets: Instalarea și configurarea sistemului de gestionare a configurației de la distanță Puppet. Master of puppets: Instalarea și configurarea sistemului de gestionare a configurației la distanță Puppet. Instalarea puppet

Master of puppets: Instalarea și configurarea sistemului de gestionare a configurației de la distanță Puppet. Master of puppets: Instalarea și configurarea sistemului de gestionare a configurației la distanță Puppet. Instalarea puppet

Pentru a utiliza Puppet mai eficient, trebuie să înțelegeți cum sunt construite modulele și manifestele. Acest tutorial vă va ghida prin modul în care funcționează aceste componente Puppet prin configurarea unei stive LAMP pe un server Ubuntu 14.04.

Cerințe

Instalarea Puppet (master și agent). Mai multe despre asta -.
Posibilitatea de a crea cel puțin un server virtual Ubuntu 14.04 pentru a servi nodul agent Puppet.

Elementele de bază ale codului păpușilor

Resurse

Codul marionetelor constă în principal din resurse. O resursă este o bucată de cod care descrie starea sistemului și determină modificările de care are nevoie. De exemplu:

utilizator("mitchell":
asigura => prezent,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

Declarația de resurse are următorul format:

tip_resursa("nume_resursa"
atribut => valoare
...
}

Pentru a vizualiza toate tipurile de resurse Puppet, lansați comanda:

resurse de păpuși --tipuri

Veți afla mai multe despre tipurile de resurse în acest ghid.

Manifeste

Un manifest este un script de orchestrare. Programele marionete cu extensia .pp se numesc manifeste. Manifestul Puppet implicit este /etc/puppet/manifests/site.pp.

Clase

Ca în orice limbaj obișnuit de programare, clasele sunt responsabile pentru organizarea și reutilizarea părților orchestrației.

În definiția unei clase este un bloc de cod care descrie modul în care funcționează clasa. Odată ce definiți o clasă, o puteți utiliza în manifeste.

Definiția clasei are următorul format:

clasa exemplu_clasa(
...
cod
...
}

Acest cod definește clasa example_class. Codul Puppet va fi între acolade.

O declarație de clasă este locul din cod în care este apelată o anumită clasă. Cu o declarație de clasă, Puppet își procesează codul.

Declarația de clasă poate fi obișnuită și după tipul de resursă.

O declarație obișnuită de clasă este adăugată la cod folosind cuvântul cheie include.

include example_class

Când este declarată ca tip de resursă, clasa este declarată în format de resursă:

clasa("clasa_exemplu":)

Această declarație vă permite să adăugați parametri de clasă la codul dvs. care înlocuiesc valorile implicite ale atributelor de clasă. De exemplu:

nodul „gazdă2” (
clasă ("apache": ) # folosește modulul apache
apache::vhost ( "example.com": # definiți resursa vhost
port => "80",
docroot => "/var/www/html"
}
}

Module

Un modul este un grup de manifeste și alte fișiere organizate într-un mod predefinit, care facilitează partajarea și reutilizarea părților individuale ale orchestrației. Modulele ajută la organizarea codului Puppet, deoarece pot fi folosite pentru a separa codul în mai multe manifeste.

Modulele puppet sunt stocate în directorul /etc/puppet/modules.

Scrierea unui manifest

Puteți exersa scrierea manifestelor, modulelor și claselor Puppet folosind exemplul instalării unei stive LAMP pe un server Ubuntu (rezultatul va fi ).

Deci, pentru a orchestra un server Ubuntu 14.04 și a instala o stivă LAMP pe el, aveți nevoie de resurse pentru următoarele acțiuni:

instalarea pachetului apache2.
pornirea serviciului apache2.
instalarea pachetului Server MySQL, mysql-server.
pornind serviciul mysql.
instalarea pachetului php5
crearea unui script de testare PHP, info.php.
actualizarea indexului apt înainte de a instala fiecare pachet.

Mai jos veți găsi trei exemple de cod Puppet care pot fi folosite pentru a realiza o astfel de configurare a stivei LAMP.

Primul exemplu vă va învăța cum să scrieți manifeste de bază într-un singur fișier. Al doilea exemplu vă va ajuta să asamblați și să utilizați o clasă și un modul bazat pe manifeste scrise anterior. Al treilea exemplu vă va arăta cum să utilizați module publice pre-construite pentru a instala o stivă LAMP.

Notă: Pentru testare este mai bine să folosiți un server virtual proaspăt.

Exemplul 1: Instalarea LAMP cu un singur manifest

Manifestul Puppet poate fi scris pe nodul agent și apoi executat folosind comanda puppet apply (nu este nevoie să aveți o configurare master și agent pentru a face acest lucru).

În această secțiune, veți învăța să scrieți manifeste care vor folosi aceste tipuri de declarații de resurse:

exec: Executați comenzi.
pachet: instalați pachete.
serviciu: managementul serviciului.
fişier: managementul fişierelor.

Crearea unui manifest

Creați un manifest nou:

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

Adăugați următorul cod pentru a declara resursele necesare.

# rulați comanda „apt-get update”.
exec("apt-update": # resource exec "apt-update"
command => "/usr/bin/apt-get update" # comanda pe care o va rula această resursă
}
# instalați pachetul apache2
pachet("apache2":
require => Exec["apt-update"], # solicitați "apt-update" înainte de a instala pachetul
asigura => instalat,
}
# porniți serviciul apache2
service("apache2":
asigura => rulează,
}
# instalați mysql-server
pachet("mysql-server":
require => Exec["apt-update"], # solicitați "apt-update" prin reinstalare
asigura => instalat,
}
# porniți serviciul mysql
service("mysql":
asigura => rulează,
}
# instalați pachetul php5
pachet("php5":
require => Exec["apt-update"], # cereți "apt-update" înainte de instalare
asigura => instalat,
}
# porniți serviciul info.php
fisier("/var/www/html/info.php":
asigura => fișier,
continut => "", # cod phpinfo
require => Pachetul["apache2"], # cerere pentru pachetul "apache2"
}

Aplicarea unui manifest

Pentru a utiliza noul manifest, introduceți comanda:

sudo puppet apply --test

Acesta va afișa un rezultat voluminos care afișează toate schimbările în starea mediului. Dacă nu există erori în rezultat, ar trebui să puteți deschide adresa IP externă sau numele de domeniu în browser. Un test de testare va apărea pe ecran. pagina PHP cu informații despre stiva. Aceasta înseamnă că Apache și PHP funcționează.

Acum stiva LAMP este instalată pe server folosind Puppet.

Acesta este un manifest destul de simplu, deoarece poate fi executat pe un agent. Dacă nu aveți un maestru Puppet, alte noduri de agenți nu vor putea folosi acest manifest.

Serverul Puppet master verifică dacă starea serverului se modifică la fiecare 30 de minute.

Exemplul 2: Instalarea unei stive LAMP folosind un modul

Acum încercați să creați un modul simplu bazat pe manifestul LAMP pe care l-ați scris în secțiunea anterioară.

Pentru a crea un modul, creați un nou director în directorul modules (numele acestuia trebuie să corespundă cu numele modulului). Acest director ar trebui să conțină un director manifest și un fișier init.pp. Fișierul init.pp specifică clasa Puppet (numele acesteia trebuie să se potrivească și cu numele modulului).

Crearea unui Modul

Accesați serverul Puppet master și creați o structură de directoare pentru modul:

cd /etc/puppet/modules
sudo mkdir -p lamp/manifest

Creați și deschideți fișierul init.pp în editor:

sudo vi lamp/manifests/init.pp

Introduceți clasa lămpii în fișier:

lampă de clasă (
}

Copiați conținutul manifestului din secțiunea 1 și inserați-l în blocul clasei de lampă. Acum aveți o definiție a clasei de lampă. Alte manifeste vor putea folosi această clasă ca modul.

Salvați și închideți fișierul.

Folosind un modul în manifestul principal

Acum puteți configura manifestul principal și puteți utiliza modulul lampă pentru a instala stiva LAMP pe server.

Pe serverul Puppet master, editați următorul fișier:

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

Cel mai probabil pe acest moment fisierul este gol. Adăugați următoarele rânduri la acesta:

implicit nod ( )
nodul „lampa-1” (
}

Notă: Înlocuiți lamp-1 cu numele de gazdă al agentului dvs. Puppet pe care să instalați stiva.

Blocul de noduri vă permite să specificați codul Puppet care se va aplica numai unor noduri.

Blocul implicit se aplică tuturor nodurilor de agent care nu au un bloc individual (lăsați-l gol). Blocul lamp-1 va fi aplicat nodului agent lamp-1.

Adăugați următoarea linie la acest bloc, care utilizează modulul lămpii:

Salvați și închideți fișierul.

Acum, nodul agent Puppet va putea să descarce setările de pe serverul principal și să instaleze stiva LAMP. Dacă doriți să faceți modificări chiar acum, executați comanda pe agent:

sudo puppet agent --test

Modulele sunt cea mai convenabilă modalitate de a reutiliza codul Puppet. În plus, modulele vă ajută să vă organizați codul în mod logic.

Exemplul 3: Instalarea LAMP folosind module publice

Modulul MySQL este utilizat într-un mod similar. Adăugați următoarele linii la blocul de noduri:

class("mysql::server":
root_password => „parolă”,
}

De asemenea, puteți trece parametrii modulului MySQL.

Adăugați o resursă care va copia info.php în locația dorită. Utilizați parametrul sursă. Adăugați următoarele linii la blocul de noduri:

fișier("info.php": # nume fișier resursă
cale => "/var/www/html/info.php", # cale țintă
asigura => fișier,
require => Class["apache"], # clasa apache de utilizat
source => "puppet:///modules/apache/info.php", # locație în care să copiați fișierul
}

Această declarație de clasă folosește parametrul sursă în loc de conținut. Această opțiune nu numai că folosește conținutul fișierului, dar îl și copiază.

Puppet va copia fișierul puppet:///modules/apache/info.php în /etc/puppet/modules/apache/files/info.php.

Salvați și închideți fișierul.

Creați un fișier info.php.

sudo sh -c "eco"„> /etc/puppet/modules/apache/files/info.php”

Acum, nodul agent Puppet va putea să descarce setările de pe serverul principal și să instaleze stiva LAMP. Dacă doriți să faceți modificări în mediul agent chiar acum, executați comanda pe acest nod:

sudo puppet agent --test

Această comandă va descărca toate actualizările pentru nodul curent și va instala stiva pe acesta. Pentru a vă asigura că Apache și PHP funcționează, deschideți adresa IP sau domeniul nodului într-un browser:

http://lamp_1_public_IP/info.php

Concluzie

Acum aveți cunoștințe de bază despre lucrul cu modulele și manifestele Puppet. Încercați să creați singur un manifest și un modul simplu.

Puppet este excelent pentru gestionarea fișierelor de configurare a aplicației.

Etichete: ,
Un pic de poezie. S-ar părea că acest articol ar trebui să fie punctul de plecare pentru întreaga serie, dar publicul țintă este încă utilizatorii mai experimentați ai produselor Open Source Puppet Labs, care nu sunt mulțumiți de modulele individuale, slab integrate cu Puppet Forge. La fel ca în orice caz „bibliotecă vs. cadru”, prețul de plătit este să urmați viziunea asupra lumii a autorului soluției integrate.

Câteva despre cum funcționează Puppet

Puppet este în primul rând un limbaj specific pentru specificarea declarativă a stării finale a sistemului. Pentru comparație, GNU Makefile este extrem de potrivit, unde, pe lângă descrierea directă a dependențelor, este posibil să devină ciudat la maximum.

Abstracția păpușilor este ceva de genul acesta ( ruperea tiparelor - uitați tot ce știați despre termenii de programare!).

Nodul este un set de configurații pentru un anumit sistem țintă. De fapt, acesta este un caz special al unei clase.
Clasă este un set de logică declarativă care este inclusă în configurația nodului sau în alte clase. Clasa nu are nici instanțe, nici metode, dar are parametri și variabile definiți în cadrul logicii. De fapt, este mai degrabă o procedură care poate moșteni o altă procedură prin simpla adăugare de cod și având un domeniu nu atât de banal de variabile.
Tip- dar aceasta arată mai mult ca o clasă clasică - presupune instanțe cu un nume și cu siguranță parametrii dați, dar nimic mai mult. O implementare specifică a unui tip poate fi scrisă ca un script Puppet prin define , care creează instanțe de alte tipuri, sau ca o extensie Ruby cu un zbor de lux.
Resursă- acestea sunt de fapt numite instanțe ale Tipurilor. Fiecare nume de resursă este unic într-un anumit tip din configurația nodului (director).
Variabile- ei bine, pe scurt, astea sunt constante... Înainte de Puppet 4, lucrurile erau și mai rele cu scopul lor. Acum este adecvat: pentru utilizare din afara locației definiției, trebuie specificat un identificator complet calificat, cu excepția cazului moștenirii clasei.

Puppet poate fi folosit pentru implementare locală fără o rețea sau infrastructură asociată. Aceasta poate fi folosită pentru a crea imagini container. Există chiar și o întreagă mișcare care pledează pentru abandonarea unui server centralizat.

Într-o manieră corectă din punct de vedere ideologic, infrastructura Puppet constă dintr-un agent - un serviciu privilegiat pe sistemul țintă - și un server care distribuie instrucțiuni valoroase sub formă de directoare declarative de resurse la cererea agenților. Securitatea este implementată la nivelul infrastructurii cu chei publice private (X.509). Mai simplu spus, aceleași mecanisme ca și în HTTPS, dar cu propria CA și verificare obligatorie certificat de client.

Într-o formă simplificată, procedura de implementare arată cam așa:

Procesare prin TLS și X.509 (stabilirea conexiunii, actualizarea CRL, verificarea restricțiilor certificatelor etc.)
Agentul primește generatoare de fapte de la server cu cache și toate lucrurile (mai precis, totul este scos din folderele lib/ din module). Nu este dificil să adăugați propriul script Ruby pentru a colecta informațiile de interes.
Agentul colectează informații despre sistemul țintă și le trimite serverului. Toate faptele pot fi vizualizate cu ușurință manual prin apelul pentru fapte marionete. Aceste fapte sunt disponibile ca variabile globale.
Serverul compilează un catalog de resurse și îl trimite agentului. Sub aceasta se află un întreg strat de concepte diferite.
Agentul extrage tot ce este necesar de pe server și aduce sistemul în forma specificată. Agentul în sine nu știe ce să facă cu resurse; se bazează pe implementarea furnizorilor (traducerea semantică va fi „implementator”, nu furnizor) a unor tipuri specifice de resurse. Unii furnizori sunt standard și sunt incluși în pachetele Puppet, în timp ce restul sunt scoase din module.

Pentru a vă bucura de toate deliciile, există chifle suplimentare sub formă de:

Modul- o colecție de scripturi Puppet declarative, extensii Ruby pentru Puppet, fișiere, șabloane de fișiere, date Hiera și multe altele. Un termen mai corect ar fi „pachet”.
Mediu inconjurator- un set de scripturi, module și date Hiera. Pe măsură ce infrastructura a devenit mai complexă, a devenit inevitabil necesară împărțirea configurației mai mult decât împărțirea standard pe noduri. Practic, acest lucru este necesar pentru inovațiile pilot și controlul accesului banal (când nu toți administratorii au acces la toate nodurile infrastructurii IT).
Hiera- baza de date ierarhica. Această formulare poate fi foarte intimidantă. Acesta este probabil motivul pentru care a fost schimbat în documentația versiunilor ulterioare. De fapt, acesta este un mecanism extrem de simplu și convenabil pentru extragerea configurației din fișierele YAML sau JSON. Ierarhia este capacitatea de a specifica ordinea de citire a mai multor fișiere de configurare - de ex. ierarhia/prioritatea acestor fișiere.
- Pe lângă preluarea datelor prin apelul de funcție, Puppet extrage parametrii impliciti de clasă, care este principalul punct culminant.
- Desigur, Hiera acceptă interpolarea faptelor și chiar apelarea funcțiilor speciale.
- În Puppet 4.3, am implementat din nou aceeași funcționalitate pentru a sprijini nu numai baza de date globală, ci și cea locală pentru Mediu și Modul, deși autorul a găsit deja câteva probleme în implementarea lor (PUP-5983, PUP-5952 și PUP). -5899), care au fost remediate instantaneu de Puppet Labs.
- Sunt acceptate mai multe strategii pentru extragerea valorilor din toate fișierele din ierarhie:
  - first - prima valoare găsită prin prioritate este returnată
  - unic - colectează toate valorile într-o matrice unidimensională și elimină duplicatele
  - hash - combină toate YAML Hash găsite. Cheile duplicate sunt selectate după prioritate.
  - deep este în esență o versiune recursivă a hashului
- Frumusețea este că strategia de eșantionare poate fi specificată atât la apelarea funcției lookup(), deoarece și în orice fișier de ierarhie prin cheia specială lookup_options, care este utilizată activ în modulul cfnetwork.
PuppetDB- în esență, un strat de logică de afaceri în jurul unei baze de date relaționale (PostgreSQL), care vă permite să salvați rapoarte despre fapte și implementări efectuate și să exportați resurse pentru importarea ulterioară în directoare pe alte noduri sau selecții prin funcții speciale. Există, de asemenea, o interfață web sub forma Puppet Dashboard.
X.509 PKI- infrastructura de certificate deja menționată, care este extrem de convenabilă de utilizat pentru alte servicii fără a fi nevoie de a gestiona o infrastructură separată.
MCollective- pare a fi un lucru util pentru lansarea pe bază de evenimente a sarcinilor pe o fermă de servere, dar autorul are o anumită neîncredere în securitatea unei anumite soluții.
Forja păpușilor- o platformă deschisă pentru publicarea și descărcarea modulelor.
alte caracteristici sub formă de controale dispozitive externe tip de echipament Cisco și implementare pe bare metal, dar aceasta este o altă poveste

Note despre securitate și accesibilitate

Trebuie să înțelegeți că Puppet Server devine un punct vulnerabil al întregii infrastructuri IT, deoarece... determină configurația finală a tuturor sistemelor. În cazuri speciale, este logic să faceți o separare - un server separat pentru elementele de infrastructură critice cu extrem acces limitatși actualizare manuală și a doua pentru orice altceva.

Disponibilitatea Puppet Server determină capacitatea de a gestiona întreaga infrastructură. Este logic să găzduiți Puppet Server pe o mașină virtuală într-un cloud terță parte mai fiabil și mai rapid recuperabil decât propriile capacități. Sau ar trebui să instalați mai multe servere.

În orice caz, nu ar trebui să instalați alte servicii pe sistemul în care va fi implementat Puppet Server cu clopoței și fluiere. Virtualizarea și containerizarea vă pot ajuta.

Multi-master (mai multe servere Puppet separate)

În acest caz, un singur server acționează ca CA (Autoritate de Certificare) - indisponibilitatea acestuia înseamnă că este imposibil să adăugați noduri noi.
- Puppet vă permite să utilizați o infrastructură X.509 terță parte dacă cea încorporată nu este satisfăcătoare.
Întreaga configurație (Mediul) trebuie să fie stocată într-un sistem de control al versiunilor și implementată pe fiecare server simultan.
Singurul lucru în comun este baza de date PostgreSQL, a cărei organizare a disponibilității ridicate depășește domeniul de aplicare al acestui articol.
Modulul cfpuppetserver acceptă instalări ca server primar (cu CA) și ca server secundar.

Ce s-a schimbat semnificativ de la versiunile mai vechi

Producătorul are o descriere completă.

Toate serviciile s-au mutat în JVM, JRuby și Jetty. În ciuda avantajelor evidente ale integrării, există și dezavantaje în ceea ce privește consumul de memorie.
Au fost adăugate funcții Lambda pentru procesarea colecțiilor - acum nu este nevoie să tăiați cârje în Ruby sau să pervertiți prin create_resources()
A apărut un instrument pentru procesarea șabloanelor EPP - în esență același ERB, dar cu Puppet DSL în loc de Ruby,
Structura implicită de directoare a fișierelor de configurare s-a schimbat semnificativ
S-a adăugat suport pentru furnizorii de date pentru medii și module (hack-urile nu mai sunt necesare).
Minimizarea rolului Hierei globale. Comanda nouă și asociată este căutarea marionete.

Instalare

Acest proces este destul de primitiv, dar necesită urmarea unei anumite secvențe de pași. Deoarece a face acest lucru manual este o sarcină ingrată, autorul vă va învăța ceva rău, și anume, să descărcați scripturi de neînțeles de pe Internet și să le rulați ca root pe sistemul dumneavoastră.

Cele trei componente principale ale serverului sunt Puppet Server, PuppetDB și PostgreSQL. Toate pot fi înghesuite într-un singur nod sau împărțite în două sau trei sisteme. Puppet Server și Puppet DB pot fi executate de mai multe ori, dar PostgeSQL este un singur punct de eșec. Există diverse abordări ale replicarii și grupării PostgeSQL.O abordare convenabilă în cazul serverelor principale și secundare ar fi Master + Read-Only Slave, care este acceptat în PuppetDB ca nod principal și numai pentru citire, dar automatizarea acestor o configurare necesită timp și, prin urmare, nu este încă disponibilă inclusă în modulul cfpuppetserver.

Configurația în sine poate fi pur și simplu stocată cel puțin pe Sistemul de fișiereîmpreună cu Puppet Server, dar este ca și cum ai scrie scripturi pe un server web de producție. Cea mai potrivită soluție este un depozit git. Utilitarul r10k poate extrage toate ramurile depozitului și le poate implementa pe Puppet Server ca medii separate. r10k este destul de prost la tragerea de dependențe, așa că bibliotecar-puppet este folosit deasupra. Merită remarcat imediat că principalul mediu canonic al păpușilor este „producția”. Prin urmare, depozitul de configurare ar trebui să folosească o ramură numită „producție” mai degrabă decât „master”.

Cerințe de sistem

Hardware-ul este descris chiar de producător. Modulul cfpuppetserver acceptă în prezent numai Debian Jessie+ și Ubuntu Trusty+.

Configurare în Git

Pentru r10k în sine, locația depozitului nu contează foarte mult - principalul lucru este disponibilitatea acestuia. De exemplu, în scopuri de testare, depozitul ar putea fi găzduit pe același sistem și accesat prin file:// . Un loc bun pentru a începe este exemplul de configurare codingfuture/puppet-exampleenv.

Clonarea depozitului: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Instalare Setari generale acces de administrator folosind indicii în comentarii:
- $EDITOR data/common.yaml
Să creăm o configurație de nod:
- $MY_DOMAIN - nume de domeniu rădăcină (de exemplu, example.org)
- $HOST_NAME - nume de gazdă client fără domeniu
- mkdir date/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - configurarea unui nod cu Puppet Server conform sugestiilor din comentarii
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - configurarea unui nod arbitrar pe baza sugestiilor din comentarii
Impingem către propriul nostru server Git sau îl facem disponibil local pe un nod cu Puppet Server prin rsync sau scp. Un depozit local este convenabil ca pas intermediar până când serverul Git este implementat de la Puppet însuși. Într-un fel, acest lucru amintește de asamblarea unui compilator în mai multe etape.

Instalarea de la zero pe un sistem curat

Modulul cfpuppetserver vă permite să instalați totul folosind Puppet în sine, dar pentru instalarea inițială, operațiunile de bază sunt duplicate de un script Bash.

Pe sistemul țintă:

Descărcați scriptul de instalare: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Ne uităm prin script și ne încruntăm: mai puțin setup_puppetserver.sh
Rulați: bash setup_puppetserver.sh
marionetă.$(MY_DOMAIN) .
- Exemplu cu un depozit la distanță: bash setup_puppetserver.sh ssh:// [email protected]/puppet-conf
- Exemplu cu local: bash setup_puppetserver.sh file:///root/puppetconf/
Vedem cum sistemul se umflă și nu instalează totul foarte repede.
Dacă depozitul este la distanță:
- Creați o cheie SSH pentru root: ssh-keygen -t rsa -b 2048
- Înregistrăm cheia publică /root/.ssh/id_rsa.pub pe serverul Git la distanță...
- ... și acolo am configurat un hook Git apelând următoarea comandă: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Începem să implementăm manual configurația: /etc/puppetlabs/deploy.sh
Să încercăm cum funcționează pe serverul însuși: /opt/puppetlabs/bin/puppet agent --test
Verificați setările de rețea, val protectorși acces SSH

Adăugarea de noduri gestionate

Numele complet calificat al Puppet Server trebuie să fie disponibil prin DNS pe gazda gestionată sau codificat în /etc/hosts.
- Exemplu: echo „128.1.1.1 puppet.example.com” >> /etc/hosts
Pe nodul cu Puppet Server, rulați următorul script /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Copiați întregul rezultat și inserați-l în Linie de comanda pe sistemul țintă.
Așteptăm sfârșitul execuției și rulăm /opt/puppetlabs/bin/puppet agent --test . La prima lansare, va fi generată o cerere de semnare a certificatului.
Mergem la nodul Puppet Server pentru a semna certificatul.
- lista de certificare a marionetelor - verificăm semnătura certificatului pentru paranoia suplimentară.
- semn de certificare marionetă $(HOST_NAME).$(MY_DOMAIN) - de fapt, semnăm certificatul.
Ne întoarcem la nodul gestionat și rulăm din nou: /opt/puppetlabs/bin/puppet agent --test`. Acest lucru va forța să înceapă procedura de implementare.
Așteptăm finalizarea implementării prin intermediul Puppet Agent.
Gata, aveți o infrastructură minimă Puppet pregătită!

Exemplu de ieșire din /root/genclientinit.sh

bash</etc/cflocation fi if test! -z ""; apoi echo -n >/etc/cflocationpool fi if test! -z „\$http_proxy”; apoi exportați http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! care lsb-release | citit; apoi apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; apoi echo „Eșuat la detectarea numelui de cod corect” exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(codename) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<semn de certificare marionetă host.example.com" ecou "Folosiți CTRL+C pentru a opri ciclul, dacă nu reușește din motive diferite" somn 5 terminat EOT

Descrierea modulului

Lista completă a parametrilor Bash pentru scriptul inițial de instalare

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

r10k_repo_url - URI al depozitului Git
certname - numele de domeniu complet calificat al gazdei
cflocation - inițializarea faptului cf_location
cflocationpool - inițializarea faptului cf_location_pool
http_proxy - server proxy pentru cereri HTTP și HTTPS

Lista completă a parametrilor Bash pentru scriptul de inițializare a clientului Puppet

~# /root/genclientinit.sh Utilizare: ./genclientinit.sh [ [ []]]
Semnificația parametrilor este aceeași ca în scriptul anterior.

clasa cfpuppetserver

deployuser = "deploypuppet" - nume de utilizator pentru implementarea automată a actualizărilor de configurare
deployuser_auth_keys = undef - lista de chei pentru $deployuser
repo_url = undef - URI de depozit (exemplu: ssh://user@host/repo sau file:///some/path)
puppetserver = true - dacă se instalează componenta Puppet Server pe acest nod
puppetdb = true - dacă se instalează componenta PuppetDB pe acest nod
puppetdb_port = 8081 - port pentru PuppetDB
setup_postgresql = true - dacă se instalează componenta PostgreSQL pe acest nod (doar dacă instalarea PuppetDB este activată)
service_face = "orice" - numele resursei cfnetwork::iface pentru acceptarea conexiunilor de intrare
puppetserver_mem = automat - RAM pentru Puppet Server în megaocteți (minimum 192 MB)
puppetdb_mem = automat - RAM pentru PuppetDB în megaocteți (minimum 192 MB)
postgresql_mem = auto - RAM pentru PostgreSQL în megaocteți (minim 128 MB)

clasa cfpuppetserver::puppetdb

postgresql_host = "localhost" - adresa bazei de date
postgresql_listen = $postgresql_host - valoarea merge direct la directiva listen_addresses PostgreSQL
postgresql_port = 5432 - portul bazei de date
postgresql_user = "puppetdb" - utilizator PuppetDB în baza de date
postgresql_pass = "puppetdb" - parola utilizatorului PuppetDB din baza de date
postgresql_ssl = false - activați criptarea conexiunii pe baza certificatelor PKI Puppet

clasa cfpuppetserver::puppetserver

autosign = fals - NU TREBUIE folosit într-un mediu de luptă, cu excepția poate în DMZ. Există exclusiv pentru automatizarea testelor.
global_hiera_config = "cfpuppetserver/hiera.yaml" - calea către fișierul implicit de configurare Hiera conform canoanelor Puppet (prima componentă este numele modulului, restul este calea de sub fișierele/dosarul din modul)

Puteți ajuta și transfera niște fonduri pentru dezvoltarea site-ului

Gestionarea unui număr mare de sisteme Unix nu poate fi numită convenabilă. Pentru a schimba un parametru, administratorul trebuie să contacteze fiecare mașină; scripturile pot ajuta doar parțial și nu în toate situațiile.

Trebuie recunoscut faptul că administratorii de rețea Windows sunt încă într-o poziție mai avantajoasă. Este suficient să schimbați setările politicii de grup și după un timp toate computerele din rețea, inclusiv cele cu un sistem de operare instalat recent, vor „învăța” despre inovație, dacă le privește, desigur. Privind înapoi la perioada lungă de dezvoltare a Unix, veți observa că nimic de genul acesta nu a prins vreodată. Există soluții precum kickstart care ajută la instalarea inițială sistem de operare, dar o rafinare suplimentară va necesita un efort semnificativ. Soluțiile comerciale precum BladeLogic și OpsWare rezolvă doar parțial problema automatizării setărilor; principalul lor avantaj este disponibilitatea GUIși pot fi achiziționate numai de la organizații mari. Există, desigur, proiecte care oferă soluții gratuite, dar de-a lungul existenței lor nu au reușit niciodată să creeze o comunitate mare. De exemplu, Cfengine nu este foarte popular în rândul administratorilor, deși pe lângă Linux, poate fi folosit în *BSD, Windows și Mac OS X. Acest lucru se poate datora complexității relative a creării configurațiilor. Când descrieți sarcini, trebuie să țineți cont de caracteristicile fiecărui sistem specific și să controlați manual succesiunea de acțiuni atunci când executați comenzi. Adică, administratorul trebuie să rețină că pentru unele sisteme ar trebui să scrieți adduser pentru altele, useradd, să țineți cont de locația fișierelor pe diferite sisteme și așa mai departe. Acest lucru complică procesul de scriere a comenzilor cu un ordin de mărime; este foarte dificil să creați configurația corectă din mers și este aproape imposibil să citiți configurațiile create după un timp. În ciuda licenței GPL, Cfengine este de fapt un proiect unic care controlează toate schimbările și nu este foarte interesat de construirea unei societăți deschise. Drept urmare, capacitățile cfengine sunt destul de satisfăcătoare pentru dezvoltator, dar pentru alți administratori este mai degrabă o bătaie de cap în plus. Pentru a îmbunătăți cfengine, au fost create diverse suplimente de către dezvoltatori terți, ceea ce adesea a înrăutățit situația. Autorul mai multor astfel de module pentru cfengine, Luke Kanies, a decis în cele din urmă să dezvolte un instrument similar, dar fără multe dintre deficiențele cfengine.

Caracteristici marionete

Puppet, ca și cfengine, este un sistem client-server care utilizează un limbaj declarativ, adică obligatoriu pentru descrierea sarcinilor și bibliotecile pentru implementarea lor. Clienții se conectează periodic (30 de minute în mod implicit) la serverul central și primesc cea mai recentă configurație. Dacă setările primite nu se potrivesc cu starea sistemului, acestea vor fi executate, iar dacă este necesar, un raport cu operațiunile efectuate va fi trimis către server. Serverul poate salva mesaje în syslog sau într-un fișier, poate crea un grafic RRD și le poate trimite la un e-mail specificat. Straturile suplimentare Tranzacționale și de abstracție a resurselor oferă compatibilitate maximă cu setările și aplicațiile existente, permițându-vă să vă concentrați asupra obiectelor de sistem fără a vă face griji cu privire la diferențele în implementarea și descrierea comenzilor și formatelor de fișiere detaliate. Administratorul operează doar cu tipul de obiect, Puppet se ocupă de restul. Astfel, tipul de pachete cunoaște aproximativ 17 sisteme de pachete; cel necesar va fi recunoscut automat pe baza informațiilor despre versiunea distribuției sau a sistemului, deși, dacă este necesar, managerul de pachete poate fi forțat.

Spre deosebire de scripturi, care de multe ori nu sunt posibil de utilizat pe alte sisteme, configurațiile Puppet scrise de administratori terți vor funcționa, în cea mai mare parte, fără probleme pe orice altă rețea. În cartea de bucate cu marionete [ http://www.reducctivelabs.com/trac/puppet/tags/puppet%2Crecipe] există deja trei duzini de rețete gata făcute. Puppet acceptă în prezent oficial următoarele sisteme de operare și servicii: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo și MySQL, LDAP.

Limbajul păpușilor

Pentru a merge mai departe, trebuie mai întâi să înțelegeți elementele și capacitățile de bază ale limbii. Limba este una dintre punctele forte Marionetă. Cu ajutorul acestuia, sunt descrise resursele pe care administratorul plănuiește să le gestioneze și acțiunile. Spre deosebire de majoritatea soluțiilor similare, Puppet permite limbajului să simplifice accesul la toate resursele similare pe orice sistem într-un mediu eterogen. O descriere a unei resurse constă de obicei dintr-un nume, tip și atribute. De exemplu, să indicam fișierul /etc/passwd și să setăm atributele acestuia:

fisier("/etc/passwd":

proprietar => root,

grup => rădăcină,

Acum clienții, s-au conectat la server, vor copia fișierul /etc/passwd și vor instala atributele specificate. Puteți defini mai multe resurse într-o singură regulă, separându-le folosind punct și virgulă. Ce să faci dacă fișierul de configurare folosit pe server diferă de cel client sau nu este folosit deloc? De exemplu, această situație poate apărea când Setări VPN conexiuni. În acest caz, fișierul poate fi indicat folosind directiva sursă. Există două opțiuni aici, ca de obicei, pentru a specifica calea către alt fișier; sunt acceptate și două protocoale URI: fișier și marionetă. În primul caz, o legătură către un extern Server NFS, în a doua opțiune, pe serverul Puppet este lansat un serviciu asemănător NFS, care exportă resurse. În acest din urmă caz, calea implicită este relativă la directorul rădăcină al marionetei - /etc/puppet. Adică, legătura puppet://server.domain.com/config/sshd_config va corespunde fișierului /etc/puppet/config/sshd_config. Puteți suprascrie acest director folosind directiva filebucket, deși este mai corect să folosiți secțiunea cu același nume din fișierul /etc/puppet/fileserver.conf. În acest caz, puteți restricționa accesul la serviciu doar de la anumite adrese. De exemplu, să descriem secțiunea de configurare.

calea /var/puppet/config

permite *.domain.com

permite 192.168.0.*

permite 192.168.1.0/24

refuza *.wireless.domain.com

Și apoi ne întoarcem la această secțiune când descriem resursa.

sursă => „puppet://server.domain.com/config/sshd_config”

Înainte de două puncte este numele resursei. În cele mai simple cazuri, puteți specifica pur și simplu un alias sau variabile ca nume. Aliasul este setat folosind directiva alias. calea completă către fișier. În configurații mai complexe

fisier("/etc/passwd":

alias => passwd

O altă opțiune pentru crearea unui alias este bună atunci când aveți de-a face cu sisteme de operare diferite. De exemplu, să creăm o resursă care descrie fișierul sshd_config:

fișier (sshdconfig:

nume => $sistem de operare ? (

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

implicit => "/etc/ssh/sshd_config"

În acest exemplu, ne confruntăm cu o alegere. Fișierul pentru Solaris este specificat separat, pentru toate celelalte fișierul /etc/ssh/sshd_config va fi selectat. Acum această resursă poate fi accesată ca sshdconfig, în funcție de sistemul de operare se va selecta calea dorită. De exemplu, indicăm că dacă daemonul sshd rulează și este primit fișier nou, ar trebui să reporniți serviciul.

asigura => adevărat,

subscribe => Fișier

Variabilele sunt adesea folosite atunci când lucrați cu datele utilizatorului. De exemplu, descriem locația directoarelor de acasă ale utilizatorilor:

$homeroot = "/acasă"

Acum fișierele unui anumit utilizator pot fi accesate ca

$(homeroot)/$nume

Parametrul $name va fi completat cu numele contului utilizatorului. În unele cazuri, este convenabil să definiți o valoare implicită pentru un anumit tip. De exemplu, pentru tipul exec, ele indică adesea directoarele în care ar trebui să caute fișierul executabil:

Exec (cale => "/usr/bin:/bin:/usr/sbin:/sbin")

Dacă trebuie să indicați mai multe fișiere și directoare imbricate, puteți utiliza parametrul recurse.

fisier("/etc/apache2/conf.d":

sursă => „puppet:// puppet://server.domain.com/config/apache/conf.d”,

recurs => "adevărat"

Mai multe resurse pot fi combinate în clase sau definiții. Clasele sunt o descriere completă a unui sistem sau serviciu și sunt utilizate separat.

„/etc/passwd”: proprietar => rădăcină, grup => rădăcină, mod => 644;

„/etc/shadow”: proprietar => rădăcină, grup => rădăcină, mod => 440

Ca și în limbajele orientate pe obiecte, clasele pot fi suprascrise. De exemplu, pe FreeBSD proprietarul grupului acestor fișiere este wheel. Prin urmare, pentru a nu rescrie complet resursa, să creăm o nouă clasă freebsd, care va moșteni clasa linux:

clasa freebsd moștenește Linux (

Fișier[“/etc/passwd”] (grup => roată);

Fișier[“/etc/shadow”] (grup => roată)

Pentru comoditate, toate clasele pot fi plasate într-un fișier separat, care poate fi conectat folosind directiva include. Definițiile pot lua mai mulți parametri drept argumente, dar nu acceptă moștenirea și sunt folosite atunci când trebuie să descrii obiecte reutilizabile. De exemplu, să definim directorul principal al utilizatorilor și comenzile necesare pentru a crea un cont nou.

definește user_homedir ($grup, $nume complet, $ingroups) (

utilizator("$nume":

asigura => prezent,

comentariu => "$nume complet",

gid => "$grup",

grupuri => $ingroups,

abonament => minim,

shell => "/bin/bash",

home => "/home/$nume",

necesită => Grup[$grup],

exec("$name homedir":

comanda => „/bin/cp -R /etc/skel /home/$nume; /bin/chown -R $nume:$grup /acasă/$nume",

creează => "/home/$nume",

require => Utilizator[$name],

Acum pentru a crea unul nou cont doar contactați user_homedir.

user_homedir("sergej":

grup => "sergej",

nume complet => „Sergej Jaremchuk”,

ingroups => ["media", "admin]

Există descrieri separate ale nodurilor care acceptă moștenirea ca clase. Când un client se conectează la serverul Puppet, se va căuta secțiunea de noduri corespunzătoare și vor fi furnizate setări specifice numai acestui computer. Pentru a descrie toate celelalte sisteme, puteți utiliza nodul implicit. O descriere a tuturor tipurilor este dată în documentul „Referință tip”, care trebuie citit în orice caz, cel puțin pentru a înțelege toate capacitățile limbajului Puppet. Tipuri variate vă permit să executați comenzi specificate, inclusiv atunci când sunt îndeplinite anumite condiții (de exemplu, schimbarea unui fișier de configurare), lucrul cu cron, acreditările și grupurile utilizatorului, computerele, montarea resurselor, pornirea și oprirea serviciilor, instalarea, actualizarea și eliminarea pachetelor, lucrul cu chei SSH, zone Solaris și așa mai departe. Așa este cât de ușor este să forțezi lista de pachete din distribuțiile care folosesc apt să fie actualizată în fiecare zi între 2 și 4 ore.

program (zilnic:

perioada => zilnic,

interval =>

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

program => zilnic

Actualizarea pentru perioada respectivă va fi efectuată de fiecare sistem o singură dată, după care sarcina este considerată finalizată și va fi ștearsă de pe computerul client. Limbajul Puppet acceptă alte structuri familiare: condiții, funcții, matrice, comentarii și altele asemenea.

Instalarea Puppet

Puppet necesită Ruby (>= 1.8.1) cu suport OpenSSL și biblioteci XMLRPC, precum și biblioteca Faster [ http://reducctivelabs.com/projects/facter]. Depozitul Ubuntu 7.04 care a fost folosit pentru instalarea de testare includea deja pachetul Puppy.

$ sudo apt-cache search marionetă

puppet — managementul configurației centralizate pentru rețele

puppetmaster - demon centralizat de control al managementului configurației

În timpul instalării, vor fi instalate toate pachetele de dependență necesare: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install puppet puppetmaster

Puteți verifica disponibilitatea bibliotecilor Ruby cu comanda.

$ ruby -ropenssl -e "puts:yep"

~$ ruby -rxmlrpc/client -e "puts:yep"

Dacă nu sunt primite erori, atunci tot ce aveți nevoie este deja inclus. Fișierele care descriu configurația dorită a sistemelor sunt numite manifeste în terminologia Puppet. Când este lansat, demonul încearcă să citească fișierul /etc/puppet/manifests/site.pp; dacă lipsește, afișează un mesaj de avertizare. Când testați, puteți spune demonului să funcționeze în modul offline, caz în care manifestul nu este necesar

$ sudo /usr/bin/puppetmasterd --nonodes

Dacă este necesar, puteți conecta alte fișiere la site.pp, de exemplu cu descrieri de clasă. Pentru o rulare de probă, puteți introduce cele mai simple instrucțiuni în acest fișier.

fisier("/etc/sudoers":

proprietar => root,

grup => rădăcină,

Toate fișierele de configurare atât pentru server, cât și pentru clienți sunt localizate în /etc/puppet. Fișierul fileserver.conf despre care am vorbit mai sus este opțional și este folosit doar dacă Puppet va funcționa și ca server de fișiere. Pe Ubuntu, acest fișier exportă subdirectorul /etc/puppet/files. Subdirectorul ssl conține certificate și chei care vor fi utilizate pentru criptare la conectarea clienților. Cheile sunt create automat prima dată când porniți puppetmasterd; le puteți crea manual cu comanda.

$ sudo /usr/bin/ puppetmasterd --mkusers.

Fișierele puppetd.conf și puppetmasterd.conf sunt similare. Ele indică unii parametri pentru funcționarea demonilor pe sistemul client și pe server. Fișierul client diferă doar prin prezența parametrului server, care indică computerul pe care rulează puppetmasterd.

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# trimite un raport la server

Pentru a evita să tastezi totul manual, poți crea un șablon folosind puppetd însuși.

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

În mod similar, puteți crea site.pp pe server.

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Un alt fișier, tagmail.conf, vă permite să specificați adresele de e-mail la care vor fi trimise rapoartele. În cel mai simplu caz, puteți folosi o singură linie.

toate: [email protected]

Fișierele de configurare nu sunt suficiente pentru ca clientul să se conecteze la server. Pentru a face acest lucru, trebuie să semnați și certificatele. Mai întâi, pentru a informa serverul despre noul computer de pe sistemul client, introduceți comanda:

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

info: Solicitare certificat

avertisment: certificatul peer nu va fi verificat în această sesiune SSL

aviz: nu am primit certificat

Dacă se returnează o linie diferită, ar trebui să verificați funcționarea serverului.

$ ps aux | marionetă grep

marionetă 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd

Firewall-ul trebuie să permită conexiuni pe portul 8140.

Pe server primim o listă de certificate care trebuie semnate.

$ sudo puppetca --list

nomad.grinder.com

Și semnăm certificatul de client.

$ sudo puppetca –semn nomad.grinder.com

Acum clientul se poate conecta liber la server și poate primi setări.

Din păcate, pur și simplu nu este posibil să arătați toate capacitățile Puppet în cadrul articolului. Dar, după cum puteți vedea, acesta este un instrument funcțional și flexibil care vă permite să rezolvați majoritatea problemelor de administrare simultană a unui număr mare de sisteme. Dacă domeniul dvs. de lucru necesită configurarea mai multor sisteme. Și cel mai important, proiectul a reușit să adune o comunitate mică, dar în continuă creștere. Prin urmare, să sperăm că o idee bună nu va avea voie să moară sau să plece deoparte.

Marionetă este o structură multiplatformă care permite administratorii de sistem Efectuați sarcini obișnuite folosind cod. Codul vă permite să efectuați diverse sarcini de la instalarea de noi programe până la verificarea permisiunilor de fișiere sau actualizarea conturilor de utilizator. Marionetă superior nu numai în timpul instalării inițiale a sistemului, ci pe întregul ciclu de viață al sistemului. În cele mai multe cazuri marionetă utilizat în configurarea client/server.

Această secțiune prezintă instalarea și configurarea Marionetăîntr-o configurație client/server. Acest exemplu simplu demonstrează cum se instalează Apache folosind Marionetă.

Instalare

Pentru instalare Marionetă intra in terminal:

Sudo apt-get install puppetmaster

Pe mașinile client, introduceți:

Sudo apt-get install puppet

Setări

Înainte de a configura marioneta, poate doriți să adăugați o intrare DNS CNAME Pentru puppet.example.com, Unde exemplu.com- acesta este domeniul tău. Clienți impliciti Marionetă verificați DNS pentru puppet.example.com ca nume de server puppet ( Maestru papusar). Consultați Serviciul de nume de domeniu pentru detalii suplimentare despre utilizarea DNS.

Dacă nu intenționați să utilizați DNS, puteți adăuga intrări în fișierul /etc/hosts de pe server și client. De exemplu, în fișierul /etc/hosts Marionetă server adauga:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

Pe fiecare MarionetăÎn client, adăugați o intrare pentru server:

192.168.1.16 meercat.example.com marionetă meercat

Înlocuiți adresele IP și nume de domenii de la exemplu la adresele dvs. curente și numele serverului și clienților.

Acum, să setăm câteva resurse pentru apache2. Creați un fișier /etc/puppet/manifests/site.pp conţinând următoarele:

Pachetul ( "apache2": asigură => instalat ) serviciu ( "apache2": asigură => true, enable => true, require => Pachet["apache2"] )

Nodul „meercat02.example.com” (include apache2)

A inlocui meercat02.example.com la numele dvs. actual Marionetă client.

Pasul final pentru acest simplu Marionetă serverul trebuie să repornească serviciul:

Sudo /etc/init.d/puppetmaster reporniți

Acum pe Marionetă totul este configurat pe server și este timpul să configurați clientul.

Mai întâi, să configuram serviciul Marionetă agent de lansare. Editați /etc/default/puppet, înlocuind valoarea START pe da:

Sudo /etc/init.d/puppet start

Să revenim la Marionetă server pentru a semna certificatul client folosind comanda:

Sudo puppetca --semn meercat02.example.com

Verifica /var/log/syslog pentru orice erori de configurare. Dacă totul a mers bine, pachetul apache2 iar dependențele sale vor fi instalate la Marionetă client.

Acest exemplu este foarte simplu și nu arată multe dintre caracteristici și beneficii. Marionetă. Pentru Informații suplimentare uite

Serghei Iaremciuk

Configurare centralizată a sistemelor UNIX folosind Puppet

Gestionarea unui număr mare de sisteme UNIX nu poate fi numită convenabilă. Pentru a schimba un parametru, administratorul trebuie să contacteze fiecare mașină; scripturile pot ajuta doar parțial și nu în toate situațiile.

Trebuie recunoscut faptul că administratorii de rețea Windows sunt încă într-o poziție mai avantajoasă. Este suficient să schimbați setările politicii de grup și, după un timp, toate computerele din rețea, inclusiv cele cu un sistem de operare instalat recent, vor „învăța” despre inovație, dacă le privește, desigur. Privind înapoi la perioada lungă de dezvoltare UNIX, puteți vedea că nimic de genul acesta nu a prins vreodată. Există soluții precum kickstart care ajută la instalarea inițială a sistemului de operare, dar dezvoltarea ulterioară va necesita un efort semnificativ. Soluțiile comerciale, precum BladeLogic și OpsWare, rezolvă problema automatizării setărilor doar parțial; principalul lor avantaj este prezența unei interfețe grafice și doar organizațiile mari își pot permite să le achiziționeze. Există, desigur, proiecte care oferă soluții gratuite, dar de-a lungul existenței lor nu au reușit să creeze o comunitate mare. De exemplu, Cfengine nu este foarte popular în rândul administratorilor, deși, pe lângă Linux, poate fi folosit în *BSD, Windows și Mac OS X. Acest lucru se poate datora complexității relative a creării configurațiilor. Atunci când descrieți sarcini, este necesar să luați în considerare caracteristicile fiecărui sistem specific și să controlați manual secvența acțiunilor la executarea comenzilor. Adică, administratorul trebuie să-și amintească că pentru unele sisteme ar trebui să scrieți adduser, pentru altele - useradd, să țineți cont de locația fișierelor pe diferite sisteme și așa mai departe. Acest lucru complică procesul de scriere a comenzilor cu un ordin de mărime; este foarte dificil să creați configurația corectă din mers și este aproape imposibil să citiți configurațiile create după un timp. În ciuda licenței GPL, Cfengine este în esență un proiect unic care controlează toate schimbările și nu este foarte interesat de construirea unei societăți deschise. Drept urmare, capacitățile lui Cfengine sunt destul de satisfăcătoare pentru dezvoltator, dar pentru alți administratori este mai degrabă o bătaie de cap în plus. Pentru a îmbunătăți Cfengine, au fost create diverse suplimente de către dezvoltatori terți, ceea ce adesea a înrăutățit situația. Autorul mai multor astfel de module pentru Cfengine, Luke Kanies, a decis în cele din urmă să dezvolte un instrument similar, dar fără multe dintre deficiențele Cfengine.

Caracteristici marionete

Puppet, ca și Cfengine, este un sistem client-server care utilizează un limbaj declarativ pentru a descrie sarcini și biblioteci pentru a le implementa. Clienții se conectează periodic (la fiecare 30 de minute în mod implicit) la serverul central și primesc cea mai recentă configurație. Dacă setările primite nu se potrivesc cu starea sistemului, acestea vor fi executate, iar dacă este necesar, un raport cu operațiunile efectuate va fi trimis către server. Serverul de mesaje îl poate salva în syslog sau într-un fișier, poate crea un grafic RRD și îl poate trimite la adresa de e-mail specificată. Straturile suplimentare Tranzacționale și de abstracție a resurselor oferă compatibilitate maximă cu setările și aplicațiile existente, permițându-vă să vă concentrați asupra obiectelor de sistem fără a vă face griji cu privire la diferențele de implementare și descrierea comenzilor și formatelor de fișiere detaliate. Administratorul operează doar cu tipul de obiect, Puppet se ocupă de restul. Astfel, tipul de pachete cunoaște aproximativ 17 sisteme de pachete; cel necesar va fi recunoscut automat pe baza informațiilor despre versiunea distribuției sau a sistemului, deși, dacă este necesar, managerul de pachete poate fi setat forțat.

Spre deosebire de scripturi, care sunt adesea imposibil de utilizat pe alte sisteme, configurațiile Puppet scrise de administratori terți vor funcționa în cea mai mare parte fără probleme pe orice altă rețea. Puppet CookBook are deja trei duzini de rețete gata făcute. Puppet acceptă în prezent oficial următoarele sisteme de operare și servicii: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo și MySQL, LDAP.

Limbajul păpușilor

Pentru a merge mai departe, trebuie mai întâi să înțelegeți elementele și capacitățile de bază ale limbii. Limbajul este unul dintre punctele forte ale lui Puppet. Descrie resursele pe care administratorul intenționează să le gestioneze și acțiunile pe care le întreprind. Spre deosebire de majoritatea soluțiilor similare, Puppet permite limbajului să simplifice accesul la toate resursele similare pe orice sistem într-un mediu eterogen. O descriere a unei resurse constă de obicei dintr-un nume, tip și atribute. De exemplu, să indicam fișierul /etc/passwd și să setăm atributele acestuia:

fisier("/etc/passwd":

Proprietar => rădăcină,

Grup => rădăcină,

Mod => 644,

Acum clienții care se conectează la server vor copia fișierul /etc/passwd și vor seta atributele specificate. Puteți defini mai multe resurse într-o singură regulă, separându-le folosind punct și virgulă. Dar dacă fișierul de configurare folosit pe server diferă de cel client sau nu este folosit deloc? De exemplu, această situație poate apărea la configurarea conexiunilor VPN. În acest caz, ar trebui să indicați fișierul folosind directiva sursă. Există două opțiuni aici; puteți, ca de obicei, să specificați calea către alt fișier și, de asemenea, să utilizați cele două protocoale URI acceptate: fișier și marionetă. În primul caz, se folosește o legătură către un server NFS extern; în a doua opțiune, pe serverul Puppet este lansat un serviciu asemănător NFS, care exportă resurse. În acest din urmă caz, calea implicită este relativă la directorul rădăcină al marionetei – /etc/puppet. Adică, legătura puppet://server.domain.com/config/sshd_config va corespunde fișierului /etc/puppet/config/sshd_config. Puteți suprascrie acest director folosind directiva filebucket, deși este mai corect să folosiți secțiunea cu același nume din fișierul /etc/puppet/fileserver.conf. În acest caz, puteți restricționa accesul la serviciu doar la anumite adrese. De exemplu, să descriem secțiunea de configurare:

Calea /var/puppet/config

Permite *.domain.com

Permite 127.0.0.1

Permite 192.168.0.*

Permiteți 192.168.1.0/24

Respinge *.wireless.domain.com

Și apoi ne referim la această secțiune când descriem resursa:

sursă => „puppet://server.domain.com/config/sshd_config”

Înainte de două puncte este numele resursei. În cele mai simple cazuri, puteți specifica pur și simplu calea completă către fișier ca nume. În configurații mai complexe este mai bine să folosiți un alias sau variabile. Aliasul este setat folosind directiva alias:

fisier("/etc/passwd":

Alias => passwd

O altă opțiune pentru crearea unui alias este bună atunci când aveți de-a face cu sisteme de operare diferite. De exemplu, să creăm o resursă care descrie fișierul sshd_config:

fișier (sshdconfig:

Nume => $sistem de operare ? (

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

Implicit => "/etc/ssh/sshd_config"

În acest exemplu, ne confruntăm cu o alegere. Fișierul pentru Solaris este specificat separat, pentru toate celelalte fișierul /etc/ssh/sshd_config va fi selectat. Acum această resursă poate fi accesată ca sshdconfig, în funcție de sistemul de operare se va selecta calea dorită. De exemplu, indicăm că dacă daemonul sshd rulează și se primește un fișier nou, serviciul ar trebui repornit:

serviciu (sshd:

Asigură => adevărat,

Abonare => Fișier

Variabilele sunt adesea folosite atunci când lucrați cu datele utilizatorului. De exemplu, descriem locația directoarelor de acasă ale utilizatorilor:

$homeroot = "/acasă"

Acum fișierele unui anumit utilizator pot fi accesate ca:

$(homeroot)/$nume

Parametrul $name va fi completat cu numele contului utilizatorului. În unele cazuri, este convenabil să definiți o valoare implicită pentru un anumit tip. De exemplu, pentru tipul exec este foarte obișnuit să se specifice directoarele în care ar trebui să caute fișierul executabil:

Exec ( cale => "/usr/bin:/bin:/usr/sbin:/sbin" )

Dacă trebuie să indicați mai multe fișiere și directoare imbricate, puteți utiliza parametrul recurs:

fisier("/etc/apache2/conf.d":

Sursă => „puppet:// puppet://server.domain.com/config/apache/conf.d”,

Recurs => „adevărat”

Mai multe resurse pot fi combinate în clase sau definiții. Clasele sunt o descriere completă a unui sistem sau serviciu și sunt utilizate separat:

clasa linux (

Fișier (

„/etc/passwd”: proprietar => rădăcină, grup => rădăcină, mod => 644;

„/etc/shadow”: proprietar => rădăcină, grup => rădăcină, mod => 440

clasa freebsd moștenește Linux (

Fișier["/etc/passwd"] (grup => roată);

Fișier["/etc/shadow"] (grup => roată)

Pentru comoditate, toate clasele pot fi plasate într-un fișier separat, care trebuie inclus folosind directiva include. Definițiile pot lua mai mulți parametri drept argumente, dar nu acceptă moștenirea și sunt folosite atunci când trebuie să descrii obiecte reutilizabile. De exemplu, să definim directorul principal al utilizatorului și comenzile necesare pentru a crea un cont nou:

definește user_homedir ($grup, $nume complet, $ingroups) (

Utilizator ("$nume":

Asigurați => prezent,

Comentariu => „$nume complet”,

Gid => "$grup",

Grupuri => $ingroups,

Calitatea de membru => minim,

Shell => "/bin/bash",

Acasă => "/home/$nume",

Necesită => Grup[$grup],

Exec("$name homedir":

Comanda => "/bin/cp -R /etc/skel /home/$nume; /bin/chown -R $nume:$grup /home/$nume",

Creează => "/home/$name",

Necesită => Utilizator[$name],

Acum, pentru a crea un cont nou, trebuie doar să contactați user_homedir:

user_homedir("sergej":

Group => "sergej",

Nume complet => „Sergej Jaremchuk”,

Ingroups => ["media", "admin]

Există descrieri separate ale nodurilor care acceptă moștenirea, precum și clase. Când un client se conectează la serverul Puppet, se va căuta secțiunea de noduri corespunzătoare și vor fi furnizate setări specifice numai acestui computer. Pentru a descrie toate celelalte sisteme, puteți utiliza nodul implicit. O descriere a tuturor tipurilor este dată în documentul „Referință tip”, care trebuie citit în orice caz, cel puțin pentru a înțelege toate capacitățile limbajului Puppet. Diverse tipuri vă permit să executați comenzi specificate, inclusiv atunci când sunt îndeplinite anumite condiții (de exemplu, schimbarea unui fișier de configurare), lucrul cu cron, acreditările și grupurile de utilizator, computere, montarea resurselor, pornirea și oprirea serviciilor, instalarea, actualizarea și eliminarea pachetelor , lucrând cu chei SSH, zone Solaris și așa mai departe. Iată cum puteți forța cu ușurință lista de pachete din distribuții folosind apt să fie actualizată zilnic între 2 și 4 ore:

program (zilnic:

Perioada => zilnic,

Interval =>

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

Program => zilnic

Instalarea Puppet

Puppet necesită Ruby (versiunea 1.8.1 și mai sus) cu suport OpenSSL și biblioteci XMLRPC, precum și biblioteca Faster. Depozitul Ubuntu 7.04 care a fost folosit pentru instalarea de testare include deja pachetul Puppy:

$ sudo apt-cache search marionetă

~$ ruby -rxmlrpc/client -e "puts:yep"

$ sudo /usr/bin/puppetmasterd --nonodes

Dacă este necesar, puteți conecta alte fișiere la site.pp, de exemplu, cu descrieri de clasă. Pentru o rulare de probă, puteți introduce cele mai simple instrucțiuni în acest fișier.

clasa sudo(

Fișier ("/etc/sudoers":

Proprietar => rădăcină,

Grup => rădăcină,

Mod => 440,

nod implicit(

Includeți sudo

Toate fișierele de configurare, atât serverul cât și clientul, sunt localizate în /etc/puppet. Fișierul fileserver.conf, despre care am vorbit deja, este opțional și este folosit doar dacă Puppet va funcționa și ca server de fișiere. Pe Ubuntu, acest fișier exportă subdirectorul /etc/puppet/files. Subdirectorul ssl conține certificate și chei care vor fi utilizate pentru criptare la conectarea clienților. Cheile sunt create automat prima dată când porniți puppetmasterd; le puteți crea manual cu comanda:

$ sudo /usr/bin/puppetmasterd --mkusers

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# trimite un raport la server

raport = adevărat

Pentru a evita să tastați totul manual, puteți crea un șablon folosind puppetd:

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

În mod similar, puteți crea site.pp pe server:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Un alt fișier, tagmail.conf, vă permite să specificați adresele de e-mail la care vor fi trimise rapoartele. În cel mai simplu caz, puteți folosi o singură linie:

toate: [email protected]

Fișierele de configurare nu sunt suficiente pentru ca clientul să se conecteze la server. Pentru a face acest lucru, trebuie să semnați și certificatele.

Mai întâi, pentru a informa serverul despre noul computer, introduceți comanda pe sistemul client:

$ sudo puppetd --server grinder.com --waitforcert 60 –test

Firewall-ul trebuie să permită conexiuni pe portul 8140.

Pe server primim o listă de certificate care trebuie semnate:

$ sudo puppetca –list

nomad.grinder.com

Și semnați certificatul de client:

$ sudo puppetca –semn nomad.grinder.com

Acum clientul se poate conecta liber la server și poate primi setări.

Din păcate, este imposibil să arăți toate capacitățile Puppet în cadrul articolului. Dar, după cum puteți vedea, acesta este un instrument funcțional și flexibil care vă permite să rezolvați majoritatea problemelor de administrare simultană a unui număr mare de sisteme. Și cel mai important, proiectul a reușit să adune o comunitate mică, dar în continuă creștere. Prin urmare, să sperăm că o idee bună nu va avea voie să moară sau să plece deoparte.

Noroc!

Site-ul web al proiectului BladeLogic – http://www.bladelogic.com.
Site-ul web al proiectului OpsWare este http://www.opsware.com.
Site-ul web al proiectului Cfengine este http://www.cfengine.org.
Site-ul web al proiectului Puppet este http://reducctivelabs.com/projects/puppet.
Cartea de bucate pentru marionete - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
Bibliotecă mai rapidă -