Wanneer het aantal servers dat u beheert minder dan tien bedraagt, denkt zelden iemand na over het gecentraliseerde beheer ervan; dit is misschien niet nodig. Als er tientallen servers zijn, is gecentraliseerd software- en configuratiebeheer uiterst nuttig. Als er honderden en duizenden servers zijn, is dit van cruciaal belang. Er zijn veel van dit soort programma's, bijvoorbeeld: Chef, CFEngine, ... Het is de laatste die in dit bericht zal worden besproken.

Puppet wordt beschouwd als een van de beste oplossingen in dit soort. Het wordt gebruikt door bedrijven als Google, Citrix en Red Hat. Dit is op zichzelf client-server-applicatie geschreven in de programmeertaal Ruby, die in twee versies wordt gedistribueerd:

• Marionet Open bron- volledig gratis versie
• Puppet Enterprise - gratis voor maximaal 10 servers, daarna licenties vereist

Laten we overwegen om de Puppet Open Source-server en -agent te installeren, die zijn opgenomen in de pakketten van de meeste moderne distributies. Vervolgens zullen we het hebben over Ubuntu 12.04 Precise Pangolin.

De achterkant van Puppet heet poppenspeler, laten we de installatie vanaf daar starten:

:~# apt-get install poppenspeler

En nu de klant:

:~# apt-get installatiepop

In het clientconfiguratiebestand /etc/puppet/puppet.conf je moet over de server praten door de volgende sectie toe te voegen:

Server=puppet.local report=true pluginsync=false

In de beginfase is het beter om pluginsync uit te schakelen.

Laten we de poppenclient zo uitvoeren dat deze een verzoek voor een certificaat aanmaakt:

:~# puppetd --verbose --test info: Een nieuwe SSL-sleutel voor linux.local aanmaken info: Certificaat in cache opslaan voor ca info: Een nieuw SSL-certificaatverzoek voor linux.local aanmaken info: Vingerafdruk certificaatverzoek (md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Afsluiten; geen certificaat gevonden en waitforcert is uitgeschakeld

Op de server moet u controleren of het certificaatverzoek is ontvangen en, indien dit het geval is, een certificaat afgeven:

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca - -sign linux.local kennisgeving: Ondertekend certificaatverzoek voor linux.local kennisgeving: Bestand verwijderen Puppet::SSL::CertificateRequest linux.local op "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Herhaal de vorige stap op de client:

:~# puppetd --verbose --test info: Caching-certificaat voor linux.local info: Plugin-info ophalen: Caching certificaat_revocation_list voor ca info: Caching-catalogus voor linux.local info: Configuratieversie "1356278451" toepassen info: Statusbestand maken / var/lib/puppet/state/state.yaml kennisgeving: voltooide catalogusuitvoering in 0,02 seconden

Geweldig, alles werkt. Laten we verder gaan met het maken van het eerste manifest. Manifesten, of configuraties, worden beschreven in een speciale declaratieve taal. We zullen meteen aan goede dingen wennen, een modulaire structuur en lessen gebruiken. Laten we bijvoorbeeld een module schrijven die het bestand up-to-date houdt /etc/hosts op al onze servers.

Laten we eens kijken waar de pop naar modules zoekt:

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

Maak mappen voor uw module

:~# cd /etc/puppet/modules :~# mkdir hosts; cd-hosts; mkdir manifesteert; cd-manifesten

Het eerste manifest, ook wel het hoofdmodulebestand genoemd, moet worden aangeroepen init.pp

