Poppentaal. Gecentraliseerde configuratie van UNIX-systemen met Puppet. Structuur beschrijving bron

Wanneer het aantal servers dat u beheert minder dan tien is - zelden denkt iemand na over hun gecentraliseerd beheer, is dit misschien niet vereist. Als er tientallen servers zijn - gecentraliseerd beheer De software en configuraties zijn uiterst nuttig. Als er honderden en duizenden servers zijn, is het van vitaal belang. Er zijn veel van dit soort programma's, bijvoorbeeld: Chef, CFEngine, ... Dit is de laatste die in dit bericht zal worden besproken.

Puppet wordt terecht beschouwd als een van de betere oplossingen zoals dat. Het wordt gebruikt door bedrijven zoals Google, Citrix en rode Hoed... Dit is wat het is client-server-toepassing geschreven in de programmeertaal Ruby, die in twee smaken wordt gedistribueerd:

• Marionet Open source- geheel gratis versie
• Puppet Enterprise - gratis in een configuratie van maximaal 10 servers, verder is de aankoop van licenties vereist

Overweeg om de Puppet Open Source-server en -agent te installeren, die aanwezig zijn in de pakketten van de meeste moderne distributies. Vervolgens zullen we ons concentreren op Ubuntu 12.04 Precise Pangolin.

Server onderdeel Marionet heet poppenspeler, laten we de installatie ervan starten:

: ~ # apt-get install puppetmaster

En nu de klant:

: ~ # apt-get install puppet

In het clientconfiguratiebestand /etc/pop/pop.conf het is noodzakelijk om over de server te vertellen door de volgende sectie toe te voegen:

Server = puppet.local report = true pluginsync = false

Het is beter om pluginsync in de beginfase uit te schakelen.

Laten we de puppet-client starten om een ​​certificaatverzoek te maken:

: ~ # puppetd --verbose --test info: Aanmaken van een nieuwe SSL-sleutel voor linux.local info: Caching certificaat voor ca info: Aanmaken van een nieuw SSL-certificaatverzoek voor linux.local info: Certificaatverzoek vingerafdruk (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 de certificaataanvraag is ontvangen en zo ja, het certificaat uitschrijven:

: ~ # 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"

We herhalen vorige stap op de klant:

: ~ # puppetd --verbose --test info: Caching-certificaat voor linux.local info: Ophalen van plugin-info: Caching certificate_revocation_list voor ca info: Caching-catalogus voor linux.local info: Toepassen van configuratieversie "1356278451" info: Statusbestand maken / var / lib / puppet / state / state.yaml opmerking: voltooide catalogusrun in 0,02 seconden

Geweldig, alles werkt. Laten we verder gaan met het maken van het eerste manifest. Manifesten, het zijn ook configuraties, worden beschreven in een speciale declaratieve taal. Laten we meteen wennen aan het goede, gebruik een modulaire structuur en klassen. Laten we bijvoorbeeld een module schrijven die het bestand up-to-date houdt / etc / gastheren op al onze servers.

Laten we eens kijken waar Puppet naar modules zoekt:

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

Mappen maken 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

