Dukkespråk. Sentralisert konfigurasjon av UNIX-systemer ved bruk av Puppet. Ressursbeskrivelsesstruktur

Når antallet servere du administrerer er mindre enn ti - sjelden tenker noen på deres sentraliserte administrasjon, er dette kanskje ikke nødvendig. Når det er dusinvis av servere - sentralisert ledelse Programvaren og konfigurasjonene er ekstremt nyttige. Når det er hundrevis og tusenvis av servere, er det viktig. Det er mange programmer av denne typen, for eksempel: Chef, CFEngine, ... Dette er det siste som vil bli diskutert i dette innlegget.

Puppet regnes fortjent som en av de bedre løsninger slik. Den brukes av selskaper som Google, Citrix og Rød hatt... Dette er hva det er klient-server-applikasjon skrevet i Ruby programmeringsspråk, som er distribuert i to smaker:

• Dukke Åpen kilde- fullt gratis versjon
• Puppet Enterprise - gratis i en konfigurasjon på opptil 10 servere, krever videre kjøp av lisenser

Vurder å installere Puppet Open Source-serveren og agenten, som finnes i pakkene til de fleste moderne distribusjoner. Deretter vil vi fokusere på Ubuntu 12.04 Precise Pangolin.

Server del Dukke kalles dukke mester, la oss starte installasjonen fra den:

: ~ # apt-get install puppetmaster

Og nå klienten:

: ~ # apt-get install dukke

I klientens konfigurasjonsfil /etc/puppet/puppet.conf det er nødvendig å fortelle om serveren ved å legge til følgende seksjon:

Server = puppet.local rapport = true pluginsync = usant

Det er bedre å slå av pluginsync i det innledende stadiet.

La oss starte dukkeklienten for å lage en sertifikatforespørsel:

: ~ # puppetd --verbose --test info: Opprette en ny SSL-nøkkel for linux.local info: Bufresertifikat for ca info: Opprette en ny SSL-sertifikatforespørsel for linux.local info: Sertifikatforespørselsfingeravtrykk (md5): E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51 Avslutter; ingen sertifikat funnet og waitforcert er deaktivert

På serveren må du sjekke at sertifikatforespørselen er mottatt og i så fall skrive ut sertifikatet:

: ~ # puppetca --list "linux.local" (E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51): ~ # puppetca - -sign linux.local notis: Signert sertifikatforespørsel for linux.local notis: Fjerner fil Puppet :: SSL :: CertificateRequest linux.local på "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Vi gjentar forrige steg på klienten:

: ~ # puppetd --verbose --test info: Buffer sertifikat for linux.local info: Henter plugin info: Buffer certificate_revocation_list for ca info: Buffer katalog for linux.local info: Bruker konfigurasjonsversjon "1356278451" info: Oppretter tilstandsfil / var / lib / puppet / state / state.yaml varsel: Ferdig katalogkjøring på 0,02 sekunder

Flott, alt fungerer. La oss gå videre til å lage det første manifestet. Manifester, de er også konfigurasjoner, er beskrevet i et spesielt deklarativt språk. La oss venne oss til det gode med en gang, bruk en modulær struktur og klasser. La oss for eksempel skrive en modul som holder filen oppdatert / etc / verter på alle våre servere.

La oss sjekke hvor dukken leter etter moduler:

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

Lag kataloger for modulen din

: ~ # cd / etc / puppet / modules: ~ # mkdir-verter; cd-verter; mkdir manifesterer; cd manifesterer seg

Det første manifestet, også kjent som hovedmodulfilen, må kalles init.pp