Class hosts (# puppet.local host ( "puppet.local": sure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local host ("linux.local": sure => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

Standaard zoekt de pop naar een bestand /etc/puppet/manifests/site.pp om de configuratie te laden, brengen we deze naar de volgende vorm:

Standaard knooppunt (inclusief hosts)

We controleren het manifest op de server:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: Configuratieversie "1356281036" toepassen kennisgeving: /Stage//Host/ensure: aangemaakte info: FileBucket toevoegen (md5)notice: /Stage// Hosten/zorgen: melding gemaakt: voltooide catalogusrun in 0,03 seconden

Op de cliënt:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 16 december 19:10 /etc/hosts :~# puppetd --verbose --test info: Caching-catalogus voor linux.local info: Toepassen configuratieversie "1356283380" info: FileBucket toevoegen (md5) mededeling: /Stage/Hosts/Host/ensure: melding aangemaakt: /Stage/Hosts/Host/ensure: melding aangemaakt: voltooide catalogus uitgevoerd in 0,04 seconden:~# ll /etc /hosts -rw-r--r-- 1 root root 551 23 december 20:43 /etc/hosts

Nadat we er zeker van zijn dat alles werkt, laten we de service beginnen /etc/default/puppet wijziging:

# Marionet starten bij opstarten? BEGIN=ja

Het starten van de dienst

:~# servicepopstart

Puppet zal de puppetmaster-server elke 30 minuten controleren op configuratiewijzigingen en, indien nodig, het systeem dienovereenkomstig aanpassen.

Voor meer effectief gebruik Puppet moet begrijpen hoe modules en manifesten worden gebouwd. In deze tutorial wordt uitgelegd hoe deze Puppet-componenten werken door een LAMP-stack op een Ubuntu 14.04-server in te stellen.

Vereisten

• Puppet installeren (master en agent). Meer hierover -.
• Mogelijkheid om er minstens één te creëren virtuele server Ubuntu 14.04 voor onderhoud aan het Puppet-agentknooppunt.

Basisprincipes van poppencode

Bronnen

Marionetcode bestaat voornamelijk uit bronnen. Een resource is een stukje code dat de status van het systeem beschrijft en bepaalt welke wijzigingen het nodig heeft. Bijvoorbeeld:

gebruiker("mitchell":
zorgen => aanwezig,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

De brondeclaratie heeft het volgende formaat:

resource_type("bron_naam"
attribuut => waarde
...
}

Om alle Puppet-brontypen te bekijken, geeft u de opdracht:

poppenbron --types

In deze handleiding leert u meer over resourcetypen.

Manifesten

Een manifest is een orkestratiescript. Marionettenprogramma's met de extensie .pp worden manifesten genoemd. Het standaard Puppet-manifest is /etc/puppet/manifests/site.pp.

Klassen

Zoals in elke reguliere programmeertaal zijn klassen verantwoordelijk voor het organiseren en hergebruiken van delen van de orkestratie.

Binnen een klassedefinitie bevindt zich een codeblok dat beschrijft hoe de klasse werkt. Nadat u een klasse hebt gedefinieerd, kunt u deze in manifesten gebruiken.

De klassedefinitie heeft het volgende formaat:

klasse voorbeeld_klasse(
...
code
...
}

Deze code definieert de klasse example_class. De Marionetcode staat tussen accolades.

Een klassedeclaratie is de plaats in de code waar een bepaalde klasse wordt aangeroepen. Met een klassedeclaratie verwerkt Puppet zijn code.

De klassedeclaratie kan gewoon zijn en per resourcetype.

Er wordt een reguliere klassedeclaratie aan de code toegevoegd met behulp van het trefwoord include.

omvatten voorbeeld_klasse

Wanneer gedeclareerd als een resourcetype, wordt de klasse gedeclareerd in het resourceformaat:

class("voorbeeld_klasse":)

Met deze declaratie kunt u klasseparameters aan uw code toevoegen die de standaardwaarden van klassekenmerken overschrijven. Bijvoorbeeld:

knooppunt "host2" (
class ("apache": ) # gebruik apache-module
apache::vhost ("example.com": # definieer vhost-bron
poort => "80",
docroot => "/var/www/html"
}
}

Modules

Een module is een groep manifesten en andere bestanden die op een vooraf gedefinieerde manier zijn georganiseerd om delen en hergebruik te vergemakkelijken afzonderlijke onderdelen orkestratie. Modules helpen bij het organiseren van Puppet-code, omdat ze kunnen worden gebruikt om code in meerdere manifesten te verdelen.

Puppet-modules worden opgeslagen in de map /etc/puppet/modules.

Een manifest schrijven

Je kunt oefenen met het schrijven van Puppet-manifesten, modules en klassen met behulp van het voorbeeld van het installeren van een LAMP-stack op een Ubuntu-server (het resultaat is ).

Dus om de orkestratie te doen Ubuntu-servers 14.04 en installeer de LAMP-stack erop, je hebt middelen nodig voor de volgende acties:

• het apache2-pakket installeren.
• het starten van de apache2-service.
• installatie van het MySQL-serverpakket, mysql-server.
• het starten van de mysql-service.
• php5-pakket installeren
• het maken van een PHP-testscript, info.php.
• het bijwerken van de apt-index voordat elk pakket wordt geïnstalleerd.

Hieronder vindt u drie voorbeelden van Puppet-code die kunnen worden gebruikt om een ​​dergelijke LAMP-stack-opstelling te realiseren.

In het eerste voorbeeld leert u hoe u basismanifesten in één bestand schrijft. Het tweede voorbeeld helpt u bij het samenstellen en gebruiken van een klasse en module op basis van eerder geschreven manifesten. Het derde voorbeeld laat zien hoe u vooraf gebouwde openbare modules kunt gebruiken om een ​​LAMP-stack te installeren.

Opmerking: Voor het testen is het beter om een ​​nieuwe virtuele server te gebruiken.

Voorbeeld 1: LAMP installeren met één manifest

Het Puppet-manifest kan op het agentknooppunt worden geschreven en vervolgens worden uitgevoerd met behulp van de opdracht puppet apply (u hoeft hiervoor geen master- en agentconfiguratie te hebben).

In deze sectie leert u manifesten schrijven die gebruik maken van dit soort brondeclaraties:

• exec: Voer opdrachten uit.
• pakket: pakketten installeren.
• dienst: servicemanagement.
• bestand: bestandsbeheer.

Het creëren van een manifest

Maak een nieuw manifest:

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

Voeg de volgende code eraan toe om de vereiste bronnen te declareren.

# voer de opdracht "apt-get update" uit
exec("apt-update": # resource exec "apt-update"
command => "/usr/bin/apt-get update" # commando dat deze bron zal uitvoeren
}
# installeer apache2-pakket
package("apache2":
require => Exec["apt-update"], # request "apt-update" voordat u het pakket installeert
zorgen => geïnstalleerd,
}
# start apache2-service
service("apache2":
zorgen => rennen,
}
# installeer mysql-server
package("mysql-server":
require => Exec["apt-update"], # verzoek "apt-update" door opnieuw te installeren
zorgen => geïnstalleerd,
}
# start de mysql-service
service("mysql":
zorgen => rennen,
}
# installeer php5-pakket
pakket("php5":
require => Exec["apt-update"], # verzoek "apt-update" vóór de installatie
zorgen => geïnstalleerd,
}
# start de info.php-service
file("/var/www/html/info.php":
zorg ervoor => bestand,
inhoud => "", #phpinfo-code
require => Pakket["apache2"], # verzoek voor pakket "apache2"
}

Een manifest toepassen

Om het nieuwe manifest te gebruiken, voert u de opdracht in:

sudo marionet toepassen --test

Het geeft een omvangrijk resultaat weer dat alle veranderingen in de toestand van de omgeving weergeeft. Als er geen fouten in de uitvoer voorkomen, zou u uw externe IP-adres moeten kunnen openen of domeinnaam in de browser. Er verschijnt een PHP-testpagina met stapelinformatie op het scherm. Dit betekent dat Apache en PHP werken.

Nu wordt de LAMP-stack op de server geïnstalleerd met behulp van Puppet.

Dit is een vrij eenvoudig manifest, omdat het op een agent kan worden uitgevoerd. Als u geen Puppet Master heeft, kunnen andere agentknooppunten dit manifest niet gebruiken.

De Puppet Master-server controleert elke 30 minuten op wijzigingen in de serverstatus.

Voorbeeld 2: Een LAMP-stack installeren met behulp van een module

Probeer nu een eenvoudige module te maken op basis van het LAMP-manifest dat u in de vorige sectie hebt geschreven.

Om een ​​module te maken, maakt u deze aan in de modulesmap nieuwe catalogus(de naam moet overeenkomen met de modulenaam). Deze map moet een map met manifesten en een init.pp-bestand bevatten. Het bestand init.pp specificeert de Puppet-klasse (de naam moet ook overeenkomen met de naam van de module).

Een module maken

Ga naar de Puppet master-server en maak een directorystructuur voor de module:

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

Maak en open het bestand init.pp in de editor:

sudo vi lamp/manifesten/init.pp

Voeg de lampklasse in het bestand in:

klasse lamp (
}

Kopieer de inhoud van het manifest uit sectie 1 en plak deze in het lampklasseblok. U hebt nu een lampklassedefinitie. Andere manifesten kunnen deze klasse als module gebruiken.

Sla het bestand op en sluit het.

Een module gebruiken in het hoofdmanifest

Nu kunt u het hoofdmanifest configureren en de lampmodule gebruiken om de LAMP-stack op de server te installeren.

Bewerk op de Puppet Master-server het volgende bestand:

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

Hoogstwaarschijnlijk op op dit moment het bestand is leeg. Voeg er de volgende regels aan toe:

standaard knooppunt ( )
knooppunt "lamp-1" (
}

Opmerking: Vervang lamp-1 door de hostnaam van uw Puppet-agent waarop u de stapel wilt installeren.

Met het knooppuntblok kunt u Marionetcode opgeven die alleen op bepaalde knooppunten van toepassing is.

Het standaardblok is van toepassing op alle agentknooppunten die geen individueel blok hebben (laat dit leeg). Het lamp-1-blok wordt toegepast op het lamp-1-agentknooppunt.

Voeg toe aan dit blok volgende regel, die de lampmodule gebruikt:

Sla het bestand op en sluit het.

Nu kan het Puppet-agentknooppunt instellingen downloaden van de masterserver en de LAMP-stack installeren. Als u nu wijzigingen wilt aanbrengen, voert u de opdracht uit op de agent:

sudo marionetagent -test

Modules zijn de handigste manier hergebruiken Marionetcode. Bovendien helpen modules u bij het logisch ordenen van uw code.

Voorbeeld 3: LAMP installeren met openbare modules

De MySQL-module wordt op een vergelijkbare manier gebruikt. Voeg de volgende regels toe aan het knooppuntblok:

class("mysql::server":
root_password => "wachtwoord",
}

U kunt ook MySQL-moduleparameters doorgeven.

Voeg een bron toe die info.php naar de gewenste locatie kopieert. Gebruik de bronparameter. Voeg de volgende regels toe aan het knooppuntblok:

file("info.php": # bestandsnaam van bron
path => "/var/www/html/info.php", # doelpad
zorg ervoor => bestand,
require => Class["apache"], # apache-klasse om te gebruiken
source => "puppet:///modules/apache/info.php", # locatie waar het bestand naartoe moet worden gekopieerd
}

Deze klassedeclaratie gebruikt de bronparameter in plaats van de inhoud. Deze optie gebruikt niet alleen de inhoud van het bestand, maar kopieert deze ook.

Puppet kopieert het bestand puppet:///modules/apache/info.php naar /etc/puppet/modules/apache/files/info.php.

Sla het bestand op en sluit het.

Maak een info.php-bestand.

sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"

Nu kan het Puppet-agentknooppunt instellingen downloaden van de masterserver en de LAMP-stack installeren. Als u nu wijzigingen wilt aanbrengen in de agentomgeving, voert u de opdracht uit op dit knooppunt:

sudo marionetagent -test

Met deze opdracht worden alle updates voor het huidige knooppunt gedownload en de stapel daarop geïnstalleerd. Om te verifiëren dat Apache en PHP werken, opent u het IP-adres of domein van het knooppunt in een browser:

http://lamp_1_public_IP/info.php

Conclusie

Je hebt nu basiskennis van het werken met Puppet-modules en manifesten. Probeer zelf een eenvoudig manifest en module te maken.

Puppet is ideaal voor het beheren van applicatieconfiguratiebestanden.

Trefwoorden: ,
Auteur: Luke Kanies
Publicatiedatum: 2 mei 2012
Vertaling: A. Panin
Datum van vertaling: 27 augustus 2013

18.1. Invoering

Puppet is een tool voor het beheer van de IT-infrastructuur, ontwikkeld met behulp van de programmeertaal Ruby en gebruikt om het onderhoud van datacenters en serverbeheer voor Google, Twitter, de New York Stock Exchange en vele andere organisaties te automatiseren. De ontwikkeling van het project wordt voornamelijk ondersteund door de Puppet Labs-organisatie, die de basis heeft gelegd voor de ontwikkeling ervan. Puppet kan 2 tot 50.000 servers beheren en worden onderhouden door een team van één of honderden systeembeheerders.

Puppet is een hulpmiddel dat is ontworpen om uw computers in te stellen en te onderhouden; Met behulp van de eenvoudige configuratietaal kunt u Puppet vertellen hoe u uw machines wilt configureren, en hij zal ze indien nodig opnieuw configureren om aan uw specificaties te voldoen. Als u deze specificatie in de loop van de tijd wijzigt vanwege omstandigheden zoals pakketupdates, het toevoegen van nieuwe gebruikers of configuratie-updates, zal Puppet de configuratie van uw machines automatisch bijwerken zodat deze overeenkomt met de specificatie. Als ze al correct zijn geconfigureerd, zal Puppet geen werk doen.

Over het algemeen doet Puppet alles mogelijke acties gericht op het gebruik van de functies van een bestaand systeem om hun werk uit te voeren; dat wil zeggen, op distributies gebaseerd op RedHat-technologieën zal het het hulpprogramma yum gebruiken om pakketten te beheren en init.d om services te beheren, terwijl het in OS X het hulpprogramma dmg zal gebruiken om pakketten te beheren en launchd om services te beheren. Een van de fundamentele doelen van het Puppet Project is het produceren van nuttig werk, of het nu gaat om het gebruik van Puppet Project-code of het systeem zelf, dus de volgende systeemstandaarden zijn van cruciaal belang.

Het Puppet-project is gebouwd op basis van ervaring met vele andere tools. In de wereld van open source-applicaties was de grootste invloed op de ontwikkeling ervan het CFEngine-project, het eerste configuratietool algemeen doel open source, evenals het ISconf-project, dat het make-hulpprogramma gebruikte om al het werk te doen, wat op zijn beurt veroorzaakte speciale aandacht naar expliciet beschreven afhankelijkheden in het systeem. In de commerciële wereld software Puppet kan worden gezien als een concurrent van de BladeLogic- en Opsware-projecten (die later door grotere bedrijven werden overgenomen), die beide goed verkochten toen Puppet werd geïntroduceerd, maar elk van deze tools werd verkocht aan leidinggevenden van grote bedrijven, in plaats van te worden verkocht aan managers van grote bedrijven. ontwikkeld in overeenstemming met de directe vereisten voor tools voor kwaliteitssysteembeheerders. Het doel van het Puppet-project was het oplossen van problemen die vergelijkbaar zijn met de problemen die met deze tools worden opgelost, terwijl het bedoeld was voor totaal andere gebruikers.

Als eenvoudig voorbeeld van het gebruik van Puppet is hier een codefragment om ervoor te zorgen dat de Secure Shell-service (SSH) correct wordt geïnstalleerd en geconfigureerd: class ssh ( package ( ssh: sure => geïnstalleerd ) file ( "/etc/ssh /sshd_config ": source => "puppet:///modules/ssh/sshd_config", sure => present, require => Package ) service ( sshd: sure => running, require => , Package] ) )

Met deze code weet u zeker dat het pakket wordt geïnstalleerd, het bestand op de gewenste locatie wordt geplaatst en de service wordt gestart. Opgemerkt moet worden dat we de afhankelijkheden tussen bronnen hebben beschreven, zodat we alle werkzaamheden altijd in de juiste volgorde zullen uitvoeren. Deze klasse kan aan elk knooppunt worden gekoppeld om een ​​bepaalde configuratie binnen dat knooppunt toe te passen. Houd er rekening mee dat de bouwstenen van de poppenconfiguratie gestructureerde objecten zijn in dit geval deze objecten zijn pakket, bestand en service. In Puppet-terminologie noemen we deze objecten bronnen ( bronnen) en eventuele Puppet-configuratiespecificaties bestaan ​​uit deze bronnen en de afhankelijkheden daartussen.

Een normale Puppet-installatie bevat tientallen of zelfs honderden van deze stukjes code, die we klassen noemen ( klassen); We slaan deze klassen op schijf op in bestanden die manifesten worden genoemd, en we groeperen ook logisch gerelateerde klassen in groepen die modules worden genoemd ( modules). U hebt bijvoorbeeld mogelijk een ssh-module met deze ssh-klasse en andere logisch gerelateerde klassen, samen met de mysql-, apache- en sudo-modules.

De meeste interactie met Puppet vindt plaats met behulp van schelp of altijd draaiende HTTP-services, maar er zijn ook grafische interfaces voor het uitvoeren van taken zoals het verwerken van rapporten. Puppet Labs levert ook commerciële Puppet-softwareproducten die web-GUI's gebruiken.

Het eerste Puppet-prototype werd ontwikkeld in de zomer van 2004 en de volledige ontwikkeling van het project begon in februari 2005. Het is oorspronkelijk ontworpen en ontwikkeld door Luke Kanies, een systeembeheerder met uitgebreide ervaring met het ontwikkelen van kleine tools, maar geen ervaring met het ontwikkelen van projecten met meer dan 10.000 regels code. In wezen leerde Luke Kanies programmeervaardigheden tijdens de ontwikkeling van het Puppet-project, wat de architectuur van het project zowel positief als negatief beïnvloedde.

Puppet is in eerste instantie en vooral ontwikkeld als een hulpmiddel voor systeembeheerders om hun leven gemakkelijker te maken, waardoor ze hun werk sneller, efficiënter en met minder fouten kunnen doen. De eerste belangrijke innovatie om dit principe te implementeren waren de hierboven beschreven hulpbronnen, namelijk Puppet-primitieven; ze kunnen tussen besturingssystemen worden overgedragen terwijl ze implementatiedetails abstract weergeven, waardoor de gebruiker kan nadenken over de resultaten van het werk in plaats van hoe deze te bereiken. Deze reeks primitieven werd geïmplementeerd op Puppet's Resource Abstraction Layer.

Marionetbronnen moeten uniek zijn voor een bepaald knooppunt. U kunt slechts één pakket hebben met de naam "ssh", één service met de naam "sshd" en één bestand met de naam "/etc/ssh/sshd_config". Deze beperking voorkomt onderlinge conflicten tussen verschillende delen van uw configuraties en u wordt zich al vroeg in het configuratieproces bewust van deze conflicten. We verwijzen naar deze bronnen met hun typen en namen, d.w.z. Pakket en Service. U kunt een pakket en een dienst met dezelfde naam hebben omdat het verschillende typen zijn, maar geen twee pakketten of diensten met dezelfde naam.

De tweede belangrijke innovatie in Puppet is de mogelijkheid om direct afhankelijkheden tussen bronnen te specificeren. Eerder gebruikte tools waren bedoeld om individuele taken uit te voeren zonder rekening te houden met de relaties tussen deze taken; Puppet was het eerste hulpmiddel dat expliciet stelde dat afhankelijkheden een fundamenteel onderdeel zijn van uw configuraties, die op hun beurt dienovereenkomstig moeten worden gemodelleerd. Het creëerde een grafiek van hulpbronnen en hun afhankelijkheden als een van de belangrijkste gegevenstypen, en bijna alle poppenacties waren afhankelijk van deze grafiek (een catalogus genoemd), de hoekpunten en randen.

Het laatste belangrijke onderdeel van Puppet is de configuratietaal. Deze taal is declaratief en is meer bedoeld voor het beschrijven van de configuratie dan voor volwaardig programmeren - het herhaalt bijna volledig het Nagios-configuratieformaat, maar is ook onder aanzienlijke invloed ontstaan ​​uit de talen van CFEngine en Ruby.

De functionele componenten van Puppet zijn gebaseerd op twee leidende principes: het moet zo eenvoudig mogelijk te gebruiken zijn, waarbij bruikbaarheid prioriteit krijgt boven functies; en het zou ook eerst ontwikkeld moeten worden in de vorm van een raamwerk en daarna een applicatie, zodat, indien gewenst, externe ontwikkelaars de mogelijkheid zullen hebben om hun applicaties te creëren op basis van Puppet-softwarecomponenten. Het was duidelijk dat dit naast het raamwerk breed toepasbaar was kwaliteit applicatie, maar de ontwikkelaars waren nog steeds primair gefocust op het raamwerk, niet op de applicatie. Veel mensen geloven nog steeds dat Puppet de applicatie zelf is, en niet het raamwerk waarop deze is geïmplementeerd.

Na het bouwen van zijn eerste Puppet-prototype werd Luke een over het algemeen goede Perl-ontwikkelaar met enige shell-scripting-ervaring en enige C-ervaring, voornamelijk opgedaan door het werken met het CFEngine-systeem. Bovendien had hij ervaring met het bouwen van parseersystemen voor eenvoudige talen, nadat hij twee van dergelijke systemen had ontwikkeld die in kleine tools konden worden uitgevoerd, en het CFEngine-parseersysteem helemaal opnieuw had ontwikkeld om het gemakkelijker te onderhouden (deze code is niet naar het project overgebracht). vanwege kleine onverenigbaarheden).

