Nu cu mult timp în urmă, pe paginile revistei, ne-am uitat la sistem telecomanda configurarea mașinilor UNIX Cfengine, care simplifică foarte mult viața administratorului de sistem prin automatizarea pașilor de configurare a multor noduri de rețea. Dar, oricât de convenabil ar fi Cfengine, are multe dezavantaje pe care nu le are un sistem numit Puppet.

Imaginați-vă în rolul unui administrator de sistem, responsabil cu menținerea funcționalității a sute de mașini care rulează sisteme de operare de tip UNIX. Fiecare dintre ele necesită configurare, actualizare periodică și monitorizare și se presupune că multe dintre ele îndeplinesc funcții similare.

Două treimi sunt stații de lucru, încă câteva sunt routere, iar restul sunt mai multe servere web și stocare de date. Întrebare: cum să gestionezi toată această afacere? Cel mai simplu răspuns este să vă conectați pur și simplu la fiecare dintre ele folosind SSH și să faceți modificările necesare. Cu toate acestea, această metodă are două probleme. În primul rând, este foarte intensivă în muncă. În al doilea rând, administratorul va trebui să efectueze în mod constant multe acțiuni monotone (de exemplu, pentru a actualiza OpenOffice.org pe toate stațiile de lucru, va trebui să executați aceleași comenzi de câteva zeci de ori). Puteți încerca să evitați această problemă scriind mai multe scripturi care se vor conecta la fiecare mașină în sine și vor executa comenzi pre-scrise. Dar și aici te așteaptă probleme.

Scripturile vor trebui modificate constant pentru a le adapta la fiecare sarcină; Scripturile vor trebui să țină cont de diferențele dintre sistemele de operare și versiuni și vor trebui să fie depanate mult timp înainte de a fi aplicate mașinilor care rulează. În general, nu comme il faut. Răspunsul corect este să folosiți așa-numitele sisteme de management al configurației la distanță, dintre care cei mai cunoscuți reprezentanți sunt sisteme deschise Cfengine și păpușă. Astfel de sisteme își asumă toate responsabilitățile pentru a aduce configurația mașinii la tipul potrivit, solicitând administratorului doar să descrie starea finală a sistemului într-un limbaj special (de exemplu, o descriere a pachetelor care trebuie instalate în sistemul de operare, ce linii trebuie adăugate la fișierele de configurare, ce comenzi trebuie executate etc. ). După aceasta, toate nodurile vor primi informații despre starea necesară de la server și vor efectua configurarea automată a sistemului. Datorită acestui mecanism, noile mașini pot fi configurate complet fără intervenția umană, iar cele existente pot fi reconfigurate adăugând doar câteva rânduri la descrierea stării.

Marionetă?