Klasseverter (# puppet.local vert ("puppet.local": sikre => "present", target => "/ etc / hosts", ip => "192.168.0.1", host_aliases => "puppet",) # linux.local vert ("linux.local": sikre => "present", target => "/ etc / hosts", ip => "192.168.0.2", host_aliases => "linux",))

Som standard ser puppet etter en fil /etc/puppet/manifests/site.pp for å laste konfigurasjonen, la oss konvertere den til følgende skjema:

Nodestandard (inkluder verter)

Sjekker manifestet på serveren:

: ~ # puppet apply --verbose /etc/puppet/manifests/site.pp info: Bruker konfigurasjonsversjon "1356281036" varsel: / Stage // Vert / sikre: opprettet info: FileBucket adding (md5) notice: / Stage // Vert / sikre: opprettet varsel: Ferdig katalogkjøring på 0,03 sekunder

På klienten:

: ~ # ll / etc / hosts rw-r - r-- 1 root root 290 16. desember 19:10 / etc / hosts: ~ # puppetd --verbose --test info: Bufferkatalog for linux.local info: Bruker konfigurasjon versjon "1356283380" info: FileBucket legger til (md5) varsel: / Stage / Hosts / Host / sikre: opprettet varsel: / Stage / Hosts / Host / sikre: opprettet varsel: Ferdig katalog kjøres på 0,04 sekunder: ~ # ll / etc / hosts -rw-r - r-- 1 rotrot 551 23. desember 20:43 / etc / hosts

Etter at vi har forsikret oss om at alt fungerer, tillater vi oppstart av tjenesten, inn / etc / default / puppet endring:

# Starte dukke på støvelen? START = ja

Vi starter tjenesten

: ~ # tjeneste dukkestart

Puppet vil spørre puppetmaster-serveren hvert 30. minutt for konfigurasjonsendringer og, om nødvendig, justere systemet deretter.

De snakket om hva konfigurasjonsadministrasjon er og hvordan du implementerer denne teknologien i infrastrukturen din.

Merk: Opplæringen er laget på Ubuntu 14.04 og Apache.

Denne opplæringen hjelper deg med å forberede automatisert serverorkestrering ved å bruke Puppet-konfigurasjonsadministrasjonsverktøyet. Du vil bli kjent med de grunnleggende begrepene, syntaksen og funksjonene til Puppet. Som et resultat får du en helautomatisk enkel distribusjon, som består av følgende trinn:

• Oppdaterer pakkeindeksen.
• Installerer Apache.
• Opprett en tilpasset dokumentrotkatalog.
• Opprette en index.html-fil i den.
• Bruke en mal for å installere en egendefinert virtuell vert.
• Start Apache på nytt.

Merk: Denne opplæringen fokuserer på å lage manifest - Puppet-skript for å automatisere konfigurasjonen. Du kan lese mer om Puppet i artiklene:

Begynnelsen av arbeidet

Før du begynner å utvikle manifestet ditt, må du være kjent med grunnleggende Puppet-termer.

Dukketerminologi

• Puppet Master: Hovedserveren som administrerer konfigurasjonen av nodene.
• Puppet agent: en slavenode som adlyder mesteren.
• Manifest: Orkestreringsmanus.
• Ressurs: En kodebit som definerer endringene systemet trenger.
• Modul: En gruppe med manifester og andre filer, organisert på en forhåndsdefinert måte, som gjør det lettere å dele og gjenbruk dens individuelle orkestrering.
• Klasse: Som med alle konvensjonelle programmeringsspråk, er klassene ansvarlige for å organisere og gjenbruke deler av orkestreringen.
• Fakta: globale systemvariabler.
• Tjenester: endre statusen til en tjeneste (start, stopp osv.).

Orchestration Puppet er utviklet i DSL-språket, som er basert på Ruby.

Ressurser

Puppet definerer oppgaver ved hjelp av ressurser. Ressurser kan representere pakker, filer, tjenester, brukere og kommandoer. De kan ha en tilstand som vil føre til en endring i systemet dersom tilstanden til den deklarerte ressursen er forskjellig fra nåværende tilstand systemer. For eksempel vil en pakkeressurs med en installert tilstand i manifestet starte installasjonen av pakken hvis en slik pakke ikke har blitt installert tidligere. En slik ressurs ser slik ut:

pakke ("apache2":

sikre => "installert"

Exec-ressursen lar deg utføre en hvilken som helst kommando:

exec ("apt-get update":

kommando => '/ usr / bin / apt-get update'

Merk at apt-get update i eksemplet ovenfor ikke er en kommandoerklæring, men en ressursidentifikator. Ofte må du i Puppet referere til andre ressurser, og det er derfor identifikasjonene deres brukes.

Ressursavhengighet

Når du skriver manifester, er det viktig å huske at Puppet ikke bruker ressurser i den rekkefølgen de er definert. Ressurser må eksplisitt definere deres avhengighet av hverandre, i ellers det er umulig å forstå i hvilken rekkefølge ressursene skal leses og utføres, og om de i det hele tatt vil bli utført.

Et eksempel er følgende kode; den definerer avhengigheten til ressursen, og først da selve ressursen:

pakke ("python-programvare-egenskaper":

sikre => "installert"

}
exec ("add-repository":

kommando => "/ usr / bin / add-apt-repository ppa: ondrej / php5 -y"
krever => Pakke ["python-software-properties"]

Krev-alternativet mottar en kobling til en annen ressurs som en parameter. V i dette tilfellet pakkeressursen er definert av pakken python-software-properties.

Merk: Ressurserklæringer starter med en liten bokstav (exec, pakke), og avhengigheter starter med stor bokstav (Exec, Package).

Du må for eksempel få en oppgave til å kjøre før den andre. Før-alternativet brukes til dette.

pakke ("krøll":

sikre => "installert"
før => Exec ["installer script"]

exec ("installer skript":

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

Manifestformat

Manifester er samlinger av ressurser med .pp-utvidelsen. Nedenfor er et eksempel på et enkelt manifest som gjør to ting: oppdaterer pakkeindeksen og installerer vim.

exec ("apt-get update":

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

}
pakke ("vim":

sikre => "installert"
require => Exec ["apt-get update"]

Merk: På slutten av denne håndboken finner du full kode dukkemanifestet.

Å skrive et manifest

Variabler

Variabler kan defineres hvor som helst i manifestet. De vanligste variabeltypene er strenger og arrays av strenger, men Puppet støtter også andre typer.

Denne koden definerer en variabelstreng som senere kan brukes i manifestet:

$ pakke = "vim"
pakke ($ pakke:

sikre => "installert"

sykluser

Sløyfer brukes vanligvis til å gjenta en oppgave ved å bruke forskjellige inngangsverdier. Det vil si at i stedet for å lage 10 oppgaver for å installere 10 forskjellige pakker, kan du opprette en oppgave og bruke en løkke for å gjenta oppgaven for å installere eventuelle pakker.

Den enkleste måten å definere en loop i Puppet er med en matrise, for eksempel:

$ packages = ["vim", "git", "curl"]
pakke ($ pakker:

sikre => "installert"

Fra versjon 4 støtter Puppet ekstra stierå iterere over oppgaver. Koden nedenfor gjør det samme som den forrige koden, men denne gangen bruker den hver iterator. Dette alternativet gjør det enklere å lage ressursløkker:

$ packages.each | String $ pakke | (
pakke ($ pakke:

sikre => "installert"

Bruke betingede uttrykk

Betingede uttrykk kan brukes for dynamisk tilpasning (for eksempel når du må bestemme basert på en variabel eller kommandoutgang om du vil utføre en oppgave).

Puppet støtter det meste betingede strukturer tradisjonelle programmeringsspråk (for eksempel if / else og case statements); i tillegg støtter noen ressurser (som exec) attributter som fungerer som betingelser, men bare aksepterer utdata fra en kommando som en betingelse.

La oss si at du vil utføre en kommando basert på fakta. I et slikt tilfelle, for å sjekke verdien av en variabel, må du bruke en av de støttede betingede strukturene som støttes, for eksempel hvis / annet:

if $ osfamily! = "Debian" (

advarsel ("Dette manifestet støttes ikke på dette operativsystemet.")

gi beskjed ("Godt å gå!" :)

Betingede uttrykk brukes også ofte i IT-automatisering når utførelsen av en kommando avhenger av utdata fra en annen kommando. I slike tilfeller, bruk bare hvis eller med mindre, som vist i eksempelet nedenfor. Følgende kommando vil bare bli utført hvis / bin / som php-utdata er vellykket:

kommando => "/ bin / echo PHP er installert her> /tmp/test.txt",
onlyif => "/ bin / hvilken php"

På samme måte vil unless-setningen utføre en kommando bare hvis unless-kommandoen er utført.

kommando => "/ bin / echo PHP er IKKE installert her> /tmp/test.txt",
med mindre => "/ bin / hvilken php"

Bruke maler

Maler brukes ofte i konfigurasjonsfiler og lar deg legge til variabler og andre funksjoner som gjør disse filene mer allsidige og gjenbrukbare. Puppet støtter to malformater

• Embedded Puppet (EPP): fungerer bare med Puppet 4+.
• Embedded Ruby (ERB)

Nedenfor er et eksempel på en ERB-mal for å lage en virtuell Apache-vert som bruker en variabel til å lage rotkatalogen denne verten:

ServerAdmin [e-postbeskyttet]
DocumentRoot<%= @doc_root %>
>
Tillat Overstyr alle
Krev alle innvilget

For å bruke malen må vi lage en filressurs som gjengir innholdet i malen ved å bruke malmetoden. For å erstatte den standard virtuelle Apache-verten, bruk et mønster som dette:

sikre => "present",
innhold => mal ("apache / vhost.erb")

I dette tilfellet vil Puppet se etter vhost.tpl-malen i apache / templates-katalogen.

Tjenestedefinisjon

Tjenesteressurser endrer tilstand systemtjeneste(for eksempel stoppe eller starte det på nytt).

La oss se på det forrige eksemplet på en mal for å lage en virtuell Apache-vert. For å sikre at Apache starter på nytt etter å ha endret den virtuelle verten, må du opprette en tjenesteressurs. Dette gjøres slik:

tjeneste ("apache2":

sikre => kjører,
aktiver => sant

Bruk varslingsalternativet for å identifisere ressursen.

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

sikre => "present",
innhold => mal ("vhost.erb"),
varsle => Tjeneste ["apache2"]

Eksempel manifest

Du kan nå samle all koden for denne opplæringen i ett manifest som vil automatisere Apache-installasjonen på Ubuntu 14.04.

Merk: En oppdatert versjon av manifestet finnes på Github. Denne mappen inneholder også en Vagrant-fil som lar deg teste manifestet på en lett installasjon ved hjelp av virtuell maskin Vagrant.

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

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

}
pakke ("apache2":

sikre => "installert",
require => Exec ["apt-get update"]

}
fil ($ doc_root:

sikre => "katalog",
eier => "www-data",
gruppe => "www-data",
modus => 644

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

sikre => "present",
kilde => "puppet: ///modules/main/index.html",
krever => Fil [$ doc_root]

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

sikre => "present",
innhold => mal ("main / vhost.erb"),
varsle => Tjeneste ["apache2"],
krever => Pakke ["apache2"]

}
tjeneste ("apache2":

sikre => kjører,
aktiver => sant

• Den første linjen inneholder $ doc_root-variabelen, som senere brukes til å deklarere ressursen.
• Linje 3-5: Exec-ressursen kjører kommandoen apt-get update.
• Linjer 7-10: Pakkeressursen installerer apache2-pakken, avhenger av apt-get update. Det vil si at denne ressursen vil bli utført bare hvis den nødvendige ressursen er utført.
• Linje 12-17: Filressursen oppretter en ny rotkatalog. Filressursen kan lage filer og kataloger, bruke maler og kopiere lokale filer til ekstern server... Denne oppgaven kan utføres på alle stadier av orkestreringen, så den trenger ikke avhengigheter.
• Linje 19-23: En annen filressurs kopierer index.html-filen til rotkatalogen på serveren. Kildeparameteren lar Puppet finne kildefilen. Denne koden er basert på behandlingsmetoden lokale filer i Puppet. Github-depotet inneholder en katalogstruktur som lar Puppet finne denne ressursen. Rotkatalogen må opprettes før denne ressursen kjøres, så alternativet krever brukes her.
• Linje 25-30: Denne filressursen bruker Apache-malen og starter tjenesten på nytt. V dette eksemplet orkestrering er organisert ved hjelp av hovedmodulen (så kildemalen vil være main / vhost.erb). Krav-alternativet sikrer at ressursen kjøres bare hvis apache2-pakken er installert.
• Linje 32-35: Tjenesteressursen starter apache2-tjenesten på nytt.

Konklusjon

Puppet er et kraftig verktøy for konfigurasjonsadministrasjon som bruker DSL til å administrere serverressurser og automatisere oppgaver. Dette språket tilbyr tilleggsressurser som gir fleksibilitet i orkestreringen.

Når du arbeider med Puppet, er det viktig å huske at ressurser ikke alltid leses og utføres i samme rekkefølge som de er definert. Vær veldig forsiktig når du oppretter utførelseskjeden.

Tags:,

Dukke er et rammeverk på tvers av plattformer som lar systemadministratorer utføre vanlige oppgaver ved hjelp av kode. Koden lar deg utføre ulike oppgaver fra å installere nye programmer til å sjekke filtillatelser eller oppdatere brukerkontoer. Dukke utmerket ikke bare under den første installasjonen av systemet, men også hele veien Livssyklus systemer. I de fleste tilfeller marionett brukes i klient/serverkonfigurasjon.

Denne delen viser installasjon og konfigurasjon Dukke i klient/serverkonfigurasjon. Dette enkle eksemplet viser hvordan du installerer Apache ved hjelp av Dukke.

Installasjon

For installasjon Dukke skriv inn i terminal:

Sudo apt-get install puppetmaster

Skriv inn på klientmaskinen (eller maskinene):

Sudo apt-get install marionett

Tilpasning

Før du konfigurerer dukke, vil du kanskje legge til en oppføring DNS CNAME til puppet.example.com, hvor eksempel.com er ditt domene. Standard klienter Dukke sjekk DNS for puppet.example.com som serverdukkenavn ( Dukke mester). Se Domain Name Service for mer informasjon om bruk av DNS.

Hvis du ikke har tenkt å bruke DNS, kan du legge til oppføringer i / etc / hosts-filen på serveren og klienten. For eksempel i filen / etc / hosts Dukke server legge til:

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

På hver Dukke klient legg til en oppføring for serveren:

192.168.1.16 meercat.example.com meercat marionett

Erstatt IP-adressene og domenenavnene fra eksemplet med dine faktiske adresser og server- og klientnavn.

La oss nå sette opp noen ressurser for apache2... Opprett en fil /etc/puppet/manifests/site.pp som inneholder følgende:

Pakke ("apache2": sikre => installert) tjeneste ("apache2": sikre => sant, aktiver => sant, krever => Pakke ["apache2"])

Node "meercat02.example.com" (inkluder apache2)

Erstatte meercat02.example.com til det faktiske navnet på din Dukke klient.

Det siste trinnet for dette enkle Dukke serveren starter tjenesten på nytt:

Sudo /etc/init.d/puppetmaster restart

Nå på Dukke alt er konfigurert på serveren og det er på tide å konfigurere klienten.

Først, la oss sette opp tjenesten Dukke agent å kjøre. Rediger / etc / default / puppet erstatter verdien START på ja:

Sudo /etc/init.d/puppet start

Tilbake til Dukke server for å signere klientsertifikatet ved å bruke kommandoen:

Sudo puppetca --sign meercat02.example.com

Kryss av / var / log / syslog for eventuelle konfigurasjonsfeil. Hvis alt gikk bra, pakken apache2 og dens avhengigheter vil bli installert på Dukke klient.

Dette eksemplet er veldig enkelt og viser ikke mange funksjoner og fordeler. Dukke... Til tilleggsinformasjon se

Forfatter: Luke Kanies
Publiseringsdato: 2. mai 2012
Oversettelse: A. Panin
Oversettelsesdato: 27. august 2013

18.1. Introduksjon

Puppet er et administrasjonsverktøy for IT-infrastruktur utviklet med Ruby programmeringsspråk og brukes til å automatisere vedlikehold av datasenter og serveradministrasjon. Google-selskaper, Twitter, New York Stock Exchange og mange andre organisasjoner. Utviklingen av prosjektet er i hovedsak støttet av Puppet Labs-organisasjonen, som la grunnlaget for utviklingen. Puppet kan administrere fra 2 til 50 000 servere og vedlikeholdes av et team på én eller hundrevis av systemadministratorer.

Puppet er et verktøy for å konfigurere og vedlikeholde datamaskinene dine; ved å bruke det enkle konfigureringsspråket kan du fortelle Puppet hvordan du vil konfigurere maskinene dine, og deretter rekonfigurere dem etter behov for å matche spesifikasjonene dine. Når du endrer denne spesifikasjonen over tid på grunn av omstendigheter som pakkeoppdateringer, nye brukere lagt til eller konfigurasjonsoppdateringer, vil Puppet automatisk oppdatere maskinkonfigurasjonen slik at den samsvarer med spesifikasjonen. I tilfelle de allerede er riktig konfigurert, vil ikke Puppet gjøre noe arbeid.

Generelt utfører Puppet alle mulige handlinger rettet mot å bruke funksjonene det eksisterende systemetå gjøre jobben sin; det vil si at på distribusjoner basert på RedHat-teknologier, vil den bruke yum til å administrere pakker og init.d for å administrere tjenester, mens på OS X vil den bruke dmg-verktøyet for pakkehåndtering og lansert for tjenesteadministrasjon. Et av de grunnleggende målene for Puppet-prosjektet er å oppfylle nyttig arbeid uansett om du bruker Puppet-prosjektkoden eller selve systemet til dette, så følgende systemstandarder er kritiske.

Puppet-prosjektet er bygget på erfaring med mange andre verktøy. I en verden av åpen kildekode-applikasjoner kildekode den største innflytelsen på utviklingen ble gjort av CFEngine-prosjektet, som var det første konfigurasjonsverktøyet generelt formålåpen kildekode, samt ISconf-prosjektet, som brukte make-verktøyet til å gjøre alt arbeidet, som igjen resulterte i Spesiell oppmerksomhet til eksplisitt beskrevet avhengigheter i systemet. I den kommersielle programvareverdenen kan Puppet sees på som en konkurrent til BladeLogic- og Opsware-prosjekter (som senere ble kjøpt opp av mer enn store selskaper), som alle solgte godt da Puppet først ble introdusert, men hvert av disse verktøyene ble solgt til administrerende direktører i store selskaper, i stedet for å bli utviklet for å møte de umiddelbare kravene til sysadmin-verktøy av høy kvalitet. Puppet-prosjektet ble designet for å takle problemer som ligner på disse verktøyene, samtidig som de retter seg mot helt andre brukere.

Som enkelt eksempel metode for å bruke Puppet, nedenfor er en kodebit for å sikre at Secure Shell (SSH)-tjenesten er riktig installert og konfigurert: klasse ssh (pakke (ssh: sikre => installert) fil ("/ etc / ssh / sshd_config": kilde = > "puppet: /// modules / ssh / sshd_config", sørg for => tilstede, krever => Pakke) tjeneste (sshd: sikre => kjører, krever =>, Pakke]))

Denne koden sørger for at pakken blir installert, filen vil bli plassert på riktig plassering, og tjenesten vil starte. Det skal bemerkes at vi har beskrevet avhengighetene mellom ressurser, så vi vil alltid utføre alt arbeid i riktig rekkefølge. Denne klassen kan assosieres med hvilken som helst node for å bruke en gitt konfigurasjon innenfor den noden. Vær oppmerksom på at byggeklosser Dukkekonfigurasjon er strukturerte objekter, i dette tilfellet pakke-, fil- og tjenesteobjekter. I Puppet-terminologi kaller vi disse objektene ressurser ( ressurser) og eventuelle Puppet-konfigurasjonsspesifikasjoner består av disse ressursene og avhengighetene mellom dem.

En vanlig Puppet-installasjon vil inneholde dusinvis eller til og med hundrevis av disse kodebitene, som vi kaller klasser ( klasser); vi lagrer disse klassene på disk i filer kalt manifester, og vi samler også logisk relaterte klasser i grupper kalt moduler ( moduler). For eksempel kan du ha en ssh-modul med denne ssh-klassen og andre logisk relaterte klasser til din disposisjon sammen med mysql-, apache- og sudo-modulene.

Det meste av interaksjonen med Puppet gjøres ved hjelp av skall eller alltid kjører HTTP-tjenester, men det er det grafiske grensesnittå utføre oppgaver som å behandle rapporter. Puppet Labs tilbyr også kommersielle programvareprodukterå jobbe med Puppet som bruker grafiske webgrensesnitt.

Den første Puppet-prototypen ble utviklet sommeren 2004, og full utvikling av prosjektet startet i februar 2005. Det ble opprinnelig designet og utviklet av Luke Kanies, en systemadministrator med lang erfaring i å utvikle små verktøy, men ingen erfaring i prosjekter med mer enn 10 000 linjer med kode. I utgangspunktet fikk Luke Kanies programmeringsferdigheter under utviklingen av Puppet-prosjektet, noe som påvirket arkitekturen til prosjektet både positivt og negativt.

Puppet ble utviklet fra første stund og først og fremst som et verktøy for systemadministratorer for å gjøre livet enklere, for å få arbeidet gjort raskere, mer effektivt og med færre feil. Den første nøkkelinnovasjonen for å implementere dette prinsippet var ressursene beskrevet ovenfor, som er Puppet-primitiver; de kan overføres mellom operativsystemer mens de abstrakt presenterer implementeringsdetaljer, slik at brukeren kan tenke på resultatene av arbeidet i stedet for hvordan de skal oppnå dem. Dette settet med primitiver har blitt implementert på Puppet Resource Abstraction Layer.

Dukkeressurser må være unike for gitt node... Du kan bare ha en pakke kalt "ssh", en tjeneste kalt "sshd" og en fil med navnet "/ etc / ssh / sshd_config". Denne begrensningen forhindrer gjensidige konflikter mellom ulike deler av konfigurasjonene dine, og du vil gjenkjenne disse konfliktene tidlig i konfigurasjonsprosessen. Vi refererer til disse ressursene ved deres typer og navn, det vil si Pakke og Tjeneste. Du kan bruke en pakke og tjeneste med samme navn som de refererer til forskjellige typer men ikke to pakker eller tjenester med samme navn.

Den andre nøkkelinnovasjonen i Puppet er evnen direkte indikasjon avhengigheter mellom ressurser. Tidligere brukte verktøy rettet mot å utføre individuelle oppgaver uten å ta hensyn til forholdet mellom disse oppgavene; Puppet var det første verktøyet som eksplisitt sa at avhengigheter er den primære delen av konfigurasjonene dine, som igjen bør modelleres på riktig måte. Han laget en graf over ressurser og deres avhengigheter som en av hoveddatatypene, og nesten alle Puppet-handlinger var avhengig av denne grafen (kalt katalogen), dens toppunkter og kanter.

Den siste en viktig komponent Puppet er et konfigurasjonsspråk. Dette språket er deklarativt og er mer ment for å beskrive konfigurasjon enn for fullverdig programmering - det gjentar nesten fullstendig Nagios-konfigurasjonsformatet, men ble også opprettet under betydelig påvirkning av språk fra CFEngine og Ruby.

I hjertet av funksjonelle komponenter Puppet har to prinsipper som styrer utviklingen: den skal være så enkel å bruke som mulig, med brukervennlighet å foretrekke fremfor funksjoner; og også det bør utvikles først og fremst i form av et rammeverk og for det andre - en applikasjon, dermed, hvis ønskelig tredjeparts utviklere vil kunne lage sine applikasjoner basert på Puppet programvarekomponenter. Det var tydelig at det i tillegg til rammeverket også var behov for en mye brukt kvalitetsapplikasjon, men utviklerne var likevel først og fremst opptatt av rammeverket, ikke applikasjonen. Mange tror fortsatt at Puppet er nettopp denne applikasjonen, og ikke rammeverket den er implementert på.

Etter å ha bygget den første Puppet-prototypen, ble Luke en generelt god Perl-utvikler med liten erfaring med shell-scripting og lite C-erfaring, mest fra CFEngine-systemet. I tillegg til dette hadde han erfaring med å lage dataparsingsystemer for enkle språk, som ble oppnådd ved å utvikle to slike systemer til å fungere som en del av små verktøy, samt re-utvikle et dataparsingsystem for CFEngine fra bunnen av for å forenkle støtten (denne koden ble ikke overført til prosjektet på grunn av mindre inkompatibiliteter).

Beslutningen om å bruke et dynamisk språk for å implementere Puppet ble tatt ganske raskt på grunn av den betydelig høyere utvikler- og distribusjonsproduktiviteten. av denne typen språk, men selve valget viste seg å være ganske vanskelig. De originale Perl-prototypene ble forkastet, så det ble utført eksperimenter for å finne andre språk. Det ble gjort forsøk på å bruke Python språk men Luke fant at dette språket var vesentlig i strid med hans syn på verden. Etter å ha hørt en venn snakke om fordelene med det nye språket, prøvde Luke Ruby og bygde en fungerende prototype på fire timer. På det tidspunktet da fullskalautviklingen av Puppet begynte, var Ruby praktisk talt ukjent, så beslutningen om å bruke den var fylt med en stor risiko, men i dette tilfellet spilte utviklerproduktiviteten igjen en avgjørende rolle i valget av språk. Hoved kjennetegn Ruby språk i det minste fra Perl var det lett å skape ikke-hierarkiske klasseforhold, mens språket ikke motskrev tenkeaktiviteten til utvikleren Luke, som var kritisk.

Se for deg selv i rollen som en systemadministrator som er ansvarlig for å opprettholde helsen til hundrevis eller andre maskiner som kjører operativsystemer som UNIX. Hver av dem krever konfigurasjon, periodiske oppdateringer og overvåking, men mange av dem forventes å utføre lignende funksjoner. To tredjedeler er arbeidsstasjoner, noen flere er rutere, og resten er flere webservere og datavarehus. Spørsmålet er: hvordan styre hele denne økonomien?

Det enkleste svaret er å bare koble til hver enkelt ved å bruke SSH og gå inn nødvendige endringer... Denne metoden har imidlertid to problemer. For det første er det veldig arbeidskrevende. For det andre vil administratoren hele tiden måtte utføre mange monotone handlinger (for eksempel for å oppdatere OpenOffice.org på alle arbeidsstasjoner, må han utføre de samme kommandoene flere dusin ganger). Du kan prøve å unngå dette problemet ved å skrive flere skript som selv kobler til hver maskin og utfører forhåndsskrevne kommandoer. Men også her venter problemer på oss. Skriptene må hele tiden modifiseres for å justere dem for hver oppgave, skriptene må ta hensyn til forskjellen i operativsystemer og versjoner, de må feilsøkes i lang tid før de brukes på kjørende maskiner. Generelt sett ikke en camilfo.

Det riktige svaret er å bruke de såkalte systemene fjernkontroll konfigurasjoner, hvorav de mest kjente er åpne systemer Cfengine og dukke. Slike systemer påtar seg alt ansvar for å bringe maskinkonfigurasjonen til den rette typen krever fra administratoren kun en beskrivelse av den endelige tilstanden til systemet på spesielt språk(for eksempel en beskrivelse av hvilke pakker som skal installeres på operativsystemet, hvilke linjer som skal legges til konfigurasjonsfiler hvilke kommandoer som skal utføres osv.). Etter det vil alle noder selv motta informasjon om den nødvendige tilstanden fra serveren og vil autokonfigurere systemet. Takket være denne mekanismen kan nye maskiner bli fullstendig innstilt uten menneskelig innblanding, og eksisterende kan rekonfigureres med bare noen få linjer med tilstandsbeskrivelser.

dukke?

Puppet ble utviklet av Luke Kanies, som ble lei av begrensningene til Cfengine og bestemte seg for å lage en bedre versjon fra bunnen av. Hvis du har brukt Cfenfine før, vil du sannsynligvis oppleve at Puppet er et mer brukervennlig og kraftig system. Puppets tilstandsbeskrivelsesspråk er mer høyt nivå og fleksibelt, slik at administratoren ikke trenger å bekymre seg for ting som å skrive separate regler for hver type OS eller Detaljert beskrivelse utfører trivielle handlinger. Puppet lar deg fokusere på hva han vil gjøre det, i stedet for å gjøre det (for eksempel for å installere en bestemt pakke i noen av de støttede operativsystemene, er det nok å skrive bokstavelig talt noen få linjer som sier "Installer dette programmet", i stedet for å beskrive kommandoene som kreves for å installer det). Puppet er skrevet på et enkelt Ruby-språk, noe som gjør det enkelt å tilpasse seg spesifikk oppgave og utvide funksjonaliteten (et fleksibelt plug-in-system følger med). I tillegg, i motsetning til utviklingsmodellen Cfengine, som faktisk dreier seg om én person, har det dannet seg et stort fellesskap av entusiaster rundt Puppet som bidrar til koden, deler konfigurasjonseksempler og skriver dokumentasjon.

Totalt sett fremstår Puppet som et mer moderne og gjennomtenkt system med god design... I likhet med Cfengine, støtter den nesten alle moderne UNIX-lignende operativsystemer (inkludert MacOS X), og kan også kjøres i Cygwin på toppen av Windows. Listen over dens avhengigheter inkluderer bare Ruby-tolken og Factor-verktøyet, så det skal ikke være noen problemer med installasjonen (det er rimelig å si at listen over Cfengine-avhengigheter er enda kortere).

Filserver

Mange oppgaver fjernadministrasjon kan ikke løses uten å kopiere til maskiner tilleggsfiler... Disse kan være forhåndsforberedte konfigurasjoner, nettsider for Apache, pakker som ikke er i det offisielle depotet og mye mer. For å lette prosessen med å overføre disse filene til eksterne noder, inkluderer Puppet en filserver.

Innstillinger filserver lagret i filen /etc/puppet/fileserver.conf. For å tvinge Puppet til å vise innholdet i en spesifikk katalog til klienter, må du legge inn flere linjer i den:

Path = / var / puppet / files allow * .server.com

Disse to linjene indikerer at katalogen / var / puppet / files skal være tilgjengelig for alle verter i server.com-domenet. Vi kan også angi hele Domenenavn av den tillatte maskinen eller dens IP-adresse, samt kutte av de uønskede ved å bruke avvisningsdirektivet. Deretter kan enhver fil i denne katalogen flyttes til klienten ved hjelp av filressursen. For eksempel:

Fil ("/etc/httpd/conf/httpd.conf": source => "puppet: //httpd/httpd.conf", modus => 644,)

httpd.conf-filen som ligger på serveren i / var / puppet / files / httpd-katalogen vil bli kopiert til målmaskinen langs banen spesifisert i ressursnavnet.

konklusjoner

I denne artikkelen har vi dekket en veldig liten del av Puppets evner. Faktisk er det veldig komplekst system, som bare kan beskrives fullstendig på sidene i boken. Samtidig er Puppet veldig enkelt å konfigurere og vedlikeholde, spesielt siden du kan finne mange eksempler på konfigurasjonen på nettet.