De beslissing om een ​​dynamische taal te gebruiken om Puppet te implementeren werd vrij snel genomen vanwege de aanzienlijk hogere productiviteit en distributie van ontwikkelaars van dit type talen, maar de keuze zelf bleek best lastig. De eerste prototypes in Perl werden afgewezen, dus werden experimenten uitgevoerd om andere talen te vinden. Er is geprobeerd gebruik te maken Python-taal, maar Luke vond deze taal aanzienlijk in tegenspraak met zijn kijk op de wereld. Nadat Luke een vriend had horen praten over de voordelen van de nieuwe taal, probeerde hij Ruby te gebruiken en maakte hij binnen vier uur een werkend prototype. Toen de volledige ontwikkeling van Puppet begon, was de Ruby-taal vrijwel onbekend, dus de beslissing om deze te gebruiken was een groot risico, maar in dit geval speelde de productiviteit van de ontwikkelaar opnieuw een beslissende rol bij de taalkeuze. Het belangrijkste onderscheidende kenmerk van de Ruby-taal, althans van Perl, was het gemak waarmee niet-hiërarchische klassenrelaties konden worden gecreëerd, terwijl de taal niet in tegenspraak was met het kritische denken van de ontwikkelaar Luke.

Stel jezelf voor in de rol systeembeheerder, verantwoordelijk voor het behoud van de functionaliteit van honderden machines met besturingssystemen zoals UNIX. Elk daarvan vereist configuratie en periodieke updates en monitoring, maar van veel daarvan wordt verwacht dat ze vergelijkbare functies vervullen. Twee derde bestaat uit werkstations, nog een paar zijn routers, de rest bestaat uit verschillende webservers en gegevensopslag. Vraag: hoe al deze zaken te beheren?

