Crearea de manifeste Puppet. Configurare centralizată cu Puppet

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 fel, de exemplu: Chef, CFEngine, ... Acesta din urmă va fi discutat în această postare.

Marioneta este considerată pe bună dreptate una dintre cele cele mai bune solutii ca asta. Este folosit de companii precum Google, Citrix și palarie rosie. Aceasta este de la sine aplicație client-server scris în limbaj Programare Ruby, care este distribuit în două versiuni:

  • Marionetă Sursa deschisa- versiune complet 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 prezente î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 maestru papusar, să începem instalarea de acolo:

:~# apt-get install puppetmaster

Și acum clientul:

:~# apt-get install puppet

Î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:

:~# puppetd --verbose --test info: Crearea unei noi chei SSL pentru linux.local info: Cache certificat pentru ca info: Crearea unei noi cereri de certificat SSL pentru linux.local info: Amprenta de solicitare a certificatului (md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Ieșire; nu a fost găsit niciun certificat și waitforcert este dezactivat

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

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca - -sign linux.local notice: Solicitare de certificat semnat pentru linux.local notificare: Eliminarea fișierului Puppet::SSL::CertificateRequest linux.local la „/var/lib/puppet/ssl/ca/requests/linux.local.pem”

Repetați pasul anterior asupra clientului:

:~# puppetd --verbose --test info: Cache certificat pentru linux.local info: Preluare informații despre plugin: Cache certificate_revocation_list pentru ca info: Cache catalog pentru linux.local info: Se aplică versiunea de configurare "1356278451" info: Crearea fișierului de stare / notificare var/lib/puppet/state/state.yaml: Catalog terminat în 0,02 secunde

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:

:~# puppet apply --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

Creați directoare pentru modulul dvs

:~# cd /etc/puppet/modules :~# mkdir hosts; gazde cd; mkdir se manifestă; se manifestă cd

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", țintă => "/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:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: Se aplică versiunea de configurare „1356281036” notificare: /Stage//Host/ensure: create info: FileBucket adăugând (md5)notice: /Stage// Gazdă/asigură: anunț creat: Catalog terminat rulat în 0,03 secunde

Pe client:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: Catalog de stocare în cache pentru linux.local info: Se aplică versiunea de configurare „1356283380” informații: FileBucket adăugând (md5)notice: /Stage/Hosts/Host/ensure: create notice: /Stage/Hosts/Host/ensure: create notice: Catalog terminat rulat în 0,04 secunde:~# ll /etc /hosts -rw-r--r-- 1 rădăcină rădăcină 551 23 decembrie 20:43 /etc/hosts

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

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

Pornirea serviciului