Am dedicat deja un articol întreg sistemului Cfengine, așa că astăzi ne vom concentra asupra sistemului Puppet, care poate fi numit succesorul său ideologic. Puppet a fost dezvoltat de Luke Kanies, care s-a săturat de limitările lui Cfengine și a decis să creeze o versiune mai bună de la zero. Dacă ați folosit deja Cfenfine, probabil veți găsi Puppet un sistem mai convenabil și mai puternic. Limba de stat a lui Puppet este mai la nivel înalt și mai flexibil, ceea ce înseamnă că administratorul nu trebuie să-și facă griji cu privire la lucruri precum scrierea unor reguli separate pentru fiecare tip de sistem de operare sau descriere detaliată efectuând acțiuni banale. Puppet îi permite stăpânului său să se concentreze pe ceea ce vrea să facă, în loc de cum să o facă (de exemplu, pentru a instala un anumit pachet pe oricare dintre sistemele de operare acceptate de sistem, trebuie doar să scrieți literalmente câteva rânduri spunând „Instalați acest program " în loc să descrie comenzile, necesare instalării acestuia). Puppet este scris într-un limbaj Ruby simplu, ceea ce facilitează adaptarea la o anumită sarcină și extinderea funcționalității acestuia (este furnizat un sistem flexibil de pluginuri).

În plus, spre deosebire de modelul de dezvoltare al lui Cfengine, care se învârte în esență în jurul unei singure persoane, Puppet are o comunitate mare de entuziaști care aduc îmbunătățiri la cod, partajează exemple de configurare și scriu documentație.

În general, Puppet pare a fi un sistem mai modern și mai sofisticat cu design bun. La fel ca Cfengine, acceptă aproape toate sistemele de operare moderne asemănătoare UNIX (inclusiv MacOS X) și poate rula și în mediul Cygwin pe Windows. Lista sa de dependențe include doar interpretul Ruby și instrumentul Factor, așa că nu ar trebui să existe probleme cu instalarea (pentru a fi corect, lista de dependențe a lui Cfengine este și mai scurtă).

Instalare

La fel ca Cfengne, Puppet este un sistem client-server care constă dintr-un server de control și noduri slave. Serverul stochează o descriere a stărilor finale ale nodurilor (care în termenii Puppet se numește manifest) și așteaptă să se conecteze. La fiecare jumătate de oră (implicit), clientul se conectează la server, primește de la acesta o descriere a stării finale, o compară cu cea actuală și, dacă acesta și/sau starea descrisă s-a schimbat, reconfigurează sistemul și apoi se duce la culcare. Comunicarea se realizează printr-un canal criptat, astfel încât atacurile bazate pe înlocuirea descrierii stării sunt excluse (dar dacă un atacator preia serverul, atunci toate nodurile vor fi sub controlul său).

Puppet este inclus în depozitele tuturor distribuțiilor populare, așa că instalarea nu ar trebui să fie dificilă. De exemplu, pe Debian/Ubuntu clientul Puppet poate fi instalat astfel:

$ sudo apt-get install puppet

Și serverul este așa:

$ sudo apt-get install puppet puppetmaster

Fișierele de configurare client și server sunt stocate în directorul /etc/puppet. Cel mai important dintre acestea este fișierul /etc/puppet/manifests/site.pp, care conține manifestul.

Stochează o descriere a stărilor și ar trebui să existe doar pe server. Pentru a ușura depanarea, să îi adăugăm o configurație simplă:

clasa passwd(
fisier("/etc/passwd":
proprietar => root,
grup => rădăcină,
mod => 644,
}
}
nod implicit(
include passwd
}

Aceste linii descriu starea în care proprietarul fișierului /etc/passwd trebuie să fie root și permisiunile sale sunt setate la 644. Vom arunca o privire mai atentă la formatul fișierului manifest în secțiunea următoare. Al doilea cel mai important fișier este /etc/puppet/puppet.conf. Setează configurația serverului și clienților, deci trebuie să fie prezent pe toate mașinile organizate în rețeaua Puppet. În Ubuntu, acest fișier conține setările minime necesare și în majoritatea cazurilor suficiente. Mai jos sunt date cu comentarii:

# vi /etc/puppet/puppet.conf
# Căi standard de director
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Locația instrumentului Facter,
# folosit pentru a obține informații despre sistemul de operare
factpath=$vardir/lib/factor
# Sincronizați pluginurile
# (plugin-uri instalate pe server - sunt copiate pe clienți)
pluginsync=true
# Catalog cu șabloane (citiți mai jos despre ele)
templatedir=$confdir/şabloane
# Sincronizare cu etckeeper
# (cine știe, va înțelege, alții nu au nevoie)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Fișierul de configurare poate include număr mare diverse opțiuni, informații despre care pot fi obținute prin generarea unei configurații implicite:

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

Configurația client implicită este generată folosind o altă comandă:

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

Fișierele Fileserver.conf și auth.conf sunt folosite pentru configurare server de fișiere(citiți despre acest lucru în secțiunea „Server de fișiere”) și autentificare. Încă nu are rost să le atingem. Odată finalizată configurarea, serverul Puppet trebuie repornit:

$ sudo /etc/init.d/puppetmaster restart

După care va fi gata să accepte cererile clienților. Cu toate acestea, fără un certificat semnat, niciun client nu va putea primi manifestul de la server și configura mașina.

Prin urmare, trebuie să rulăm clienții Puppet în modul de testare, astfel încât să își poată trimite certificatele la server pentru semnare (apropo, acest lucru se poate face pe toate mașinile în același timp folosind instrumentul shmux):

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

Ne întoarcem pe server și primim o listă de certificate pregătite pentru semnare:

$ sudo puppetca --list

Selectați o gazdă din listă și semnați certificatul acesteia:

$ sudo puppetca --sign nomad.grinder.com

Sau semnăm totul deodată:

$ sudo puppetca --semn --all

Acum puteți lansa clienți în modul luptă. Dar mai întâi trebuie să introduceți numele serverului Puppet în fișierul de configurare (în mod implicit, numele lui este pur și simplu puppet):

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

Lansarea clienților:

$ sudo /etc/init.d/puppet start

Limbajul descrierii de stat

După cum am menționat mai sus, Puppet folosește propriul limbaj pentru a descrie starea finală sistem de operare, cu ajutorul căruia administratorul de sistem indică sub ce formă trebuie aduse componentele OS pentru ca acesta să atingă starea dorită. Acesta este un limbaj destul de complex, care, cu toate acestea, este mult mai simplu decât orice limbaj de programare. Dacă sunteți cel puțin superficial familiarizat cu limbajul de scripting bash, veți înțelege cu ușurință limbajul Puppet. Elementul cheie al limbajului este resursele care sunt utilizate pentru a descrie în ce formă ar trebui convertită una dintre componentele sistemului de operare. De exemplu, următoarea resursă simplă descrie starea dorită a fișierului /etc/passwd:

# vi /etc/puppet/manifests/site.pp
fisier("/etc/passwd":
proprietar => „rădăcină”
}

Aici fișierul este tipul de resursă. Există câteva zeci de ele în total, de la resurse care gestionează fișiere, ca în acest exemplu, până la pachete și servicii. Linia /etc/passwd este numele resursei.

În cazul tipului de fișier, numele este același cu calea către fișier, dar în alte tipuri, numele poate fi arbitrar. Proprietarul liniei => „rădăcină” descrie setarea atributului proprietarului la root, adică spune că proprietarul fișierul specificat trebuie să existe un administrator.

Fiecare tip de resursă are propriul set de atribute disponibile pentru modificare, plus că există meta atribute speciale care pot fi folosite în orice resursă. Una dintre calitățile importante ale resurselor este capacitatea de a le lega. Acesta poate fi folosit pentru a forma lanțuri de dependență. Următoarea intrare creează resursa /etc/group, care depinde de resursa /etc/passwd (dependențele sunt specificate folosind atributul require meta):

# vi /etc/puppet/manifests/site.pp
fisier("/etc/group":
necesită => Fișier["/etc/passwd"],
proprietar => „rădăcină”,
}

Aceasta înseamnă că resursa /etc/group poate fi configurată (adusă în forma descrisă) numai când este configurată resursa /etc/passwd. Resursele pot fi grupate în colecții de resurse numite clase. Acest lucru este necesar pentru a combina resurse care sunt similare ca semnificație și tip de sarcină efectuată într-o singură resursă abstractă. De exemplu, pentru comoditate, am putea combina instalarea și lansarea serverului web nginx într-o resursă abstractă cu același nume:

# vi /etc/puppet/manifests/site.pp
clasa nginx(
pachet("nginx":
asigura => instalat
}
service("nginx":
asigura => rulează,
require => Pachetul["nginx"],
}
}

Aici, tipul de resurse de pachet este folosit pentru a instala pachetul nginx pe sistem, iar serviciul este folosit pentru a lansa serviciul cu același nume. Cu require, forțăm sistemul să pornească serviciul numai dacă pachetul a fost instalat cu succes. Comoditatea cursurilor este că pot fi incluse și în funcție de:

# vi /etc/puppet/manifests/site.pp
service("calamar":
asigura => rulează,
cere => Clasa["nginx"],
}

Ca și în limbajele OOP reale, clasele pot moșteni unele de la altele și pot suprascrie atribute:

# vi /etc/puppet/manifests/site.pp
clasa passwd(
fisier("/etc/passwd":
proprietar => „rădăcină”,
grup => „rădăcină”,
}
}
clasa passwd-bsd moștenește passwd (
Fișier["/etc/passwd"] (grup => "roată" )
}

Aici, clasa passwd-bsd moștenește de la passwd pentru a suprascrie atributul de grup al resursei /etc/passwd (pe sistemele BSD, /etc/passwd aparține grupului de roți, așa că am creat o clasă separată pentru astfel de sisteme). Mai târziu ne vom uita la o modalitate mai corectă și mai evidentă de a selecta valori alternative ale atributelor folosind condiții.

Variabilele sunt una dintre componentele integrale ale oricărui limbaj de programare, iar Puppet le are și ele. Variabilele încep cu semnul $ și pot conține orice număr, șir sau valoare booleană(adevarat, fals):

$want_apache = adevărat
$apache_version = "2.2.14"

Una dintre cele mai puternice caracteristici ale Puppet legate de variabile este integrarea sa cu instrumentul de informare a mașinii factor. Acest utilitar returnează toate informațiile specifice mașinii sub formă de perechi cheie-valoare, care sunt transformate în variabile cu același nume în Puppet. Împreună cu instrucțiunile condiționate în limbajul Puppet, acestea pot fi folosite pentru a modifica atributele resurselor în funcție de proprietățile mașinii.

De exemplu, clasa passwd descrisă mai sus poate fi rescrisă cu ușurință pentru a selecta automat un atribut în funcție de tipul de sistem de operare (fără a fi necesară clasa în sine):

# vi /etc/puppet/manifests/site.pp
fisier("/etc/passwd":
proprietar => „rădăcină”,
grup => $kernel ? (
Linux => „rădăcină”,
FreeBSD => „roată”,
},
}

În funcție de sistemul de operare pe care va fi analizat acest fragment al manifestului, valoarea atributului grupului va fi fie rădăcină, fie roată. Cu excepţia operator condițional, limbajul Puppet acceptă și un operator de selecție a cazurilor, care poate fi folosit pentru a crea o anumită resursă în funcție de valoarea unei variabile:

# vi /etc/puppet/manifests/site.pp
caz $sistem de operare (
redhat: (serviciu ("httpd": asigurați => rulează))
debian: (service("apache": asigura => rulează))
implicit: ( service ( "apache2": asigura =>
funcţionare))
}

Acest cod definește diverse opțiuni resursă de tip serviciu în funcție de sistemul de operare (numele serviciilor din diferite distribuții Linux pot diferi, astfel încât serviciul Puppet să ruleze trebuie specificat individual pentru fiecare dintre ele).

Opțiunea implicită este utilizată dacă valoarea variabilei nu se potrivește cu niciuna dintre opțiunile anterioare. Pe lângă tipurile de resurse de fișiere, pachete și servicii discutate anterior, Puppet acceptă un număr mare de alte tipuri de resurse, inclusiv cele create de dezvoltatori terți. Descrierea lor detaliată, inclusiv exemple, atribute și caracteristici acceptate, pot fi găsite în documentația oficială - http://docs.puppetlabs.com/references/stable/type.html. Mai jos este o listă și scurtă descriere cele mai utilizate sunt:

Tipuri populare de resurse pentru păpuși

• cron - gestionați joburile cron
• exec - rulați scripturi și comenzi
• fişier - managementul fişierelor
• filebucket - backup fişiere
• grup - management de grup
• host - gestionează intrările din fișierul /etc/hosts
• interfață - configurarea interfețelor de rețea
• mount - montarea sistemelor de fișiere
• notify - trimiteți un mesaj în fișierul jurnal Puppet
• pachet - managementul pachetelor
• service - management service
• sshkey - gestionați cheile SSH
• ordonat - ștergerea fișierelor în funcție de condiții
• utilizator - gestionarea utilizatorilor
• zone - Gestionarea zonelor Solaris

Al doilea cel mai important element al limbajului Puppet după resurse sunt nodurile. Cu ajutorul lor, administratorul poate descrie la ce mașini trebuie aplicate anumite resurse și clase. Cu alte cuvinte, este o modalitate de a specifica o configurație individuală pentru fiecare dintre mașinile care participă la rețeaua Puppet. Cel mai simplu exemplu de nod este dat la începutul articolului în secțiunea „Instalare”:

# vi /etc/puppet/manifests/site.pp
nod implicit(
include passwd
}

Aceasta este definiția nodului implicit, care include resursa/clasa passwd. Numele implicit înseamnă „toate celelalte noduri”, astfel încât resursa/clasa passwd definită undeva mai sus va fi configurată pe fiecare dintre ele. Cuvântul cheie include este folosit aici pentru comoditate, de fapt, toate clasele și resursele pot fi descrise direct în descrierea nodului, dar acest lucru nu este recomandat. În plus față de implicit, în numele nodului puteți specifica numele de rețea al mașinii (atunci toate resursele descrise în nod vor fi configurate numai pe această mașină) sau un nume arbitrar (atunci acest nod poate fi moștenit de un alt nod) . Pentru a înțelege cum funcționează toate acestea împreună cu clasele și resursele, să ne uităm la un exemplu de manifest Puppet gata făcut, folosit pentru a configura două mașini de rețea (un server web și un server NTP):

# vi /etc/puppet/manifests/site.pp
# Instalarea și rularea unui server SSH
clasa sshd(
pachet ( openssh-server: asigura => instalat )
serviciu (sshd:
nume => $sistem de operare ? (
fedora => "sshd",
debian => "ssh",
implicit => "sshd",
},
enable => true,
asigura => rulează,
}
}
# Instalați și rulați Apache
clasa httpd(
pachet ( httpd: assure => instalat )
serviciu (httpd:
enable => true,
asigura => rulează,
}
}
# Instalarea și pornirea unui server NTP
clasa ntpd(
pachet ( ntp-server: asigura => instalat )
serviciu (
server ntp:
enable => true,
asigura => rulează,
}
}
# Nodul de bază, folosit doar ca părinte al tuturor celorlalți
baza nodului(
include sshd
}
# Nodul în care va fi localizat serverul web
nodul web.server.com moștenește baza (
include httpd
}
# Nod server NTP
nodul ntp.server.com moștenește baza (
include ntpd
}

Această configurație aparent simplă face destul de multe: devine Apache instalat și rulat pe mașina de la web.server.com și un server NTP instalat și rulat pe mașină. ntp.server.com. În plus, ambele mașini instalează un server SSH. Este puțin probabil ca această configurație să se potrivească chiar și unui singur administrator; va trebui să fie serios îmbunătățit pentru a învăța cum să configurați corect serverele, să primiți configurații noi și alte fișiere de la serverul principal Puppet.

Cu toate acestea, arată clar puterea lui Puppet. Folosind o configurare simplă, am făcut ca mașinile să instaleze și să ruleze ele însele software-ul necesar și să-l mențină în stare de funcționare (dacă serverul se blochează, Puppet însuși se va reconfigura pentru a aduce sistemele la starea necesară).

Server de fișiere

Multe sarcini de administrare la distanță nu pot fi rezolvate fără copierea pe mașini fișiere suplimentare. Acestea pot fi configurații pre-preparate, pagini web pentru Apache, pachete care nu se află în depozitul oficial și multe altele. Pentru a ușura procesul de transfer al acestor fișiere către gazde la distanță, Puppet include un server de fișiere.

Setările serverului de fișiere sunt stocate în fișierul /etc/puppet/fileserver.conf. Pentru a forța Puppet să ofere clienților conținutul unui anume director, trebuie să puneți câteva rânduri în el:

# vi /etc/puppet/fileserver.conf
cale = /var/puppet/files
permite *.server.com

Aceste două rânduri indică faptul că directorul /var/puppet/files ar trebui să fie accesibil tuturor gazdelor din domeniul server.com. În plus, putem specifica numele de domeniu complet al unei mașini permise sau adresa sa IP și, de asemenea, le putem tăia pe cele nedorite folosind directiva deny. Orice fișier din acel director poate fi apoi mutat către client folosind resursa fișierului. De exemplu:

# vi /etc/puppet/manifests/site.pp
fisier("/etc/httpd/conf/httpd.conf":
sursa => "marioneta://httpd/httpd.conf",
mod => 644,
}

Fișierul httpd.conf, situat pe server în directorul /var/puppet/files/httpd, va fi copiat pe mașina țintă pe calea specificată în numele resursei.

Concluzii

În acest articol, am acoperit o parte foarte mică din capacitățile lui Puppet. De fapt este sistem complex, care poate fi descris pe deplin doar pe paginile unei cărți. În același timp, Puppet este foarte ușor de configurat și întreținut, mai ales că puteți găsi o mulțime de exemple ale configurației sale pe Internet.

Info

• Puppet folosește protocolul HTTP, astfel încât poate fi rulat sub un server web pentru a îmbunătăți performanța.
• Puppet poate fi folosit pentru a auto-configura și întreține o singură mașină locală.
• Combinând Puppet, instalarea sistemului de operare de rețea (pxe-install) și imaginile de instalare auto-construite, puteți crea o rețea complet auto-configurabilă de mașini care poate fi implementată cu o singură comandă.
• Multe companii mari folosesc Puppet în munca lor, cum ar fi Google, Fedora Project, Universitatea Stanford, Red Hat, Siemens IT Solution și SugarCRM.

Legături

• http://docs.puppetlabs.com - Documentația Puppet
• http://docs.puppetlabs.com/guides/language_tutorial.html - Descriere completă Limbajul păpușilor
• http://docs.puppetlabs.com/references/stable/type.html - Tipuri de resurse

Când numărul de servere pe care le gestionați este mai mic de zece, rareori cineva se gândește la gestionarea lor centralizată, acest lucru poate să nu fie necesar. Când există zeci de servere, software-ul centralizat și gestionarea configurației este extrem de utilă. Când există sute și mii de servere, acest lucru este vital. Există multe programe de acest gen, de exemplu: Chef, CFEngine, Puppet... Acesta din urmă va fi discutat în această postare.

Marioneta este considerată pe bună dreptate una dintre cele mai bune solutii asa. Este folosit de companii precum Google, Citrix și Red Hat. Aceasta este o aplicație client-server scrisă în limbajul de programare Ruby, care este distribuită în două versiuni:

• Puppet Open Source - complet versiune gratuită
• Puppet Enterprise - gratuit pentru până la 10 servere, apoi sunt necesare licențe

Să luăm în considerare instalarea serverului și agentului Puppet Open Source, care sunt incluse în pachetele celor mai moderne distribuții. În continuare vom vorbi despre Ubuntu 12.04 Precise Pangolin.

Partea din spate a lui Puppet se numește păpușar, să începem instalarea de acolo:

Și acum clientul:

În fișierul de configurare a clientului /etc/puppet/puppet.conf trebuie să vorbiți despre server adăugând următoarea secțiune:

Server=puppet.local report=true pluginsync=fals

În etapa inițială, este mai bine să dezactivați pluginsync.

Să rulăm clientul marionetă astfel încât să creeze o solicitare pentru un certificat:

Pe server, trebuie să verificați dacă cererea de certificat a fost primită și, dacă da, să eliberați un certificat:

Repetați pasul anterior pe client:

Grozav, totul funcționează. Să trecem la crearea primului manifest. Manifestele sau configurațiile sunt descrise într-un limbaj declarativ special. Ne vom obișnui imediat cu lucrurile bune, vom folosi o structură modulară și clase. De exemplu, să scriem un modul care va menține fișierul la zi /etc/hosts pe toate serverele noastre.

Să verificăm unde caută puppet modulele:

Creați directoare pentru modulul dvs

Primul manifest, cunoscut și ca fișierul modulului principal, ar trebui apelat init.pp

Gazdele clasei ( # puppet.local host ( "puppet.local": asigura => "prezent", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # gazdă linux.local ("linux.local": asigura => "prezent", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

În mod implicit, puppet caută un fișier /etc/puppet/manifests/site.pp pentru a încărca configurația, să o aducem la următoarea formă:

Implicit nod (include gazde)

Verificăm manifestul pe server:

Pe client:

După ce suntem siguri că totul funcționează, permitem serviciului să înceapă, în /etc/default/puppet schimba:

# Începeți marioneta pe cizmă? START=da

Pornirea serviciului

Puppet va sonda serverul puppetmaster la fiecare 30 de minute pentru modificări de configurare și, dacă este necesar, va ajusta sistemul în consecință.

Cu ceva timp în urmă, lista de servere din marcajele mele a depășit 200. Pe măsură ce numărul de servere crește, implementarea oricărei noi configurații sau instalarea de pachete noi irosește o cantitate enormă de timp. Așa că am decis să folosesc marioneta.
Marionetă(English puppet) este o aplicație client-server multiplatformă care vă permite să gestionați centralizat configurația sistemelor de operare și a programelor instalate pe mai multe computere. Puppet este scris în limbajul de programare Ruby.

De asemenea, ei spun că puppet este un sistem de management al configurației de la distanță, cei mai cunoscuți reprezentanți ai căruia sunt sistemele deschise Cfengine și Puppet.

După ce am citit recenziile, am decis să folosesc marioneta.

Instalarea și configurarea serverului Puppet:
Instalarea unui server de marionete:
Instalați puppet-server pe OpenSuSE 11.4:

fermoar în puppet-server

Să schimbăm numele serverului în marionetă:
/etc/HOSTNAME:

Înregistrarea DNS trebuie să se rezolve la 127.0.0.2
cat /etc/hosts:

127.0.0.2 puppet.site puppet

Să dăm drepturi utilizatorului marionetă:

Să începem serviciul Puppet Master:

rcpuppetmasterd începe

Să adăugăm lansarea demonului marionetă la pornire:

chkconfig -a puppetmasterd

Configurarea unui server de marionete:
Să definim directorul în care vor fi stocate fișierele pe care serverul puppet le va transfera pe mașinile client în manifeste de tip fișier.

vim /etc/puppet/fileserver

calea /etc/puppet/files
permite *

mkdir /etc/puppet/files

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

Vom crea un fișier cu orice conținut pentru implementare și testare pe clienți

atingeți /etc/puppet/files/puppettetesting

Să repornim serverul de păpuși:

reporniți rcpuppetmasterd

Marionetă folosește propriul limbaj pentru descrierea stării finale a sistemului de operare, cu ajutorul căruia administratorul de sistem indică sub ce formă trebuie aduse componentele OS pentru ca acesta să atingă starea dorită. Starea poate însemna prezența unui anumit fișier, folder, servicii care rulează, pachete instalate, actualizări și multe altele. Toate setările de stare sunt descrise în fișiere sau manifeste, care se află în directorul: /etc/puppet/manifests. Aceste fișiere au nume precum *.pp.

Să creăm cel mai simplu manifest:
/etc/puppet/manifests/1.file.pp:

fisier("/tmp/puppettetesting":
sursă => „puppet:///files/puppettesting”,
}

Pentru a utiliza acest manifest:
păpușă aplica 1.file.pp

Instalarea și configurarea clientului puppet:

fermoar în marionetă

Să dăm drepturi de marionetă utilizatorului:

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

Pentru a stabili o conexiune cu serverul puppet, clientul puppet trimite o cerere de confirmare a certificatului după ce această solicitare este confirmată pe server, clientul puppet va începe să folosească manifestele destinate acestuia. Vom trimite o cerere de confirmare a certificatului:

Pe server putem vedea ce cereri de confirmare sunt în așteptare:

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

Confirmăm:

puppetca --semn "puppet-client.localdomain"

Este timpul să privim cele mai simple exemple de creare a manifestelor:
creați un fișier /etc/puppet/manifests/site.pp:

nod implicit(
fisier("/tmp/puppettetesting":
sursa => „puppet:///files/puppettesting”,
}
service("ntp":
asigura => rulează,
enable => true ,
}
pachet("htop":
asigura => instalat,
}
}

implicit - se aplică tuturor clienților
fișier - această secțiune spune să creați sau să suprascrieți fișierul /tmp/puppettetesting care se află pe server în directorul /etc/puppet/files
serviciu: verificați dacă serviciul rulează, dacă nu rulează, apoi porniți-l și adăugați-l la pornire
pachet: verificați dacă pachetul htop este instalat pe client și dacă nu, instalați-l.

Pentru a verifica, rulați pe client:

După cum puteți vedea, pe client, ntp a fost adăugat la pornire, demonul ntp a fost lansat, pachetul htop a fost instalat și fișierul puppettesting a fost copiat în directorul /tmp/

info: catalog de stocare în cache pentru puppet-client.localdomain
info: se aplică versiunea de configurare „1370163660”
notificare: / Etapă[ principal] // Nod[ implicit] / Serviciu[ ntp] / asigurați-vă că ați schimbat „oprit” în „în rulare”
notificări: / Stage[ main] // Node[ default] / Package[ htop ] / ensure: created
notificare: / Stage[ main] // Node[ default] / File[ / tmp/ puppettesting] / asigurați: conținut definit ca „(md5)f2171ac69ba86781bea2b7c95d1c8e67”
Notă: Catalogul finalizat rulează în 3,95 secunde

În articolul următor voi descrie exemple mai complexe de creare a manifestelor și interfața web puppet-dashboard.

Tipuri populare de resurse pentru păpuși
cron- gestionarea joburilor cron
exec- rularea de scripturi și comenzi
fişier- gestionarea fișierelor
filebucket- copie de rezervă a fișierelor
grup- managementul grupului
gazdă- gestionarea intrărilor din fișierul /etc/hosts
interfata- configurarea interfetelor de retea
munte- montarea sistemelor de fișiere
notifica- trimiterea unui mesaj către fișierul jurnal Puppet
pachet- managementul pachetelor
serviciu- managementul serviciilor
sshkey- Gestionarea cheilor SSH
ordonat- ștergerea fișierelor în funcție de condiții
utilizator- managementul utilizatorilor
zone- Managementul zonei Solaris

Câteva despre cum funcționează Puppet

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 de variabile nu atât de banal.
• Tip- dar aceasta seamănă mai mult cu o clasă clasică - presupune instanțe cu un nume și parametri cu siguranță specificaț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.

Î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 verificarea obligatorie a certificatului de client.

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

1. Procesare prin TLS și X.509 (stabilirea conexiunii, actualizarea CRL, verificarea restricțiilor certificatelor etc.)
2. 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.
3. 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.
4. Serverul compilează un catalog de resurse și îl trimite agentului. Sub aceasta se află un întreg strat de concepte diferite.
5. Agentul extrage tot ce este necesar de pe server și aduce sistemul în forma specificată. Agentul în sine nu știe ce să facă cu resursele 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 restul sunt scoase din module.

• 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- 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ă extragerea datelor din apelurile de funcții, Puppet extrage parametrii de clasă impliciti, care este principalul punct culminant.
  • Desigur, Hiera acceptă interpolarea faptelor și chiar apelarea funcțiilor speciale.
  • În Puppet 4.3, au implementat din nou aceeași funcționalitate pentru a susține 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 reparate 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 setată fie apelând funcția 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 importul ulterior în directoare de pe alte noduri sau selectarea 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- se pare 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 precum echipamentele Cisco și implementarea pe bare metal, dar aceasta este o altă poveste

Note despre securitate și accesibilitate

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 în acest caz, doar un 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ă atât instalări de server primare (cu CA) cât și secundare.

Ce s-a schimbat semnificativ de la versiunile mai vechi

• 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

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 pentru replicarea și clusterizarea PostgeSQL. O abordare convenabilă în cazul serverelor principale și secundare ar fi Master + Read-Only Slave, care este acceptată în PuppetDB ca nod de bază de date principal și numai pentru citire, dar automatizarea acestui tip. 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 sistem 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 atragerea dependențelor, 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

Configurare în Git

1. Clonarea depozitului: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. Setăm setări generale pentru accesul de administrator folosind sfaturile din comentarii:
   • $EDITOR data/common.yaml
3. Să creăm o configurație de nod:
   • $MY_DOMAIN - rădăcină nume de domeniu(de exemplu, example.org)
   • $HOST_NAME - numele gazdei 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
4. 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

Pe sistemul țintă:

1. Descărcați scriptul de instalare: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Ne uităm prin script și ne încruntăm: mai puțin setup_puppetserver.sh
3. 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/
4. Vedem cum sistemul se umflă și nu instalează totul foarte repede.
5. 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
6. Începem să implementăm manual configurația: /etc/puppetlabs/deploy.sh
7. Să încercăm cum funcționează pe serverul însuși: /opt/puppetlabs/bin/puppet agent --test
8. Verificați rețeaua, filtrul de rețea și setările de acces SSH

Adăugarea de noduri gestionate

1. 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
2. Pe nodul cu Puppet Server, rulați următorul script /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
3. Copiați întregul rezultat și inserați-l în linia de comandă de pe sistemul țintă.
4. 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.
5. 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.
6. 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.
7. Așteptăm finalizarea implementării prin intermediul Puppet Agent.
8. 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 | citire; apoi apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; apoi ecou „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