Het eenvoudigste antwoord is om eenvoudigweg verbinding te maken met elk van hen via SSH en de nodige wijzigingen aan te brengen. Deze methode heeft echter twee problemen. Ten eerste is het zeer arbeidsintensief. Ten tweede zal de beheerder voortdurend veel eentonige acties moeten uitvoeren (om bijvoorbeeld OpenOffice.org op alle werkstations bij te werken, moet u dezelfde opdrachten enkele tientallen keren uitvoeren). U kunt proberen dit probleem te vermijden door verschillende scripts te schrijven die verbinding maken met elke machine zelf en vooraf geschreven opdrachten uitvoeren. Maar ook hier wachten ons problemen. Scripts zullen voortdurend moeten worden aangepast om aan elke taak te voldoen, scripts zullen rekening moeten houden met verschillen in besturingssystemen en versies, en er zal lange tijd moeten worden gedebugd voordat ze op draaiende machines kunnen worden toegepast. Over het algemeen geen camilleaux.

Het juiste antwoord is het gebruik van zogenaamde systemen afstandsbediening configuraties, waarvan de beroemdste vertegenwoordigers zijn open systemen Cfengine en Puppet. Dergelijke systemen nemen alle verantwoordelijkheden op zich om de machineconfiguratie in de gewenste vorm te brengen, waarbij de beheerder alleen de eindstatus van het systeem in een speciale taal hoeft te beschrijven (bijvoorbeeld een beschrijving van welke pakketten in het besturingssysteem moeten worden geïnstalleerd, welke regels moeten worden toegevoegd aan configuratiebestanden, welke opdrachten moeten worden uitgevoerd, enz.). Hierna ontvangen alle knooppunten zelf informatie over de vereiste status van de server en voeren ze een automatische configuratie van het systeem uit. Dankzij dit mechanisme kunnen nieuwe machines volledig worden geconfigureerd zonder menselijke tussenkomst, en kunnen bestaande machines opnieuw worden geconfigureerd door slechts een paar regels aan de statusbeschrijving toe te voegen.