:~# service marionetă începe

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

  • Rubin
    • Tutorial

    Buna ziua.

    Acest subiect deschide o serie de articole despre utilizarea sistemului de management al configurației Puppet.

    Ce este un sistem de management al configurației?

    Să presupunem că aveți o flotă de servere care rulează diverse sarcini. Deși există puține servere și nu creșteți, puteți configura cu ușurință fiecare server manual. Instalați sistemul de operare (poate automat), adăugați utilizatori, instalați software introducând comenzi în consolă, configurați serviciile, editați configurațiile celor dragi editori de text(nanorc, vimrc), setați aceleași setări de server DNS pe ele, instalați agentul sistemului de monitorizare, configurați syslog pentru colectare centralizată bârlogurile... Într-un cuvânt, e destul de multă muncă și nu este deosebit de interesant.

    Cred cu adevărat că un administrator bun este un administrator leneș. Nu-i place să facă ceva de mai multe ori. Primul gând este să scriem câteva scripturi în care va fi ceva de genul:

    Servere.sh
    servers="server00 server01 server02 server03 server04" pentru server în $servers ; face scp /path/to/job/file/job.sh $server:/tmp/job.sh ssh $server sh /tmp/job.sh terminat

    Iov.sh
    #!/bin/bash apt-get update apt-get install nginx service nginx start

    Totul părea să fie ușor și bun. Trebuie să facem ceva - să scriem scenariu nou, hai să lansăm. Modificările vin la toate serverele secvenţial. Dacă scriptul este bine depanat, totul va fi bine. Pentru acum.

    Acum imaginați-vă că există mai multe servere. De exemplu, o sută. Și schimbarea durează mult timp - de exemplu, asamblarea a ceva mare și înfricoșător (de exemplu, un nucleu) din codul sursă. Scenariul va dura o sută de ani pentru a rula, dar asta nu este atât de rău.

    Imaginează-ți că trebuie să faci asta doar pe un anumit grup de acele sute de servere. Și două zile mai târziu trebuie să faceți o altă sarcină mare pe o altă secțiune de servere. Va trebui să rescrieți scripturile de fiecare dată și să verificați de multe ori dacă există erori în ele, dacă acest lucru va cauza probleme la pornire.

    Cel mai rău lucru este că în astfel de scenarii descrii actiuni, care trebuie efectuată pentru a aduce sistemul într-o anumită stare, și nu această stare în sine. Aceasta înseamnă că, dacă sistemul nu a fost inițial în starea la care te așteptai, atunci totul va merge cu siguranță prost. Manifestele marionete descriu în mod declarativ starea necesară a sistemului, iar calcularea modului de a ajunge la el din starea curentă este sarcina sistemului de management al configurației însuși.

    Pentru comparație: un manifest de marionete care face aceeași treabă ca câteva scenarii de la începutul subiectului:

    Nginx.pp
    clasa nginx ( pachet ( "nginx": asigurare => ultimul ) serviciu ( "nginx": asigurare => rulare, activare => adevărat, necesită => Pachet["nginx"] ) ) nod /^server(\d+)$ / (include nginx)
    Dacă utilizați corect serverele și petreceți ceva timp configurare inițială sistem de management al configurației, puteți obține o astfel de stare a flotei de servere, încât să nu aveți nevoie să vă conectați la ele pentru a lucra. Toate modificările necesare le vor fi trimise automat.

    Ce este Puppet?

    Puppet este un sistem de management al configurației. Arhitectura este client-server, configurațiile sunt stocate pe server (în termeni marionete sunt numite manifeste), clienții contactează serverul, le primesc și le aplică. Marioneta este scrisă în Limba rubin, manifestele în sine sunt scrise într-un DSL special, foarte asemănător cu Ruby în sine.

    Primii pasi

    Să uităm de clienți, servere, interacțiunile acestora etc. Să presupunem că avem un singur server pe care este instalat un sistem de operare complet (în continuare lucrez în Ubuntu 12.04, pentru alte sisteme acțiunile vor fi ușor diferite).

    Mai întâi, să instalăm cea mai recentă versiune de puppet.

    Wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb dpkg -i puppetlabs-release-precise.deb apt-get update apt-get install puppet puppetmaster

    Uimitor. Acum avem marioneta instalată pe sistemul nostru și ne putem juca cu ea.

    Salut Lume!
    Să creăm primul manifest:

    /tmp/helloworld.pp
    fișier ( "/tmp/helloworld": asigura => prezent, conținut => "Bună, lume!", mod => 0644, proprietar => "rădăcină", ​​grup => "rădăcină" )
    Și aplicați-l:

    $ puppet apply helloworld.pp /Stage//File/ensure: created Finished catalog rulează în 0,06 secunde

    Un pic despre lansare

    Manifestele prezentate în acest subiect pot fi aplicate manual folosind aplicația de marionetă. Cu toate acestea, în subiectele ulterioare configurația master-slave (standard pentru Puppet) va fi folosită pentru lucru.


    Acum uitați-vă la conținutul fișierului /tmp/helloworld. Va conține (în mod surprinzător!) rândul „Bună, lume!”, pe care am specificat-o în manifest.

    Ai putea spune că ai putea să faci ecou „Bună, lume!” > /tmp/helloworld , ar fi mai rapid, mai simplu, nu ar trebui să te gândești, să scrii niște manifeste groaznice și în general nimeni nu are nevoie de asta, e cumva prea complicat, dar gândește-te mai serios. De fapt, ar trebui să scrieți touch /tmp/helloworld && echo „Bună, lume!” > /tmp/helloworld && chmod 644 /tmp/helloworld && chown root /tmp/helloworld && chgrp root /tmp/helloworld pentru a asigura același rezultat.

    Să ne uităm rând cu rând la ceea ce este conținut exact în manifestul nostru:

    /tmp/helloworld.pp
    fișier ( "/tmp/helloworld": asigurați => prezent, # fișierul trebuie să existe conținut => "Bună ziua, lume!", # conținutul fișierului trebuie să fie șirul de caractere „Bună, lume!" modul => 0644, # permisiuni fișier - 0644 proprietar => „rădăcină”, # proprietar fișier - grup rădăcină => „rădăcină” # grup de fișiere - rădăcină )

    Descris aici în termeni marionete resursă tip fişier cu titlu /tmp/helloworld.

    Resurse
    O resursă este cea mai mică unitate de abstractizare din Puppet. Resursele pot fi:
    • dosare;
    • pachete (Puppet acceptă sistemele de pachete ale multor distribuții);
    • Servicii;
    • utilizatorii;
    • grupuri;
    • sarcini cron;
    • etc.
    Puteți arunca o privire la sintaxa resursei fără nicio restricție.

    Puppet vă permite să adăugați propriile resurse. Prin urmare, dacă sunteți cu adevărat confuz, puteți ajunge cu manifeste precum:

    Webserver.pp
    include server web; server web::vhost ( "example.com": asigura => prezent, dimensiune => "1G", php => fals, https => adevărat )
    Puppet va crea un volum logic de 1 GiB în dimensiune pe server, îl va monta unde ar trebui să fie (de exemplu, în /var/www/example.com), va adăuga intrările necesare în fstab, va crea gazdele virtuale necesare în nginx și apache, reporniți ambii demoni, adăugați utilizatorul example.com la ftp și sftp cu parola mySuperSecretPassWord cu acces de scriere la această gazdă virtuală.

    Gustos? Nu acel cuvânt!

    Mai mult, cel mai delicios lucru, după părerea mea, nu este automatizarea rutinei. Dacă, de exemplu, ești un idiot și îți reinstalezi constant serverele în producție, Puppet îți va permite să ridici complet vechiul set de pachete și configurații create cu dragoste de la zero. mod automat. Pur și simplu instalați agentul Puppet, îl conectați la Puppet Master și așteptați. Totul va veni de la sine. Pachetele vor apărea în mod magic (nu, într-adevăr magic!) pe server, cheile dvs. ssh vor fi descompuse, va fi instalat un firewall, vor ajunge setările individuale de bash și de rețea, tot software-ul pe care l-ați instalat cu grijă folosind Puppet va fi instalat și configurat. .
    În plus, Puppet, cu diligență, vă permite să obțineți un sistem de auto-documentare, deoarece configurația (manifestele) în sine sunt coloana vertebrală a documentației. Sunt mereu la zi (funcționează deja), nu au erori (vă verificați setările înainte de lansare), sunt puțin detaliate (funcționează).

    Puțină mai multă magie

    Câteva despre distribuția încrucișată

    Puppet are capacitatea de a folosi manifeste de distribuție încrucișată, acesta este unul dintre scopurile pentru care a fost creat. Nu l-am folosit niciodată intenționat și nu vi-l recomand. Parcul de servere ar trebui să fie cât mai omogen posibil în ceea ce privește software-ul de sistem, acest lucru vă permite să nu vă gândiți în momentele critice, „Ayblin, aici
    rc.d, nu init.d" (un semn din cap către ArchLinux) și, în general, vă permite să vă gândiți mai puțin la sarcinile de rutină.

    Multe resurse depind de alte resurse. De exemplu, pentru resursa „serviciu sshd” aveți nevoie de resursa „pachet sshd” și opțional „config sshd”
    Să vedem cum este implementat: fișier ( "sshd_config": cale => "/etc/ssh/sshd_config", asigura => fișier, conținut => "Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh / ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes RAGNUcationsAuthentiths yes Put da RhostsRSAAuth entication nu HostbasedAuthentication nu PermitEmptyPasswords nu ChallengeResponseAuthentication nu X11Redirecționare da X11DisplayOffset 10 PrintMotd nu PrintLastLog da TPCKeepAlive da AcceptEnv LANG LC_* Subsistem sftp /usr/lib/openssh/sftp-server UsePAM yes", mode => 0644, proprietar => root, group => root, require => Package["sshd"] ) package ( "sshd" : asigură => cel mai recent, nume => "openssh-server" ) serviciu ( "sshd": asigură => rulează, activare => true, nume => "ssh" subscribe => Fișier["sshd_config"], require => Pachetul[ „sshd”])

    Aceasta folosește o configurație inline, ceea ce face manifestul urât. În realitate, acest lucru nu se face aproape niciodată, există un motor de șabloane bazat pe ERB și abilitatea de a utiliza doar fișiere externe. Dar nu asta ne interesează.

    Cele mai delicioase linii de aici sunt liniile de dependență - solicitați și abonați-vă.

    Puppet acceptă multe opțiuni pentru descrierea dependențelor. Ca întotdeauna, puteți citi în detaliu în

    Am vorbit despre ce este managementul configurației și cum să implementați această tehnologie în infrastructura dvs.

    Notă: Acest tutorial a fost realizat pe Ubuntu 14.04 și Apache.

    Acest tutorial vă va ajuta să pregătiți orchestrarea automată a serverului folosind instrumentul de gestionare a configurației Puppet. Vă veți familiariza cu termenii de bază, sintaxa și caracteristicile Puppet. Ca rezultat, veți obține o implementare complet automatizată, simplă, care constă din următorii pași:

    • Actualizați indexul pachetelor.
    • Instalarea Apache.
    • Creați un director rădăcină de document personalizat.
    • Crearea unui fișier index.html în el.
    • Aplicarea unui șablon pentru a seta unul personalizat gazdă virtuală.
    • Repornirea Apache.

    Notă: Acest tutorial se concentrează pe crearea de manifeste - scripturi Puppet pentru a automatiza configurarea. Puteți citi mai multe despre Puppet în articolele:

    Începutul lucrării

    Înainte de a începe să vă dezvoltați manifestul, trebuie să vă familiarizați cu câțiva termeni de bază Puppet.

    Terminologia păpușilor

    • Puppet Master: Serverul principal care gestionează configurația nodurilor.
    • Agent marionetă: un nod slave care raportează maestrului.
    • Manifest: script de orchestrare.
    • Resursa: O bucată de cod care definește modificările necesare sistemului.
    • Modul: un grup de manifeste și alte fișiere organizate într-un mod predefinit, care facilitează partajarea și reutilizare părțile sale individuale ale orchestrației.
    • Clasa: Ca în orice limbaj obișnuit de programare, clasele sunt responsabile pentru organizarea și reutilizarea părților orchestrației.
    • Fapte: variabile globale ale sistemului.
    • Servicii: modificați starea unui serviciu (pornire, oprire etc.).

    Orchestrarea păpușilor este dezvoltată într-un limbaj DSL care se bazează pe Ruby.

    Resurse

    Puppet definește sarcini folosind resurse. Resursele pot reprezenta pachete, fișiere, servicii, utilizatori și comenzi. Ele pot avea o stare care va determina schimbarea sistemului dacă starea resursei declarate diferă de starea curentă a sistemului. De exemplu, o resursă de pachet cu starea instalată în manifest va începe să instaleze pachetul dacă pachetul nu a fost instalat anterior. O astfel de resursă arată astfel:

    pachet("apache2":

    asigura => "instalat"

    Resursa exec vă permite să executați orice comandă:

    exec("apt-get update":

    comandă => „/usr/bin/apt-get update”

    Rețineți că apt-get update din exemplul de mai sus nu este o declarație de comandă, ci un identificator de resursă. Adesea, în Puppet trebuie să faceți referire la alte resurse, iar acest lucru se face folosind ID-urile acestora.

    Dependența de resurse

    Când scrieți manifeste, este important să rețineți că Puppet nu folosește resurse în ordinea în care sunt definite. Resursele trebuie să-și definească în mod explicit dependențele una de cealaltă, altfel este imposibil de știut în ce ordine vor fi citite și executate resursele sau dacă vor fi executate deloc.

    Un exemplu este următorul cod; definește dependența resursei și apoi resursa în sine:

    pachet("python-software-properties":

    asigura => "instalat"

    }
    exec("adăugare depozit":

    comandă => "/usr/bin/add-apt-repository ppa:ondrej/php5 -y"
    require => Pachetul["python-software-properties"]

    Opțiunea require ia ca parametru o referință la o altă resursă. În acest caz, resursa Package este definită de pachetul python-software-properties.

    Notă: Declarațiile de resurse încep cu o literă mică (exec, pachet), iar dependențele încep cu o literă mare (Exec, pachet).

    De exemplu, trebuie să vă asigurați că o sarcină este finalizată înainte de a doua. Opțiunea înainte este folosită pentru aceasta.

    pachet("curl":

    asigura => "instalat"
    înainte => Exec[„script de instalare”]

    exec("script de instalare":

    comandă => „/usr/bin/curl http://example.com/some-script.sh”

    Format manifest

    Manifestele sunt colecții de resurse cu extensia .pp. Mai jos este un exemplu de manifest simplu care face două lucruri: actualizați indexul pachetului și instalați vim.

    exec("apt-get update":

    comandă => „/usr/bin/apt-get update”

    }
    pachet("vim":

    asigura => "instalat"
    require => Exec["apt-get update"]

    Notă: La sfârșitul acest manual veți găsi codul complet al manifestului Puppet.

    Scrierea unui manifest

    Variabile

    Variabilele pot fi definite oriunde în manifest. Cele mai comune tipuri de variabile sunt șiruri și matrice de șiruri, dar Puppet acceptă și alte tipuri.

    Acest cod definește un șir variabil care poate fi folosit ulterior în manifest:

    $pachet = "vim"
    pachet ($pachet:

    asigura => "instalat"

    Cicluri

    Buclele sunt de obicei folosite pentru a repeta o sarcină folosind valori de intrare diferite. Adică, în loc să creați 10 sarcini pentru a instala 10 pachete diferite, puteți crea o sarcină și puteți utiliza o buclă pentru a repeta sarcina pentru a instala orice pachet.

    Cel mai simplu mod de a defini o buclă în Puppet este cu o matrice, astfel:

    $pachete = ["vim", "git", "curl"]
    pachet ($pachete:

    asigura => "instalat"

    Începând cu versiunea 4, Puppet acceptă căi suplimentare pentru enumerarea sarcinilor. Codul de mai jos face același lucru ca codul anterior, dar de data aceasta folosește fiecare iterator. Această opțiune facilitează crearea buclelor de resurse:

    $pachete.fiecare |Șir $pachet| (
    pachet ($pachet:

    asigura => "instalat"

    Utilizarea expresiilor condiționate

    Expresiile condiționate pot fi utilizate pentru configurarea dinamică (de exemplu, atunci când trebuie să decideți dacă să efectuați o sarcină pe baza unei variabile sau a rezultatului unei comenzi).

    Puppet acceptă majoritatea structurilor condiționate ale limbajelor de programare tradiționale (cum ar fi declarațiile if/else și case); În plus, unele resurse (cum ar fi exec) acceptă atribute care acționează ca expresii condiționate, dar acceptă numai ieșirea comenzii ca o condiție.

    Să presupunem că doriți să executați o comandă bazată pe un fapt. Într-un astfel de caz, pentru a verifica valoarea unei variabile, trebuie să utilizați una dintre structurile condiționate acceptate, cum ar fi if/else:

    if $osfamily != „Debian” (

    warning ("Acest manifest este nu sunt acceptate pe acest sistem de operare.")

    notify("Bine de mers!":)

    Expresiile condiționate sunt adesea folosite și în automatizarea IT atunci când execuția unei comenzi depinde de rezultatul unei alte comenzi. În astfel de cazuri, numai dacă sau dacă nu este utilizat, așa cum se arată în exemplul de mai jos. Următoarea comandă va fi executată numai dacă ieșirea /bin/which php are succes:

    command => "/bin/echo PHP este instalat aici > /tmp/test.txt",
    onlyif => "/bin/care php"

    De asemenea, instrucțiunea unless va executa comanda numai dacă comanda in unless nu a fost executată.

    command => "/bin/echo PHP NU este instalat aici > /tmp/test.txt",
    exceptând cazul în care => "/bin/care php"

    Utilizarea șabloanelor

    Șabloanele sunt de obicei folosite în fișierele de configurare și vă permit să adăugați variabile și alte funcții care fac fișierele mai versatile și mai reutilizabile. Puppet acceptă două formate de șablon

    • Embedded Puppet (EPP): funcționează numai cu Puppet 4+.
    • Ruby încorporat (ERB)

    Mai jos este un exemplu de șablon ERB pentru crearea unui virtual gazdă Apache care folosește o variabilă pentru a crea directorul rădăcină al acelei gazde:


    ServerAdmin webmaster@localhost
    DocumentRoot<%= @doc_root %>
    >
    AllowOverride All
    Solicitați toate acordate

    Pentru a aplica un șablon, trebuie să creați o resursă de fișier care afișează conținutul șablonului folosind metoda șablonului. Pentru a înlocui gazda virtuală Apache implicită, utilizați acest șablon:

    asigura => "prezent",
    continut => template("apache/vhost.erb")

    În acest caz, Puppet va căuta șablonul vhost.tpl în directorul apache/templates.

    Definirea Serviciilor

    Resursele de serviciu modifică starea unui serviciu de sistem (de exemplu, oprirea sau repornirea acestuia).

    Să ne uităm la exemplul de șablon anterior, care este conceput pentru a crea o gazdă virtuală Apache. Pentru a vă asigura că Apache repornește după schimbarea gazdei virtuale, trebuie să creați o resursă de serviciu. Acest lucru se face astfel:

    service("apache2":

    asigura => rulează,
    enable => adevărat

    Pentru a identifica o resursă, utilizați opțiunea de notificare.

    fisier("/etc/apache2/sites-available/000-default.conf":

    asigura => "prezent",
    conținut => șablon ("vhost.erb"),
    notify => Service["apache2"]

    Exemplu de manifest

    Acum puteți colecta tot codul pentru acest tutorial într-un singur manifest care se va automatiza Instalare Apacheîn Ubuntu 14.04.

    Notă: O versiune actualizată a manifestului poate fi găsită pe Github. Acest folder conține, de asemenea, un fișier Vagrant care vă permite să testați manifestul pe o instalare simplificată folosind mașină virtuală Vagabond.

    $doc_root = "/var/www/example"
    exec("apt-get update":

    comandă => „/usr/bin/apt-get update”

    }
    pachet("apache2":

    asigura => "instalat",
    require => Exec["apt-get update"]

    }
    fișier ( $doc_root:

    asigura => "director",
    proprietar => "www-data",
    grup => "www-data",
    mod => 644

    }
    fisier("$doc_root/index.html":

    asigura => "prezent",
    sursa => "puppet:///modules/main/index.html",
    require => Fișier[$doc_root]

    }
    fisier("/etc/apache2/sites-available/000-default.conf":

    asigura => "prezent",
    content => template("main/vhost.erb"),
    notify => Service["apache2"],
    require => Pachetul["apache2"]

    }
    service("apache2":

    asigura => rulează,
    enable => adevărat

    • Prima linie conține variabila $doc_root, care este folosită ulterior pentru a declara resursa.
    • Rândurile 3-5: Resursa exec execută comanda apt-get update.
    • Rândurile 7-10: Resursa pachetului instalează pachetul apache2, depinde de actualizarea apt-get. Adică, această resursă va fi executată numai dacă este executată resursa necesară.
    • Rândurile 12-17: Resursa fișier creează un nou director rădăcină. Resursa fișierului poate crea fișiere și directoare, poate aplica șabloane și poate copia fișiere locale în server la distanta. Această sarcină poate fi efectuată în orice etapă a orchestrației, deci nu necesită dependențe.
    • Rândurile 19-23: O altă resursă de fișier copiază fișierul index.html în directorul rădăcină de pe server. Parametrul sursă îi permite lui Puppet să găsească fișierul sursă. Acest cod se bazează pe metoda de procesare fisiere localeîn Puppet. Puteți găsi o structură de directoare în depozitul Github care îi va permite Puppet să găsească această resursă. Directorul rădăcină trebuie creat înainte de a executa această resursă, astfel încât opțiunea require este folosită aici.
    • Liniile 25-30: Această resursă de fișier aplică șablonul Apache și repornește serviciul. ÎN în acest exemplu orchestrarea este organizată folosind modulul principal (prin urmare șablonul inițial va fi main/vhost.erb). Opțiunea require asigură că resursa va fi executată numai dacă pachetul apache2 este instalat.
    • Liniile 32-35: Resursa de serviciu repornește serviciul apache2.

    Concluzie

    Puppet este un instrument puternic de gestionare a configurației care utilizează DSL pentru a gestiona resursele serverului și a automatiza sarcinile. Acest limbaj oferă resurse suplimentare care oferă flexibilitate de orchestrare.

    Când lucrați cu Puppet, este important să rețineți că resursele nu sunt întotdeauna citite și executate în aceeași ordine în care sunt definite. Fiți foarte atenți când creați lanțul de execuție.

    Etichete: ,

    Administrare servere virtuale folosind Puppet

    Partea 1: Instalarea și configurarea Puppet

    Seria de conținut:

    În procesul de organizare a unui mediu server folosind instrumente de virtualizare sau servicii cloud numărul crește rapid servere separate. De fiecare dată când creați un nou server, este nevoie să instalați și să configurați cel adecvat software. În plus, sincronizarea configurațiilor serverului necesită efort suplimentar, cum ar fi scrierea de scripturi shell coajă.

    Prin utilizarea instrument software Cu Puppet, puteți crea rapid un nou server și puteți configura setările acestuia în doar câteva comenzi, fără nicio dificultate. În plus, Puppet va sincroniza periodic configurațiile serverelor create.

    În ciuda faptului că acest program este de obicei folosit pentru a gestiona structuri mari de server (de exemplu, în centre de date sau servicii Web cu un număr mare de utilizatori), poate fi folosit și pentru a întreține mai multe servere (de exemplu, în retea locala mic birou sau rețea de acasă).

    Istoria păpușilor

    Proiectul Puppet este dezvoltat de Puppet Labs și este distribuit ca software open source. cod sursa(Software cu sursă deschisă). Programul are o structură modulară flexibilă: în prezent au fost scrise peste 200 de module de extensie pentru Puppet.

    Puppet este susținut nu numai de compania de dezvoltare, ci și de o comunitate de utilizatori foarte activă.

    Instalarea și pregătirea Puppet pentru muncă

    Funcționarea Puppet este organizată după schema client-server. Fiecare client comunică periodic cu un server de management principal (sau mai multe astfel de servere) și își sincronizează configurația. În mod implicit, astfel de sesiuni de comunicare au loc la fiecare jumătate de oră. Prin urmare, pentru a asigura operatie normala Marioneta va necesita cel puțin două servere instalate: unul va îndeplini funcțiile serverului principal de control (server master), iar celălalt (sau altele) vor acționa ca servere subordonate acestuia, adică în acest context le putem numi servere „client”.

    Pentru a instala Puppet pe o gazdă care va gestiona alte servere ca server de management principal, trebuie să rulați comenzile prezentate în Lista 1. Rețineți că aceste comenzi sunt executate ca root. rădăcină.

    Listarea 1. Instalarea pachetului puppet-server pe serverul principal de comandă și control
    # yum -y instalează puppet-server # chkconfig puppetmaster la # service puppetmaster start

    Pachetele pentru serverele slave sunt instalate pe gazdele client, așa cum se arată în Lista 2 (comenzile sunt executate și ca superutilizator rădăcină).

    Lista 2. Instalarea pachetului de marionete pe gazda client
    # yum -y instalează puppet # chkconfig puppet la # service puppet start

    Dacă gazda serverului de control principal este protejată firewall, iar gazdele client sunt situate „în afara” față de acest firewall (de exemplu, computere dintr-o rețea locală), apoi pe serverul principal trebuie să deschideți un port TCP cu număr 8140 și, dacă este posibil, faceți-l disponibil numai pentru gazdele client. Dacă toate operațiunile sunt efectuate pe un computer (localhost), atunci nu sunt necesare manipulări cu firewall-ul.

    Bazele păpușilor

    Din perspectiva Marionetei, toate configurațiile sunt definite și descrise ca resurse ( resurse), care pot fi numite principalele componente structurale ale mediului de control. Resursele pot fi fișiere, servicii de server, pachete software etc. Mai mult, o resursă poate fi chiar și un singur apel de comandă coajă. De exemplu, resursa de tip descrisă în Lista 3 fişier reprezintă fișierul /etc/passwd, cunoscut de toată lumea, al cărui proprietar este rădăcină.

    Lista 3. Descrierea resursei - fișier /etc/passwd
    fișier ("/etc/passwd": proprietar => rădăcină, mod => 644, )

    Resursele pot fi grupate în funcție de anumite caracteristici: de exemplu, orice fișier are un proprietar și se află la o anumită adresă (cale) în sistemul de fișiere, fiecare utilizator are un nume de autentificare, un identificator personal (UID) și un identificator de grup ( GID). În conformitate cu aceste caracteristici, se formează tipuri de resurse. În plus, cel mai mult caracteristici importante tipurile de resurse sunt, într-un sens general, aceleași pentru oricare sisteme de operare, indiferent de detaliile minore de implementare. Adică, descrierea unei resurse poate fi complet abstractizată din implementarea ei într-un anumit sistem de operare.

    Pe baza cerințelor preliminare de mai sus, a fost format un strat de abstractizare a resurselor. RAL) Programe de păpuși. RAL împarte resursele în tipuri ( tipuri), care sunt modele nivel inalt, și furnizorii ( furnizorii), care reprezintă mai mult nivel scăzut, adică implementări de resurse specifice platformei. Această organizare RAL vă permite să scrieți descrieri de resurse într-un mod care este aplicabil aproape oricărui sistem.

    Ciclul de sincronizare RAL

    Puppet folosește RAL atât pentru a citi, cât și pentru a modifica starea resurselor sistemului. Ca sistem de monitorizare și control declarativ, Puppet își începe ciclul de lucru obținând informații despre starea în care ar trebui să se afle o resursă. Sincronizarea resurselor folosește RAL pentru a interoga starea curentă, pentru a o compara cu starea dorită și pentru a face orice modificări necesare dacă sunt detectate diferențe.

    Structura descrierii resurselor

    După cum am menționat mai sus, în Puppet, fiecare resursă este o instanță de un anumit tip ( tipul de resursă), cu care începe descrierea în sine. O resursă este identificată printr-un nume ( titlu), care este scris între ghilimele simple după acolada de deschidere și este urmat de un caracter două puncte. Urmează cu linie nouă sunt definite atributele de tip ( atribute), unele atribute fiind comune tuturor tipurilor, în timp ce altele sunt unice pentru aceasta tip specific resursă. Fiecare atribut are o valoare ( valoare), deci înregistrările de atribute cu valori corespunzătoare au forma generală atribut => valoare.

    O idee generală a sintaxei limbajului de descriere a resurselor Puppet poate fi obținută din Lista 4, care arată cel mai simplu caz - o descriere a unei resurse de tip „utilizator” ( utilizator).

    Lista 4. Sintaxa limbajului de descriere a resurselor Puppet folosind exemplul unui utilizator
    utilizator ( "alex": asigura => prezent, uid => "501", gid => "admin", shell => "/bin/bash", home => "/home/alex", managehome => true, )

    Fiecare linie de definire a atributului se termină cu o virgulă și cu închiderea bretele indică faptul că descrierea resursei este completă.

    Următoarea configurație, prezentată în Lista 5, instalează pachetul openssh-server, permite utilizarea serviciului sshd implicit și executați o verificare pentru a vă asigura că serviciul este de fapt activat și rulează.

    Lista 5. Descrierea resursei - serviciul sshd (instalare, lansare, verificare)
    pachet ( "openssh-server": asigurare => instalat, ) serviciu ( "sshd": activare => true, asigurare => rulare, necesită => Pachet["openssh-server"], )

    Acum trebuie să aplicați configurațiile de mai sus la serverele corespunzătoare. Pachetul Puppet include implicit un fișier special de configurare a resurselor. site.pp, care se află în director /etc/puppet/manifests. Dacă parametrii de configurare a resurselor nu sunt foarte complexi, atunci aceștia pot fi adăugați manual la acest fișier: de exemplu, conținutul listelor 3 și 4 de mai sus.

    După ce toate programele necesare sunt instalate și activate, și fișierele de configurare sunt generate, este imperativ să înregistrați toate serverele slave (clienții) pe serverul de control principal și să confirmați autenticitatea înregistrării ( semn), adică să se supună unui fel de certificare. Pe serverele slave, înregistrarea se face cu următoarea comandă (sunt necesare și drepturi de superutilizator rădăcină):

    puppetd --test --waitforcert 30 --server MASTER_SERVER_ADDRESS

    În loc de MASTER_SERVER_ADDRESS ar trebui indicat adresa reală server de control principal.

    Odată ce toți clienții necesari s-au înregistrat, comenzile prezentate în Lista 6 sunt executate pe serverul de control principal.

    Lista 6. Certificarea clienților înregistrați pe serverul de control principal
    puppetca --list # afișează o listă de adrese ale clienților înregistrați puppetca --sign CLIENT_SERVER_ADDRESS # în loc de CLIENT_SERVER_ADDRESS, specificați adresa reală a clientului # comanda se repetă pentru fiecare adresă de client

    Odată ce înregistrarea și certificarea sunt finalizate, Puppet va aplica automat configurațiile de resurse descrise mai sus clienților înregistrați.

    # Adresa reală a serverului este de asemenea scrisă aici server = MASTER_SERVER_ADDRESS

    Puppet este acum complet configurat și funcționează. Sincronizare automată configurațiile de resurse ale serverelor slave vor fi efectuate la fiecare 30 de minute. Puteți urmări procesul rulând comanda:

    coada -f /var/log/messages

    Concluzie

    În acest articol, am analizat procesul de configurare și configurare Puppet pe serverul principal de control și pe serverele client, a căror stare va fi monitorizată. Următorul articol din această serie va analiza exemple de configurare Puppet pentru efectuarea sarcinilor comune de administrator de sistem.

    Marionetă este o structură multiplatformă care permite administratorii de sistemîndeplini sarcini generale 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ă excelent nu numai în timpul instalării inițiale a sistemului, ci și pe tot parcursul ciclu de viață sisteme. În cele mai multe cazuri marionetă utilizat într-o configurație 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șină client(sau mașini) 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 care conțin 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 tău 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