Klasse-hosts (# puppet.local host ("puppet.local": zorgen => "present", target => "/ etc / hosts", ip => "192.168.0.1", host_aliases => "puppet",) # linux.local host ("linux.local": zorg ervoor => "present", target => "/ etc / hosts", ip => "192.168.0.2", host_aliases => "linux",))

Standaard zoekt marionet naar een bestand /etc/pop/manifests/site.pp om de configuratie te laden, laten we deze converteren naar het volgende formulier:

Standaard node (inclusief hosts)

Het manifest op de server controleren:

: ~ # puppet apply --verbose /etc/puppet/manifests/site.pp info: toepassen van configuratieversie "1356281036" melding: / Stage // Host / zorgen voor: aangemaakte info: FileBucket toevoeging (md5) melding: / Stage // Host / zorg ervoor: melding gemaakt: voltooide catalogusrun in 0,03 seconden

Op de klant:

: ~ # 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: Configuratie toepassen versie "1356283380" info: FileBucket toevoegen (md5) melding: / Stage / Hosts / Host / zorgen: gemaakt melding: / Stage / Hosts / Host / zorgen: aangemaakt melding: 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 ervoor hebben gezorgd dat alles werkt, laten we de start van de service toe, in / etc / standaard / marionet verandering:

# Start marionet op boot? BEGIN = ja

We beginnen de dienst

: ~ # dienstpopje start

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

Ze spraken over wat configuratiebeheer is en hoe u deze technologie in uw infrastructuur kunt implementeren.

Opmerking: Tutorial is gemaakt op Ubuntu 14.04 en Apache.

Deze zelfstudie helpt u bij het voorbereiden van geautomatiseerde serverorkestratie met behulp van de Puppet-configuratiebeheertool. Je raakt bekend met de basisbegrippen, syntaxis en functies van Puppet. Als resultaat krijgt u een volledig geautomatiseerde eenvoudige implementatie, die uit de volgende stappen bestaat:

• De pakketindex bijwerken.
• Apache installeren.
• Maak een aangepaste hoofdmap voor documenten.
• Een index.html-bestand erin maken.
• Een sjabloon toepassen om een ​​custom te installeren virtuele host.
• Start Apache opnieuw.

Opmerking: Deze tutorial is gericht op het maken van manifest - Puppet-scripts om de configuratie te automatiseren. Je kunt meer lezen over Puppet in de artikelen:

Begin van het werk

Voordat je begint met het ontwikkelen van je manifest, moet je bekend zijn met de basistermen van Puppet.

Marionet terminologie

• Puppet Master: De hoofdserver die de configuratie van de knooppunten beheert.
• Puppet-agent: een slave-knooppunt dat de master gehoorzaamt.
• Manifest: orkestratiescript.
• Bron: een codefragment dat de wijzigingen definieert die het systeem nodig heeft.
• Module: Een groep manifesten en andere bestanden, georganiseerd op een vooraf gedefinieerde manier, waardoor het gemakkelijker is om te delen en hergebruiken de orkestratie van de afzonderlijke delen.
• Klasse: Zoals bij elke conventionele programmeertaal, zijn klassen verantwoordelijk voor het organiseren en hergebruiken van delen van de orkestratie.
• Feiten: globale systeemvariabelen.
• Diensten: de status van een dienst wijzigen (start, stop, enz.).

Orchestration Puppet is ontwikkeld in de DSL-taal, die is gebaseerd op Ruby.

Bronnen

Puppet definieert taken met behulp van middelen. Bronnen kunnen pakketten, bestanden, services, gebruikers en opdrachten vertegenwoordigen. Ze kunnen een toestand hebben die zal leiden tot een verandering in het systeem als de toestand van de gedeclareerde bron afwijkt van: huidige toestand systemen. Een pakketbron met een geïnstalleerde status in het manifest zal bijvoorbeeld de installatie van het pakket starten als een dergelijk pakket nog niet eerder is geïnstalleerd. Zo'n bron ziet er als volgt uit:

pakket ("apache2":

zorg ervoor => "geïnstalleerd"

Met de exec-resource kunt u elk commando uitvoeren:

exec ("apt-get update":

command => ‘/ usr / bin / apt-get update’

Merk op dat apt-get update in het bovenstaande voorbeeld geen opdrachtdeclaratie is, maar een resource-ID. Vaak moet je in Puppet naar andere bronnen verwijzen, en daarom worden hun identifiers gebruikt.

Afhankelijkheid van bronnen

Bij het schrijven van manifesten is het belangrijk om te onthouden dat Puppet bronnen niet gebruikt in de volgorde waarin ze zijn gedefinieerd. Hulpbronnen moeten expliciet hun afhankelijkheid van elkaar definiëren, in anders het is onmogelijk om te begrijpen in welke volgorde de bronnen zullen worden gelezen en uitgevoerd, en of ze überhaupt zullen worden uitgevoerd.

Een voorbeeld is de volgende code; het definieert de afhankelijkheid van de resource, en alleen dan de resource zelf:

pakket ("python-software-eigenschappen":

zorg ervoor => "geïnstalleerd"

}
exec ("add-repository":

command => "/ usr / bin / add-apt-repository ppa: ondrej / php5 -y"
vereisen => Pakket ["python-software-eigenschappen"]

De optie Vereisen krijgt als parameter een link naar een andere bron. V in dit geval de pakketbron wordt gedefinieerd door het pakket python-software-properties.

Opmerking: Brondeclaraties beginnen met een kleine letter (exec, pakket) en afhankelijkheden beginnen met een hoofdletter (Exec, Pakket).

U moet bijvoorbeeld de ene taak vóór de tweede uitvoeren. Hiervoor wordt de voor-optie gebruikt.

pakket ("krul":

zorg ervoor => "geïnstalleerd"
voor => Exec ["script installeren"]

exec ("script installeren":

command => "/ usr / bin / curl http://example.com/some-script.sh"

Manifest formaat

Manifesten zijn verzamelingen bronnen met de .pp-extensie. Hieronder ziet u een voorbeeld van een eenvoudig manifest dat twee dingen doet: de pakketindex bijwerken en vim installeren.

exec ("apt-get update":

command => "/ usr / bin / apt-get update"

}
pakket ("vim":

zorg ervoor => "geïnstalleerd"
vereisen => Exec ["apt-get update"]

Opmerking: Aan het einde van deze handleiding vindt u: volledige code het poppenmanifest.

Een manifest schrijven

Variabelen

Variabelen kunnen overal in het manifest worden gedefinieerd. De meest voorkomende typen variabelen zijn strings en arrays van strings, maar Puppet ondersteunt ook andere typen.

Deze code definieert een variabele tekenreeks die later in het manifest kan worden gebruikt:

$ pakket = "vim"
pakket ($ pakket:

zorg ervoor => "geïnstalleerd"

Cycli

Loops worden meestal gebruikt om een ​​taak te herhalen met verschillende invoerwaarden. Dat wil zeggen, in plaats van 10 taken te maken om 10 verschillende pakketten te installeren, kunt u één taak maken en een lus gebruiken om de taak te herhalen om pakketten te installeren.

De eenvoudigste manier om een ​​lus in Puppet te definiëren is met een array, bijvoorbeeld:

$ packages = ["vim", "git", "curl"]
pakket ($ pakketten:

zorg ervoor => "geïnstalleerd"

Vanaf versie 4 ondersteunt Puppet extra paden om taken te herhalen. De onderstaande code doet hetzelfde als de vorige code, maar deze keer wordt elke iterator gebruikt. Deze optie maakt het gemakkelijker om resourceloops te maken:

$ pakketten.elk | String $ pakket | (
pakket ($ pakket:

zorg ervoor => "geïnstalleerd"

Voorwaardelijke uitdrukkingen gebruiken

Voorwaardelijke expressies kunnen worden gebruikt voor dynamische aanpassingen (bijvoorbeeld wanneer u op basis van een variabele of opdrachtuitvoer moet beslissen of u een taak wilt uitvoeren).

Puppet ondersteunt de meeste van voorwaardelijke structuren traditionele programmeertalen (bijvoorbeeld if / else en case-statements); daarnaast ondersteunen sommige bronnen (zoals exec) attributen die werken als conditionals, maar accepteren alleen de uitvoer van een commando als voorwaarde.

Stel dat u een opdracht wilt uitvoeren op basis van feiten. In een dergelijk geval moet u, om de waarde van een variabele te controleren, een van de ondersteunde ondersteunde voorwaardelijke structuren gebruiken, bijvoorbeeld if / else:

if $ osfamily! = "Debian" (

waarschuwing ("Dit manifest wordt niet ondersteund op dit besturingssysteem.")

melden ("Goed om te gaan!" :)

Ook worden voorwaardelijke expressies vaak gebruikt in IT-automatisering wanneer de uitvoering van de ene opdracht afhankelijk is van de uitvoer van een andere opdracht. Gebruik in dergelijke gevallen alleen als of tenzij, zoals weergegeven in het onderstaande voorbeeld. De volgende opdracht wordt alleen uitgevoerd als de / bin / welke php-uitvoer succesvol is:

command => "/ bin / echo PHP is hier geïnstalleerd> /tmp/test.txt",
onlyif => "/ bin / welke php"

Evenzo zal de instructie tenzij een opdracht alleen uitvoeren als de opdracht tenzij is uitgevoerd.

command => "/ bin / echo PHP is hier NIET geïnstalleerd> /tmp/test.txt",
tenzij => "/ bin / welke php"

Sjablonen gebruiken

Sjablonen worden vaak gebruikt in configuratiebestanden en stellen u in staat variabelen en andere functies toe te voegen die deze bestanden veelzijdiger en herbruikbaarder maken. Puppet ondersteunt twee sjabloonformaten

• Embedded Puppet (EPP): werkt alleen met Puppet 4+.
• Ingebedde robijn (ERB)

Hieronder ziet u een voorbeeld van een ERB-sjabloon voor het maken van een virtuele Apache-host die een variabele gebruikt om te maken: hoofdmap deze gastheer:

ServerAdmin [e-mail beveiligd]
DocumentRoot<%= @doc_root %>
>
ToestaanAlles overschrijven
Vereisen dat alles is verleend

Om de sjabloon toe te passen, moeten we een bestandsresource maken die de inhoud van de sjabloon weergeeft met behulp van de sjabloonmethode. Gebruik een patroon als dit om de standaard virtuele Apache-host te vervangen:

zorgen voor => "aanwezig",
inhoud => sjabloon ("apache / vhost.erb")

In dit geval zoekt Puppet naar de vhost.tpl-sjabloon in de map apache / templates.

Servicedefinitie

Status van serviceresources systeemdienst(bijvoorbeeld stoppen of opnieuw starten).

Laten we eens kijken naar het vorige voorbeeld van een sjabloon voor het maken van een virtuele Apache-host. Om ervoor te zorgen dat Apache opnieuw wordt opgestart na het wijzigen van de virtuele host, moet u een serviceresource maken. Dit wordt als volgt gedaan:

dienst ("apache2":

zorgen voor => rennen,
inschakelen => waar

Gebruik de meldingsoptie om de bron te identificeren.

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

zorgen voor => "aanwezig",
inhoud => sjabloon ("vhost.erb"),
informeren => Dienst ["apache2"]

Voorbeeld manifest

Je kunt nu alle code voor deze tutorial verzamelen in één manifest dat de Apache-installatie op Ubuntu 14.04 zal automatiseren.

Opmerking: een bijgewerkte versie van het manifest is te vinden op Github. Deze map bevat ook een Vagrant-bestand waarmee u het manifest kunt testen op een lichtgewicht installatie met behulp van virtuele machine Zwerver.

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

command => "/ usr / bin / apt-get update"

}
pakket ("apache2":

zorg voor => "geïnstalleerd",
vereisen => Exec ["apt-get update"]

}
bestand ($ doc_root:

zorgen voor => "map",
eigenaar => "www-gegevens",
groep => "www-gegevens",
modus => 644

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

zorgen voor => "aanwezig",
source => "marionet: ///modules/main/index.html",
vereisen => Bestand [$ doc_root]

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

zorgen voor => "aanwezig",
inhoud => sjabloon ("main / vhost.erb"),
informeren => Dienst ["apache2"],
vereisen => Pakket ["apache2"]

}
dienst ("apache2":

zorgen voor => rennen,
inschakelen => waar

• De eerste regel bevat de variabele $ doc_root, die later wordt gebruikt om de resource te declareren.
• Regels 3-5: De exec-resource voert de opdracht apt-get update uit.
• Regels 7-10: De pakketbron installeert het apache2-pakket, hangt af van apt-get update. Dat wil zeggen dat deze resource alleen wordt uitgevoerd als de vereiste resource wordt uitgevoerd.
• Regels 12-17: De bestandsresource maakt een nieuwe hoofdmap aan. De bestandsresource kan bestanden en mappen maken, sjablonen toepassen en lokale bestanden kopiëren naar externe server... Deze taak kan in elke fase van de orkestratie worden uitgevoerd, dus er zijn geen afhankelijkheden voor nodig.
• Regels 19-23: Een andere bestandsbron kopieert het bestand index.html naar de hoofdmap op de server. Met de bronparameter kan Puppet het bronbestand vinden. Deze code is gebaseerd op de verwerkingsmethode lokale bestanden in Marionet. De Github-repository bevat een directorystructuur waarmee Puppet deze bron kan vinden. De hoofdmap moet worden gemaakt voordat deze bron wordt uitgevoerd, dus de optie Vereisen wordt hier gebruikt.
• Regels 25-30: Deze bestandsbron past de Apache-sjabloon toe en start de service opnieuw. V dit voorbeeld orkestratie wordt georganiseerd met behulp van de hoofdmodule (dus de bronsjabloon zal main / vhost.erb zijn). De optie Vereist zorgt ervoor dat de bron alleen wordt uitgevoerd als het apache2-pakket is geïnstalleerd.
• Regels 32-35: De serviceresource herstart de apache2-service.

Gevolgtrekking

Puppet is een krachtige tool voor configuratiebeheer die DSL gebruikt om serverbronnen te beheren en taken te automatiseren. Deze taal biedt aanvullende bronnen die flexibiliteit in de orkestratie bieden.

Wanneer u met Puppet werkt, is het belangrijk om te onthouden dat bronnen niet altijd in dezelfde volgorde worden gelezen en uitgevoerd als waarin ze zijn gedefinieerd. Wees heel voorzichtig bij het maken van uw uitvoeringsketen.

Labels:,

Marionet is een platformonafhankelijk framework waarmee sysadmins veelvoorkomende taken kunnen uitvoeren met behulp van code. Met de code kunt u uitvoeren: verschillende taken van het installeren van nieuwe programma's tot het controleren van bestandsrechten of het bijwerken van gebruikersaccounts. Marionet uitstekend, niet alleen tijdens de eerste installatie van het systeem, maar ook overal levenscyclus systemen. In de meeste gevallen marionet gebruikt in client-/serverconfiguratie.

Dit gedeelte toont de installatie en configuratie Marionet in client-/serverconfiguratie. Dit eenvoudige voorbeeld laat zien hoe te installeren Apache gebruik makend van Marionet.

Installatie

Voor installatie: Marionet voer in terminal:

Sudo apt-get install puppetmaster

Voer op de clientcomputer (of machines) het volgende in:

Sudo apt-get install puppet

Maatwerk

Voordat je marionet configureert, wil je misschien een item toevoegen DNS CNAME voor marionet.voorbeeld.com, waar voorbeeld.com is uw domein. Standaard klanten Marionet controleer DNS voor puppet.example.com als de naam van de serverpop ( Poppenspeler). Zie Domain Name Service voor meer details over het gebruik van DNS.

Als u niet van plan bent DNS te gebruiken, kunt u vermeldingen toevoegen aan het bestand / etc / hosts op de server en de client. Bijvoorbeeld in het bestand / etc / hosts Marionet server toevoegen:

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

Op elke Marionet client een vermelding voor de server toevoegen:

192.168.1.16 meercat.example.com meerkat marionet

Vervang de IP-adressen en domeinnamen uit het voorbeeld door uw werkelijke adressen en server- en clientnamen.

Laten we nu wat bronnen opzetten voor apache2... Maak een bestand /etc/pop/manifests/site.pp met daarin het volgende:

Pakket ("apache2": zorgen => geïnstalleerd) service ("apache2": verzekeren => waar, inschakelen => waar, vereisen => Pakket ["apache2"])

Knooppunt "meercat02.example.com" (inclusief apache2)

Vervangen meercat02.voorbeeld.com naar de echte naam van je Marionet cliënt.

De laatste stap voor deze simpele Marionet de server herstart de service:

Sudo /etc/init.d/puppetmaster herstart

Nu verder Marionet alles is geconfigureerd op de server en het is tijd om de client te configureren.

Laten we eerst de service instellen Marionet agent te lopen. Bewerken / etc / standaard / marionet die de waarde vervangt BEGIN op de Ja:

Sudo /etc/init.d/puppet start

Terug naar Marionet server om het clientcertificaat te ondertekenen met de opdracht:

Sudo puppetca --teken meercat02.example.com

Controleren / var / log / syslog voor eventuele configuratiefouten. Als alles goed is gegaan, het pakket apache2 en zijn afhankelijkheden worden geïnstalleerd op Marionet cliënt.

Dit voorbeeld is heel eenvoudig en laat niet veel functies en voordelen zien. Marionet... Voor Extra informatie kijk

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

18.1. Invoering

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

Puppet is een hulpmiddel voor het configureren en onderhouden van uw computers; met behulp van zijn eenvoudige configuratietaal, kun je Puppet vertellen hoe je je machines wilt configureren, en dan zal het ze opnieuw configureren als dat nodig is om aan je specificatie te voldoen. Als u deze specificatie in de loop van de tijd wijzigt vanwege omstandigheden zoals pakketupdates, nieuwe gebruikers toegevoegd of configuratie-updates, zal Puppet uw machineconfiguratie automatisch bijwerken zodat deze overeenkomt met de specificatie. Als ze al goed zijn geconfigureerd, zal Puppet geen werk doen.

Over het algemeen voert Puppet alle mogelijke acties uit die gericht zijn op het gebruik van de functies het bestaande systeem om hun werk te doen; d.w.z. op distributies gebaseerd op RedHat-technologieën, zal het yum gebruiken om pakketten te beheren en init.d om diensten te beheren, terwijl het in OS X zal gebruiken dmg-hulpprogramma voor pakketbeheer en gelanceerd voor servicebeheer. Een van de fundamentele doelen van het Puppet-project is het vervullen van: nuttig werk ongeacht of je de Puppet-projectcode of het systeem zelf hiervoor gebruikt, dus het volgende: systeemnormen zijn kritisch.

Het Puppet-project is gebouwd op basis van ervaring met vele andere tools. In de wereld van open source-applicaties broncode de grootste invloed op de ontwikkeling werd uitgeoefend door het CFEngine-project, dat de eerste configuratietool was algemeen doel open source, evenals het ISconf-project, dat het make-hulpprogramma gebruikte om al het werk te doen, wat op zijn beurt resulteerde in Speciale aandacht expliciet beschreven afhankelijkheden in het systeem. In de commerciële softwarewereld kan Puppet worden gezien als een concurrent van BladeLogic- en Opsware-projecten (die vervolgens door meer dan grote bedrijven), die elk goed verkochten toen Puppet voor het eerst werd geïntroduceerd, maar elk van deze tools werd verkocht aan de CEO's van grote bedrijven, in plaats van dat ze werden ontwikkeld om te voldoen aan de onmiddellijke vereisten voor hoogwaardige sysadmin-tools. Het Puppet-project is ontworpen om problemen aan te pakken die vergelijkbaar zijn met die van deze tools, terwijl het zich richt op totaal verschillende gebruikers.

Als eenvoudig voorbeeld methode om Puppet te gebruiken, hieronder is een codefragment om ervoor te zorgen dat de Secure Shell (SSH)-service correct is geïnstalleerd en geconfigureerd: class ssh (pakket (ssh: zorgen => geïnstalleerd) bestand ("/ etc / ssh / sshd_config": source = > "marionet: /// modules / ssh / sshd_config", zorg voor => aanwezig, vereist => Pakket) service (sshd: zorg voor => actief, vereist =>, Pakket]))

Deze code zorgt ervoor dat het pakket wordt geïnstalleerd, het bestand op de juiste locatie wordt geplaatst en de service wordt gestart. Opgemerkt moet worden dat we de afhankelijkheden tussen bronnen hebben beschreven, dus we zullen elk werk altijd in de juiste volgorde uitvoeren. Deze klasse kan aan elk knooppunt worden gekoppeld om een ​​bepaalde configuratie binnen dat knooppunt toe te passen. Houd er rekening mee dat: bouw blokken Marionet configuratie zijn gestructureerde objecten, in dit geval pakket-, bestands- en serviceobjecten. In Puppet-terminologie noemen we deze objecten bronnen ( bronnen) en alle configuratiespecificaties van Puppet bestaan ​​uit deze bronnen en de onderlinge afhankelijkheden.

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 bundelen ook logisch gerelateerde klassen in groepen die modules worden genoemd ( modules). U hebt bijvoorbeeld een ssh-module met deze ssh-klasse en andere logisch gerelateerde klassen tot uw beschikking, samen met de mysql-, apache- en sudo-modules.

De meeste interactie met Puppet wordt gedaan met behulp van schelp of altijd met HTTP-services, maar er zijn grafische interfaces om taken uit te voeren, zoals het verwerken van rapporten. Puppet Labs biedt ook commerciële softwareproducten om met Puppet te werken die grafische webinterfaces 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 in het ontwikkelen van kleine tools, maar geen ervaring in projecten met meer dan 10.000 regels code. Kortom, Luke Kanies heeft programmeervaardigheden opgedaan tijdens de ontwikkeling van het Puppet-project, wat de architectuur van het project zowel positief als negatief beïnvloedde.

Puppet is vanaf het begin ontwikkeld en vooral als hulpmiddel voor systeembeheerders om hun leven gemakkelijker te maken, sneller, efficiënter en met minder fouten te werken. De eerste sleutelinnovatie om dit principe te implementeren waren de hierboven beschreven middelen, die Puppet-primitieven zijn; ze kunnen worden overgedragen tussen besturingssystemen terwijl ze de details van de implementatie abstract presenteren, zodat de gebruiker kan nadenken over de resultaten van het werk in plaats van hoe deze te bereiken. Deze reeks primitieven is geïmplementeerd in de Puppet Resource Abstraction Layer.

Marionettenbronnen moeten uniek zijn voor: gegeven knoop... U kunt slechts één pakket met de naam "ssh", één service met de naam "sshd" en één bestand met de naam "/ etc / ssh / sshd_config" hebben. Deze beperking voorkomt onderlinge conflicten tussen verschillende delen van uw configuraties en u zult deze conflicten al vroeg in het configuratieproces herkennen. We verwijzen naar deze bronnen met hun type en naam, d.w.z. Pakket en Service. U kunt een pakket en service gebruiken met dezelfde naam als waarnaar ze verwijzen verschillende soorten maar niet twee pakketten of diensten met dezelfde naam.

De tweede belangrijke innovatie in Puppet is de mogelijkheid directe indicatie afhankelijkheden tussen bronnen. Eerder gebruikte tools gericht op het uitvoeren van individuele taken zonder rekening te houden met de relaties tussen deze taken; Puppet was de eerste tool die expliciet verklaarde dat afhankelijkheden het primaire onderdeel zijn van uw configuraties, die op hun beurt op de juiste manier moeten worden gemodelleerd. Hij maakte een grafiek van bronnen en hun afhankelijkheden als een van de belangrijkste gegevenstypen en bijna alle Puppet-acties waren afhankelijk van deze grafiek (een catalogus genoemd), zijn hoekpunten en randen.

De laatste een belangrijk onderdeel Puppet is een configuratietaal. Deze taal is declaratief en is meer bedoeld voor het beschrijven van configuratie dan voor volwaardige programmering - het herhaalt bijna volledig het Nagios-configuratieformaat, maar is ook gemaakt onder de aanzienlijke invloed van talen van CFEngine en Ruby.

In het midden van functionele componenten Puppet heeft twee principes als leidraad bij de ontwikkeling: het moet zo gebruiksvriendelijk mogelijk zijn, waarbij gebruiksgemak de voorkeur heeft boven functies; en ook moet het allereerst worden ontwikkeld in de vorm van een raamwerk en ten tweede - een applicatie, dus, indien gewenst externe ontwikkelaars zullen hun applicaties kunnen maken op basis van Puppet-softwarecomponenten. Het was duidelijk dat er naast het framework ook behoefte was aan een veelgebruikte kwaliteitsapplicatie, maar het ging de ontwikkelaars toch vooral om het framework, niet om de applicatie. Veel mensen geloven nog steeds dat Puppet deze applicatie is, en niet het raamwerk waarop het is geïmplementeerd.

Na het bouwen van het eerste Puppet-prototype werd Luke een over het algemeen goede Perl-ontwikkelaar met weinig ervaring in shellscripting en weinig C-ervaring, voornamelijk met het CFEngine-systeem. Daarnaast had hij ervaring met het creëren van data-parsingsystemen voor eenvoudige talen, die hij had gekregen door twee van dergelijke systemen te ontwikkelen om als onderdeel van kleine tools te werken, en door een data-parsingsysteem voor CFEngine helemaal opnieuw te ontwikkelen om de ondersteuning ervan vereenvoudigen (deze code is niet overgebracht naar het project vanwege kleine incompatibiliteiten).

De beslissing om een ​​dynamische taal te gebruiken om Puppet te implementeren werd vrij snel genomen vanwege de aanzienlijk hogere productiviteit van ontwikkelaars en distributie. van dit type talen, maar de keuze zelf bleek best moeilijk. De originele Perl-prototypes werden weggegooid, dus werden experimenten uitgevoerd om andere talen te vinden. Er is een poging gedaan om Python-taal maar Luke vond deze taal significant in strijd met zijn kijk op de wereld. Nadat hij een vriend had horen praten over de voordelen van de nieuwe taal, probeerde Luke Ruby uit en bouwde hij in vier uur een werkend prototype. Op het moment dat de volledige ontwikkeling van Puppet begon, was de Ruby-taal praktisch onbekend, dus de beslissing om het te gebruiken was beladen met een groot risico, maar in dit geval speelde de productiviteit van de ontwikkelaar opnieuw een beslissende rol bij de keuze van de taal . de belangrijkste keurmerk Ruby taal minstens van Perl was het gemakkelijk om niet-hiërarchische klassenrelaties te creëren, terwijl de taal niet in tegenspraak was met de denkactiviteit van de ontwikkelaar Luke, die cruciaal was.

Stel jezelf voor in de rol van systeembeheerder die verantwoordelijk is voor het in stand houden van de gezondheid van honderden of andere machines met besturingssystemen zoals UNIX. Elk van hen vereist configuratie, periodieke updates en monitoring, maar van veel ervan wordt verwacht dat ze vergelijkbare functies vervullen. Tweederde zijn werkstations, nog een paar routers en de rest zijn verschillende webservers en datawarehouses. De vraag is: hoe deze hele economie te managen?

Het eenvoudigste antwoord is om gewoon met iedereen verbinding te maken via SSH en enter nodige veranderingen... Deze methode heeft echter twee problemen. Ten eerste is het erg arbeidsintensief. Ten tweede zal de beheerder voortdurend veel eentonige acties moeten uitvoeren (om bijvoorbeeld OpenOffice.org op alle werkstations bij te werken, zal hij dezelfde opdrachten enkele tientallen keren moeten uitvoeren). U kunt dit probleem proberen te vermijden door verschillende scripts te schrijven die zelf verbinding maken met elke machine en vooraf geschreven opdrachten uitvoeren. Maar ook hier wachten ons problemen. De scripts zullen constant moeten worden aangepast om ze voor elke taak aan te passen, de scripts zullen rekening moeten houden met het verschil in besturingssystemen en versies, ze zullen lange tijd moeten worden gedebugd voordat ze worden toegepast op draaiende machines. Over het algemeen geen camilfo.

Het juiste antwoord is om de zogenaamde systemen te gebruiken afstandsbediening configuraties, waarvan de bekendste zijn: open systemen Cfengine en Puppet. Dergelijke systemen nemen alle verantwoordelijkheden op zich om de machineconfiguratie naar de juiste soort vraagt ​​van de beheerder alleen een beschrijving van de eindstatus van het systeem op speciale taal(bijvoorbeeld een beschrijving van welke pakketten op het besturingssysteem moeten worden geïnstalleerd, aan welke regels moet worden toegevoegd) config bestanden welke commando's moeten worden uitgevoerd, enz.). Daarna zullen alle nodes zelf informatie over de vereiste status van de server ontvangen en het systeem automatisch configureren. Dankzij dit mechanisme kunnen nieuwe machines volledig worden afgesteld zonder menselijke tussenkomst en kunnen bestaande machines opnieuw worden geconfigureerd met slechts een paar regels toestandbeschrijvingen.

Marionet?

Puppet is ontwikkeld door Luke Kanies, die de beperkingen van Cfengine beu was en besloot om vanaf het begin een betere versie te maken. Als je Cfenfine al eerder hebt gebruikt, zul je Puppet waarschijnlijk een gebruiksvriendelijker en krachtiger systeem vinden. De staatsbeschrijvingstaal van Puppet is hoger en flexibeler, zodat de beheerder zich geen zorgen hoeft te maken over zaken als het schrijven van afzonderlijke regels voor elk type besturingssysteem of gedetailleerde beschrijving het uitvoeren van triviale handelingen. Met Puppet kun je je concentreren op wat hij wil het doen, in plaats van het te doen (om bijvoorbeeld een bepaald pakket op een van de ondersteunde besturingssystemen te installeren, volstaat het om letterlijk een paar regels te schrijven met de tekst "Installeer dit programma", in plaats van de commando's te beschrijven die nodig zijn om installeer het). Puppet is geschreven in een eenvoudige Ruby-taal, waardoor het gemakkelijk aan te passen is aan specifieke taak en de functionaliteit uitbreiden (een flexibel plug-in systeem is voorzien). Bovendien, in tegenstelling tot het Cfengine-ontwikkelingsmodel, dat eigenlijk om één persoon draait, heeft zich een grote gemeenschap van enthousiastelingen gevormd rond Puppet die bijdragen aan de code, configuratievoorbeelden delen en documentatie schrijven.

Over het algemeen lijkt Puppet een moderner en beter doordacht systeem te zijn met: goed design... Net als Cfengine ondersteunt het bijna alle moderne UNIX-achtige besturingssystemen (inclusief MacOS X) en kan het ook in Cygwin bovenop Windows draaien. De lijst met afhankelijkheden bevat alleen de Ruby-interpreter en de Factor-tool, dus er zouden geen problemen moeten zijn met de installatie (het is redelijk om te zeggen dat de lijst met Cfengine-afhankelijkheden zelfs nog korter is).

Bestanden server

Veel taken beheer op afstand kan niet worden opgelost zonder te kopiëren naar machines extra bestanden... 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.

Instellingen bestanden server opgeslagen in het bestand /etc/puppet/fileserver.conf. Om Puppet te dwingen de inhoud van een specifieke map aan klanten te leveren, moet je er verschillende regels in plaatsen:

Pad = / var / puppet / bestanden toestaan ​​* .server.com

Deze twee regels geven aan dat de directory / var / puppet / files toegankelijk moet zijn voor alle hosts in het server.com-domein. We kunnen ook de volledige aangeven Domeinnaam van de toegestane machine of zijn IP-adres, evenals de ongewenste afsnijden met behulp van de deny-richtlijn. Daarna kan elk bestand in deze map naar de client worden verplaatst met behulp van de bestandsresource. 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, zal naar de doelmachine worden gekopieerd langs het pad dat is opgegeven in de resourcenaam.

conclusies

In dit artikel hebben we een heel klein deel van de mogelijkheden van Puppet behandeld. In feite is het erg complex Systeem, die alleen volledig kan worden beschreven op de pagina's van het boek. Tegelijkertijd is Puppet heel eenvoudig te configureren en te onderhouden, vooral omdat je veel voorbeelden van de configuratie op het net kunt vinden.