Marionet?

Puppet is ontwikkeld door Luke Kanies, die de beperkingen van Cfengine beu was en besloot om helemaal opnieuw een betere versie te maken. Als u Cfenfine al hebt gebruikt, zult u Puppet waarschijnlijk een handiger en krachtiger systeem vinden. De staatstaal van Puppet is op een hoger niveau en flexibeler, zodat beheerders zich geen zorgen hoeven te maken over zaken als het schrijven van afzonderlijke regels voor elk besturingssysteem of gedetailleerde beschrijving het uitvoeren van triviale handelingen. Met Puppet kun je je concentreren op wat Wat hij wil doen, in plaats van hoe hij het moet doen (om bijvoorbeeld een bepaald pakket te installeren op een van de besturingssystemen die door het systeem worden ondersteund, volstaat het om letterlijk een paar regels te schrijven met de tekst "Installeer dit programma", in plaats van te beschrijven de opdrachten die nodig zijn om het te installeren). Marionet is ingeschreven in eenvoudige taal Ruby, waardoor het vrij eenvoudig is om het aan een specifieke taak aan te passen en de functionaliteit ervan uit te breiden (meegeleverd flexibel systeem plug-ins). Bovendien is Puppet, in tegenstelling tot het ontwikkelingsmodel van Cfengine, dat in wezen rond één persoon draait, geëvolueerd geweldige gemeenschap enthousiastelingen die verbeteringen aanbrengen in de code, configuratievoorbeelden delen en documentatie schrijven.

Over het algemeen komt Puppet over als een moderner en goed ontworpen systeem. Net als Cfengine ondersteunt het vrijwel alle moderne UNIX-achtige besturingssystemen (inclusief MacOS X), en kan het ook in de Cygwin-omgeving bovenop Windows draaien. De afhankelijkheidslijst bevat alleen de Ruby-interpreter en de Factor-tool, dus er zouden geen problemen moeten zijn met de installatie (om eerlijk te zijn, de afhankelijkheidslijst van Cfengine is zelfs nog korter).

Bestandsserver

Veel taken beheer op afstand kan niet worden opgelost zonder extra bestanden naar de machines te kopiëren. Dit kunnen vooraf voorbereide configuraties zijn, webpagina's voor Apache, pakketten die niet in de officiële repository staan, en nog veel meer. Om het proces van het overbrengen van deze bestanden naar externe knooppunten te vergemakkelijken, bevat Puppet een bestandsserver.

Bestandsserverinstellingen worden opgeslagen in het bestand /etc/puppet/fileserver.conf. Om Puppet te dwingen de inhoud van een specifieke map aan clients te leveren, moet je er een paar regels in plaatsen:

Pad = /var/puppet/files staat *.server.com toe

Deze twee regels geven aan dat de map /var/puppet/files toegankelijk moet zijn voor alle hosts in het server.com-domein. We kunnen ook de volledige domeinnaam van een toegestane machine of het IP-adres ervan specificeren, en ook ongewenste domeinen afsnijden met behulp van de deny-richtlijn. Elk bestand in die map kan vervolgens met behulp van de bestandsbron naar de client worden verplaatst. Bijvoorbeeld:

Bestand ("/etc/httpd/conf/httpd.conf": source => "puppet://httpd/httpd.conf", mode => 644, )

Het httpd.conf-bestand dat zich op de server in de map /var/puppet/files/httpd bevindt, wordt naar de doelmachine gekopieerd langs het pad dat is opgegeven in de bronnaam.

Conclusies

In dit artikel hebben we er heel erg naar gekeken een klein deel Marionet-functies. In feite is dit een zeer complex systeem, dat alleen volledig kan worden beschreven op de pagina's van een boek. Tegelijkertijd is Puppet heel eenvoudig te configureren en te onderhouden, vooral omdat je op internet veel voorbeelden van de configuratie ervan kunt vinden.

Nog niet zo lang geleden keken we op de pagina's van het tijdschrift naar het Cfengine-systeem voor configuratiebeheer op afstand voor UNIX-machines, dat het leven van een systeembeheerder aanzienlijk vereenvoudigt door de stappen voor het configureren van veel netwerkknooppunten te automatiseren. Maar hoe handig Cfengine ook is, het heeft veel nadelen die een systeem genaamd Puppet niet heeft.

Stel je voor dat je de rol speelt van een systeembeheerder, verantwoordelijk voor het onderhouden van de functionaliteit van honderden machines met besturingssystemen van het UNIX-type. Elk van hen vereist configuratie, periodieke updates en monitoring, en er wordt aangenomen dat veel van hen vergelijkbare functies vervullen.

Twee derde bestaat uit werkstations, nog een paar zijn routers en de rest bestaat uit verschillende webservers en gegevensopslag. Vraag: hoe al deze zaken te beheren? Het eenvoudigste antwoord is om eenvoudigweg verbinding te maken met elk van hen via SSH en de nodige wijzigingen aan te brengen. Deze methode heeft echter twee problemen. Ten eerste is het zeer arbeidsintensief. Ten tweede zal de beheerder voortdurend veel eentonige acties moeten uitvoeren (om bijvoorbeeld OpenOffice.org op alle werkstations bij te werken, moet u dezelfde opdrachten enkele tientallen keren uitvoeren). U kunt proberen dit probleem te vermijden door verschillende scripts te schrijven die verbinding maken met elke machine zelf en vooraf geschreven opdrachten uitvoeren. Maar ook hier wachten u problemen.

Scripts zullen voortdurend moeten worden aangepast om ze aan elke taak aan te passen; Scripts zullen rekening moeten houden met verschillen in besturingssystemen en versies, en er zullen lange tijd fouten moeten worden gedebugd voordat ze op draaiende machines kunnen worden toegepast. Over het algemeen niet als een fout. Het juiste antwoord is het gebruik van zogenaamde externe configuratiebeheersystemen, waarvan de bekendste vertegenwoordigers de open source-systemen Cfengine en Puppet zijn. Dergelijke systemen nemen alle verantwoordelijkheden op zich om de machineconfiguratie in de gewenste vorm te brengen, waarbij de beheerder alleen de eindstatus van het systeem in een speciale taal hoeft te beschrijven (bijvoorbeeld een beschrijving van welke pakketten in het besturingssysteem moeten worden geïnstalleerd, welke regels moeten worden toegevoegd aan configuratiebestanden, welke opdrachten moeten worden uitgevoerd, enz.). Hierna ontvangen alle knooppunten zelf informatie over de vereiste status van de server en voeren ze een automatische configuratie van het systeem uit. Dankzij dit mechanisme kunnen nieuwe machines volledig worden geconfigureerd zonder menselijke tussenkomst, en kunnen bestaande machines opnieuw worden geconfigureerd door slechts een paar regels aan de statusbeschrijving toe te voegen.

Marionet?

We hebben al een heel artikel gewijd aan het Cfengine-systeem, dus vandaag zullen we ons concentreren op het Puppet-systeem, dat heel goed zijn ideologische opvolger kan worden genoemd. Puppet is ontwikkeld door Luke Kanies, die de beperkingen van Cfengine beu was en besloot om helemaal opnieuw een betere versie te maken. Als u Cfenfine al hebt gebruikt, zult u Puppet waarschijnlijk een handiger en krachtiger systeem vinden. De staatstaal van Puppet is van een hoger niveau en flexibeler, zodat beheerders zich geen zorgen hoeven te maken over zaken als het schrijven van afzonderlijke regels voor elk besturingssysteem of over het uitvoeren van triviale acties. Puppet zorgt ervoor dat de meester zich kan concentreren op wat hij wil doen, in plaats van hoe hij het moet doen (om bijvoorbeeld een specifiek pakket op een van de ondersteunde besturingssystemen van het systeem te installeren, hoeft u alleen maar letterlijk een paar regels te schrijven met de tekst "Installeer dit programma " in plaats van de opdrachten te beschrijven die nodig zijn voor de installatie ervan). Marionet is eenvoudig geschreven Ruby-taal, waardoor het gemakkelijk is om het aan een specifieke taak aan te passen en de functionaliteit ervan uit te breiden (er is een flexibel systeem van plug-ins beschikbaar).

Bovendien heeft Puppet, in tegenstelling tot het ontwikkelingsmodel van Cfengine, dat in wezen om één persoon draait, een grote gemeenschap van enthousiastelingen die verbeteringen aan de code aanbrengen, configuratievoorbeelden delen en documentatie schrijven.

Over het algemeen komt Puppet over als een moderner en goed ontworpen systeem. Net als Cfengine ondersteunt het vrijwel alle moderne UNIX-achtige besturingssystemen (inclusief MacOS X), en kan het ook in de Cygwin-omgeving bovenop Windows draaien. De afhankelijkheidslijst bevat alleen de Ruby-interpreter en de Factor-tool, dus er zouden geen problemen moeten zijn met de installatie (om eerlijk te zijn, de afhankelijkheidslijst van Cfengine is zelfs nog korter).

Installatie

Net als Cfengne is Puppet een client-serversysteem dat bestaat uit een controleserver en slaafknooppunten. De server slaat een beschrijving op van de eindstatus van de knooppunten (wat in Puppet-termen een manifest wordt genoemd) en wacht tot ze verbinding maken. Elk half uur (standaard) maakt de client verbinding met de server, ontvangt van deze een beschrijving van de eindstatus, vergelijkt deze met de huidige en, als deze en/of de beschreven status is gewijzigd, configureert hij het systeem opnieuw, en vervolgens gaat slapen. De communicatie wordt uitgevoerd via een gecodeerd kanaal, dus aanvallen op basis van vervanging van de statusbeschrijving zijn uitgesloten (maar als een aanvaller de server overneemt, zijn alle knooppunten onder zijn controle).

Puppet is opgenomen in de repositories van alle populaire distributies, dus het installeren ervan zou niet moeilijk moeten zijn. Op Debian/Ubuntu kan de Puppet-client bijvoorbeeld als volgt worden geïnstalleerd:

$ sudo apt-get installatiepop

En de server is als volgt:

$ sudo apt-get install puppet puppetmaster

De client- en serverconfiguratiebestanden worden opgeslagen in de map /etc/puppet. De belangrijkste hiervan is het bestand /etc/puppet/manifests/site.pp, dat het manifest bevat.

Het slaat een beschrijving van de statussen op en zou alleen op de server moeten bestaan. Laten we, voor het gemak van foutopsporing, er een eenvoudige configuratie aan toevoegen:

klassewachtwoord(
bestand("/etc/passwd":
eigenaar => wortel,
groep => wortel,
modus => 644,
}
}
knooppunt standaard(
inclusief wachtwoord
}

Deze regels beschrijven de status waarin de eigenaar van het bestand /etc/passwd root moet zijn en de rechten ervan zijn ingesteld op 644. We zullen het manifestbestandsformaat nader bekijken in de volgende sectie. Het tweede belangrijkste bestand is /etc/puppet/puppet.conf. Het bepaalt de configuratie van de server en clients, dus het moet aanwezig zijn op alle machines die in het Puppet-netwerk zijn georganiseerd. In Ubuntu bevat dit bestand de minimaal noodzakelijke en in de meeste gevallen voldoende instellingen. Hieronder staan ​​ze met commentaar:

# vi /etc/puppet/puppet.conf
# Standaard mappaden
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Facter-toollocatie,
# gebruikt om informatie over het besturingssysteem te verkrijgen
factpath=$vardir/lib/facter
# Synchroniseer plug-ins
# (geïnstalleerde plug-ins op de server - ze worden naar clients gekopieerd)
pluginsync=waar
# Catalogus met sjablonen (lees er hieronder over)
templatedir=$confdir/sjablonen
# Synchronisatie met etckeeper
# (wie weet, zal het begrijpen, anderen hebben het niet nodig)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Het configuratiebestand kan het volgende bevatten groot aantal verschillende opties, waarover informatie kan worden verkregen door een standaardconfiguratie te genereren:

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

De standaard clientconfiguratie wordt gegenereerd met een ander commando:

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

De bestanden fileserver.conf en auth.conf worden gebruikt om de bestandsserver (lees hierover in de sectie “Bestandsserver”) en authenticatie te configureren. Het heeft nog geen zin om ze aan te raken. Zodra de configuratie is voltooid, moet de Puppet-server opnieuw worden opgestart:

$ sudo /etc/init.d/puppetmaster opnieuw opstarten

Daarna is hij klaar om verzoeken van klanten te accepteren. Zonder een ondertekend certificaat kan geen enkele client het manifest van de server ontvangen en de machine configureren.

Daarom moeten we de Puppet-clients in testmodus draaien, zodat ze hun certificaten ter ondertekening naar de server kunnen sturen (dit kan overigens op alle machines tegelijkertijd worden gedaan met behulp van de shmux-tool):

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

We keren terug naar de server en ontvangen een lijst met certificaten die klaar zijn om te ondertekenen:

$ sudo puppetca --lijst

Selecteer een host uit de lijst en onderteken het certificaat:

$ sudo puppetca --sign nomad.grinder.com

Of we ondertekenen alles in één keer:

$ sudo puppetca --sign --all

Nu kun je clients in gevechtsmodus lanceren. Maar eerst moet u de naam van de Puppet-server in het configuratiebestand invoeren (standaard is de naam eenvoudigweg marionet):

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

Lancering van klanten:

$ sudo /etc/init.d/puppet start

Beschrijvingstaal vermelden

Zoals hierboven vermeld, gebruikt Puppet zijn eigen taal om de eindtoestand te beschrijven besturingssysteem, met behulp waarvan de systeembeheerder aangeeft in welke vorm de OS-componenten moeten worden gebracht om de gewenste staat te bereiken. Dit is een nogal complexe taal, die niettemin veel eenvoudiger is dan welke programmeertaal dan ook. Als je op zijn minst oppervlakkig bekend bent met de bash-scripttaal, zul je de Puppet-taal gemakkelijk begrijpen. Het belangrijkste element van de taal zijn de bronnen die worden gebruikt om te beschrijven naar welke vorm een ​​van de OS-componenten moet worden geconverteerd. De volgende eenvoudige bron beschrijft bijvoorbeeld de gewenste status van het bestand /etc/passwd:

# vi /etc/puppet/manifests/site.pp
bestand("/etc/passwd":
eigenaar => "root"
}

Hier is het bestand het resourcetype. Er zijn er in totaal enkele tientallen, variërend van bronnen die bestanden beheren, zoals in dit voorbeeld, tot pakketten en services. De regel /etc/passwd is de naam van de bron.

Bij het bestandstype is de naam hetzelfde als het pad naar het bestand, maar bij sommige andere typen kan de naam willekeurig zijn. De regel eigenaar => "root" beschrijft het instellen van het eigenaarattribuut op root, dat wil zeggen dat er staat dat de eigenaar opgegeven bestand er moet een beheerder zijn.

Elk type bron heeft zijn eigen set attributen die kunnen worden gewijzigd, plus er zijn speciale meta-attributen die in elke bron kunnen worden gebruikt. Een van de belangrijke eigenschappen van bronnen is het vermogen om er verbinding mee te maken. Dit kan worden gebruikt om afhankelijkheidsketens te vormen. Volgende invoer maakt een /etc/group resource aan die afhankelijk is van de /etc/passwd resource (afhankelijkheden worden gespecificeerd met behulp van het require meta attribuut):

# vi /etc/puppet/manifests/site.pp
bestand("/etc/groep":
vereisen => Bestand["/etc/passwd"],
eigenaar => "root",
}

Dit betekent dat de bron /etc/group alleen kan worden geconfigureerd (naar de beschreven vorm gebracht) als de bron /etc/passwd is geconfigureerd. Hulpbronnen kunnen worden gegroepeerd in verzamelingen hulpbronnen die klassen worden genoemd. Dit is nodig om bronnen die qua betekenis en type taak vergelijkbaar zijn, te combineren in één abstracte bron. Voor het gemak kunnen we bijvoorbeeld installatie en lancering combineren nginx-webserver in één abstracte bron met dezelfde naam:

# vi /etc/puppet/manifests/site.pp
klasse nginx(
package("nginx":
zorgen => geïnstalleerd
}
service("nginx":
zorgen => rennen,
vereisen => Pakket["nginx"],
}
}

Hier wordt het pakketresourcetype gebruikt om het nginx-pakket op het systeem te installeren, en wordt service gebruikt om de service met dezelfde naam te starten. Met require dwingen we het systeem de service alleen te starten als het pakket met succes is geïnstalleerd. Het gemak van lessen is dat ze ook kunnen worden opgenomen afhankelijk van:

# vi /etc/puppet/manifests/site.pp
service("inktvis":
zorgen => rennen,
vereisen => Klasse["nginx"],
}

Net als in echte OOP-talen kunnen klassen van elkaar erven en attributen overschrijven:

# vi /etc/puppet/manifests/site.pp
klassewachtwoord(
bestand("/etc/passwd":
eigenaar => "root",
groep => "root",
}
}
klasse passwd-bsd erft passwd (
Bestand["/etc/passwd"] (groep => "wiel" )
}

Hier wordt de klasse passwd-bsd overgenomen van passwd om het groepsattribuut van de bron /etc/passwd te overschrijven (op BSD-systemen behoort /etc/passwd tot wiel groep, dus hebben we voor dergelijke systemen een aparte klasse gemaakt). Later zullen we kijken naar een meer correcte en voor de hand liggende manier het selecteren van alternatieve attribuutwaarden met behulp van voorwaarden.

Variabelen zijn een van de integrale componenten van elke programmeertaal, en Puppet heeft ze ook. Variabelen beginnen met een $-teken en kunnen elk getal, tekenreeks of Booleaanse waarde bevatten (waar, onwaar):

$want_apache = waar
$apache_version = "2.2.14"

Eén van de krachtigste eigenschappen Poppentaal Gerelateerd aan variabelen is de integratie met de factermachine-informatietool. Dit hulpprogramma retourneert alle machinespecifieke informatie in de vorm van sleutel-waardeparen, die in Puppet worden omgezet in variabelen met dezelfde naam. Samen met voorwaardelijke instructies in de Puppet-taal kunnen ze worden gebruikt om resourcekenmerken te wijzigen, afhankelijk van de eigenschappen van de machine.

De hierboven beschreven passwd-klasse kan bijvoorbeeld eenvoudig worden herschreven automatische selectie attribuut afhankelijk van het besturingssysteemtype (in dit geval is de klasse zelf niet langer nodig):

# vi /etc/puppet/manifests/site.pp
bestand("/etc/passwd":
eigenaar => "root",
groep => $kernel ? (
Linux => "root",
FreeBSD => "wiel",
},
}

Afhankelijk van op welk besturingssysteem dit fragment van het manifest zal worden geanalyseerd, zal de waarde van het groepsattribuut root of wheel zijn. Naast de voorwaardelijke operator ondersteunt de Puppet-taal ook de caseselectie-operator, die kan worden gebruikt om een ​​bepaalde bron te creëren, afhankelijk van de waarde van een variabele:

# vi /etc/puppet/manifests/site.pp
case $besturingssysteem (
redhat: (service("httpd": zorg ervoor dat => actief))
debian: (service("apache": sure => actief))
standaard: ( service ("apache2": verzekeren =>
rennen))
}

Deze code definieert verschillende opties resource-type service, afhankelijk van het besturingssysteem (de namen van services in verschillende Linux-distributies kunnen verschillen, dus welke service Puppet moet worden uitgevoerd, moet voor elk ervan afzonderlijk worden gespecificeerd).

De standaardoptie wordt gebruikt als de waarde van de variabele niet overeenkomt met een van de voorgaande opties. Naast de eerder besproken brontypen bestand, pakket en service ondersteunt Puppet een groot aantal andere, inclusief de gemaakte externe ontwikkelaars soorten hulpbronnen. Hun gedetailleerde beschrijving, inclusief voorbeelden, ondersteunde attributen en functies, kunt u vinden in officiële documentatie- http://docs.puppetlabs.com/references/stable/type.html. Hieronder vindt u een lijst en een korte beschrijving van de meest gebruikte:

Populaire typen Puppet-bronnen

• cron - beheer cron-taken
• exec - voer scripts en opdrachten uit
• bestand - bestandsbeheer
• bestandsbucket - back-up bestanden
• groep - groepsbeheer
• host - beheer vermeldingen in het bestand /etc/hosts
• interface - configuratie van netwerkinterfaces
• mount - bestandssystemen mounten
• melden - stuur een bericht naar het Puppet-logbestand
• pakket - pakketbeheer
• service - servicemanagement
• sshkey - beheer SSH-sleutels
• netjes - bestanden verwijderen afhankelijk van de omstandigheden
• gebruiker - gebruikersbeheer
• zones - Solaris-zonebeheer

Het tweede belangrijkste element van de Puppet-taal, na bronnen, zijn knooppunten. Met hun hulp kan de beheerder beschrijven op welke machines bepaalde bronnen en klassen moeten worden toegepast. Met andere woorden, het is een manier om een ​​individuele configuratie te specificeren voor elk van de machines die deelnemen aan het Puppet-netwerk. Het eenvoudigste voorbeeld van een knooppunt wordt gegeven aan het begin van het artikel in de sectie ‘Installatie’:

# vi /etc/puppet/manifests/site.pp
knooppunt standaard(
inclusief wachtwoord
}

Dit is de definitie van het standaardknooppunt, dat de bron/klasse passwd omvat. De standaardnaam betekent "alle andere knooppunten", dus de passwd-bron/klasse die ergens hierboven is gedefinieerd, zal op elk van deze knooppunten worden geconfigureerd. Trefwoord include wordt hier voor het gemak gebruikt; in feite kunnen alle klassen en bronnen rechtstreeks in de knooppuntbeschrijving worden beschreven, maar dit wordt niet aanbevolen. Naast de standaardwaarde kunt u ook de knooppuntnaam opgeven netwerknaam machine (dan worden alle bronnen beschreven in het knooppunt alleen op deze machine geconfigureerd), of een willekeurige naam (dan kan dit knooppunt worden overgenomen door een ander knooppunt). Laten we, om te begrijpen hoe dit allemaal samenwerkt met klassen en bronnen, eens kijken naar een voorbeeld van een kant-en-klaar Puppet-manifest dat wordt gebruikt om twee netwerkmachines(webserver en NTP-server):

# vi /etc/puppet/manifests/site.pp
# Een SSH-server installeren en draaien
klasse sshd(
pakket ( openssh-server: verzekeren => geïnstalleerd )
dienst(sshd:
naam => $besturingssysteem? (
fedora => "sshd",
debian => "ssh",
standaard => "sshd",
},
inschakelen => waar,
zorgen => rennen,
}
}
# Apache installeren en uitvoeren
klasse httpd(
pakket ( httpd: verzekeren => geïnstalleerd )
dienst(httpd:
inschakelen => waar,
zorgen => rennen,
}
}
# Een NTP-server installeren en starten
klasse ntpd(
pakket (ntp-server: zorg ervoor dat => geïnstalleerd)
dienst (
ntp-server:
inschakelen => waar,
zorgen => rennen,
}
}
# Het basisknooppunt, alleen gebruikt als ouder van alle andere
knooppuntbasis(
inclusief sshd
}
# Het knooppunt waar de webserver zich zal bevinden
knooppunt web.server.com erft basis (
inclusief httpd
}
# NTP-serverknooppunt
knooppunt ntp.server.com erft basis (
inclusief ntpd
}

Deze ogenschijnlijk eenvoudige configuratie doet heel veel: het installeert en Apache starten op een machine met het adres web.server.com en om een ​​NTP-server op de machine te installeren en uit te voeren ntp.server.com. Bovendien installeren beide machines een SSH-server. Het is onwaarschijnlijk dat deze configuratie zelfs maar voor één beheerder geschikt is; het zal serieus verbeterd moeten worden om te leren hoe je servers correct configureert, nieuwe configuraties en andere bestanden ontvangt van de hoofdpuppetserver.

Het laat echter duidelijk de kracht van Puppet zien. Met behulp van een eenvoudige configuratie hebben we ervoor gezorgd dat de machines zelf de benodigde software installeerden en uitvoerden en deze in werkende staat hielden (als de server crasht, zal Puppet zelf opnieuw configureren om de systemen in de vereiste staat te brengen).

Bestandsserver

Veel beheertaken op afstand kunnen niet worden opgelost zonder extra bestanden naar de machines te kopiëren. Dit kunnen vooraf voorbereide configuraties zijn, webpagina's voor Apache, pakketten die niet in de officiële repository staan, en nog veel meer. Om het proces van het overbrengen van deze bestanden naar externe hosts te vergemakkelijken, bevat Puppet een bestandsserver.

Bestandsserverinstellingen worden opgeslagen in het bestand /etc/puppet/fileserver.conf. Om Puppet te dwingen de inhoud van een specifieke map aan clients te leveren, moet je er een paar regels in plaatsen:

# vi /etc/puppet/fileserver.conf
pad = /var/puppet/files
sta *.server.com toe

Deze twee regels geven aan dat de map /var/puppet/files toegankelijk moet zijn voor alle hosts in het server.com-domein. Bovendien kunnen we de volledige domeinnaam van een toegestane machine of het IP-adres ervan specificeren, en ook ongewenste domeinnamen afsnijden met behulp van de deny-richtlijn. Elk bestand in die map kan vervolgens met behulp van de bestandsbron naar de client worden verplaatst. Bijvoorbeeld:

# vi /etc/puppet/manifests/site.pp
file("/etc/httpd/conf/httpd.conf":
source => "puppet://httpd/httpd.conf",
modus => 644,
}

Het bestand httpd.conf, dat zich op de server in de map /var/puppet/files/httpd bevindt, wordt naar de doelmachine gekopieerd langs het pad dat is opgegeven in de bronnaam.

Conclusies

In dit artikel hebben we een heel klein deel van de mogelijkheden van Puppet besproken. In feite is dit een complex systeem, dat alleen volledig kan worden beschreven op de pagina's van een boek. Tegelijkertijd is Puppet heel eenvoudig te configureren en te onderhouden, vooral omdat je op internet veel voorbeelden van de configuratie ervan kunt vinden.

Info

• Puppet gebruikt het HTTP-protocol, zodat het onder een webserver kan worden uitgevoerd om de prestaties te verbeteren.
• Puppet kan worden gebruikt om één lokale machine automatisch te configureren en te onderhouden.
• Door Puppet, net(pxe-install) en zelfbouwende installatie-images te combineren, kunt u een volledig zelfconfigurerend netwerk van machines creëren dat met slechts één opdracht kan worden ingezet.
• Veel mensen gebruiken Puppet in hun werk. grote bedrijven, zoals Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution en SugarCRM.

Koppelingen

• http://docs.puppetlabs.com - Marionetdocumentatie
• http://docs.puppetlabs.com/guides/lingual_tutorial.html - Volledige beschrijving Poppentaal
• http://docs.puppetlabs.com/references/stable/type.html - Brontypen