Dockinstallation och konfiguration. Centraliserad installation med Puppet

För inte så länge sedan, på tidningens sidor, tittade vi på Cfengine fjäför UNIX-maskiner, vilket avsevärt förenklar livet för en systemadministratör genom att automatisera stegen för att konfigurera många nätverksnoder. Men oavsett hur bekväm Cfengine är, har det många nackdelar som ett system som heter Puppet inte har.

Föreställ dig att du är en systemadministratör, ansvarig för att underhålla funktionaliteten hos hundratals maskiner som kör UNIX-operativsystem. Var och en av dem kräver konfiguration, periodisk uppdatering och övervakning, och det antas att många av dem utför liknande funktioner.

Två tredjedelar är arbetsstationer, några till är routrar och resten är några webbservrar och datalager. Fråga: hur hanterar man allt det här? Det enklaste svaret är att helt enkelt ansluta till var och en av dem med SSH och göra de nödvändiga ändringarna. Denna metod har dock två problem. För det första är det väldigt arbetskrävande. För det andra måste administratören hela tiden utföra många monotona åtgärder (till exempel för att uppdatera OpenOffice.org på alla arbetsstationer måste du utföra samma kommandon flera dussin gånger). Du kan försöka undvika detta problem genom att skriva flera skript som kommer att ansluta till varje maskin själva och utföra förskrivna kommandon. Men även här väntar problem dig.

Skript kommer ständigt att behöva modifieras för att anpassa dem till varje uppgift; Skript måste ta hänsyn till skillnader i operativsystem och versioner, och de kommer att behöva felsökas under lång tid innan de appliceras på körande maskiner. I allmänhet inte comme il faut. Rätt svar är att använda så kallade fjärrkonfigurationshanteringssystem, de mest kända representanterna för dessa är open source-systemen Cfengine och Puppet. Sådana system tar på sig allt ansvar för att föra maskinkonfigurationen till önskad form, vilket kräver att administratören endast beskriver systemets slutliga tillstånd på ett speciellt språk (till exempel en beskrivning av vilka paket som ska installeras i operativsystemet, vilket rader bör läggas till i konfigurationsfiler, vilka kommandon som måste utföras etc.). Efter detta kommer alla noder själva att ta emot information om det nödvändiga tillståndet från servern och automatiskt konfigurera systemet. Tack vare denna mekanism kan nya maskiner konfigureras helt utan mänsklig inblandning, och befintliga kan konfigureras om genom att bara lägga till några rader i tillståndsbeskrivningen.

Marionett?

Vi har redan ägnat en hel artikel åt Cfengine-systemet, så idag kommer vi att fokusera på Puppet-systemet, som väl kan kallas dess ideologiska efterföljare. Puppet utvecklades av Luke Kanies, som tröttnade på Cfengines begränsningar och bestämde sig för att skapa en bättre version från grunden. Om du redan har använt Cfenfine kommer du förmodligen att tycka att Puppet är ett bekvämare och kraftfullare system. Puppets tillståndsspråk är mer på hög nivå och flexibelt, så administratörer behöver inte oroa sig för saker som att skriva separata regler för varje OS-typ eller detaljera hur man utför triviala åtgärder. Puppet låter sin herre fokusera på vad han vill göra, istället för hur man gör det (till exempel för att installera ett specifikt paket på något av systemets stödda operativsystem behöver du bara skriva några rader och säga "Installera det här programmet " istället för att beskriva de kommandon som är nödvändiga för installationen). Puppet är skrivet på ett enkelt Ruby-språk, vilket gör det enkelt att anpassa det till en specifik uppgift och utöka dess funktionalitet (ett flexibelt system med plugins tillhandahålls).

Dessutom, till skillnad från Cfengines utvecklingsmodell, som i huvudsak kretsar kring en person, har Puppet en stor grupp av entusiaster som gör förbättringar av koden, delar konfigurationsexempel och skriver dokumentation.

Sammantaget framstår Puppet som ett mer modernt och väldesignat system. Precis som Cfengine stöder den nästan alla moderna UNIX-liknande operativsystem (inklusive MacOS X), och kan även köras i Cygwin-miljön ovanpå Windows. Dess beroendelista innehåller bara Ruby-tolken och Factor-verktyget, så det borde inte vara några problem med installationen (för att vara rättvis är Cfengines beroendelista ännu kortare).

Installation

Precis som Cfengne är Puppet ett klient-serversystem som består av en kontrollserver och slavnoder. Servern lagrar en beskrivning av nodernas sluttillstånd (som i Puppet-termer kallas ett manifest) och väntar på att de ska ansluta. Varje halvtimme (som standard) ansluter klienten till servern, får från den en beskrivning av det slutliga tillståndet, jämför det med det nuvarande och, om det och/eller det beskrivna tillståndet har ändrats, konfigurerar systemet om och sedan går och lägger sig. Kommunikation utförs genom en krypterad kanal, så attacker baserade på ersättning av tillståndsbeskrivningen utesluts (men om en angripare tar över servern kommer alla noder att vara under hans kontroll).

Puppet ingår i alla populära distributioner, så att installera det borde inte vara svårt. Till exempel, på Debian/Ubuntu kan Puppet-klienten installeras så här:

$ sudo apt-get installation marionett

Och servern är så här:

$ sudo apt-get installera puppet puppetmaster

Klient- och serverkonfigurationsfilerna lagras i katalogen /etc/puppet. Den viktigaste av dessa är filen /etc/puppet/manifests/site.pp, som innehåller manifestet.

Den lagrar en beskrivning av tillstånden och bör endast finnas på servern. För att underlätta felsökningen, låt oss lägga till en enkel konfiguration till den:

klass passwd(
file("/etc/passwd":
ägare => rot,
grupp => rot,
läge => 644,
}
}
nod standard (
inkludera passwd
}

Dessa rader beskriver ett tillstånd där ägaren till filen /etc/passwd måste vara root och dess behörigheter är inställda på 644. Vi ska titta närmare på manifestfilformatet i nästa avsnitt. Den näst viktigaste filen är /etc/puppet/puppet.conf. Den ställer in konfigurationen av servern och klienterna, så den måste finnas på alla maskiner organiserade i Puppet-nätverket. I Ubuntu innehåller den här filen minsta nödvändiga och i de flesta fall tillräckliga inställningar. Nedan ges de med kommentarer:

# vi /etc/puppet/puppet.conf
# Standardkatalogsökvägar
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Faktaverktygets plats,
# används för att få information om operativsystemet
factpath=$vardir/lib/facter
# Synkronisera plugins
# (installerade plugins på servern - de kopieras till klienter)
pluginsync=true
# Katalog med mallar (läs om dem nedan)
templatedir=$confdir/mallar
# Synkronisering med etckeeper
# (vem vet, kommer att förstå, andra behöver det inte)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Konfigurationsfilen kan innehålla ett stort antal olika alternativ, information om vilka kan erhållas genom att generera en standardkonfiguration:

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

Standardklientkonfigurationen genereras med ett annat kommando:

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

Filerna fileserver.conf och auth.conf används för att konfigurera filservern (läs om detta i avsnittet "Filserver") och autentisering. Det är ingen idé att röra dem ännu. När konfigurationen är klar måste Puppet-servern startas om:

$ sudo /etc/init.d/puppetmaster starta om

Därefter kommer han att vara redo att acceptera kundförfrågningar. Men utan ett signerat certifikat kommer ingen klient att kunna ta emot manifestet från servern och konfigurera maskinen.

Därför måste vi köra Puppet-klienterna i testläge så att de kan skicka in sina certifikat till servern för signering (det kan förresten göras på alla maskiner samtidigt med shmux-verktyget):

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

Vi återvänder till servern och får en lista med certifikat som är redo för signering:

$ sudo puppetca --lista

Välj en värd från listan och signera dess certifikat:

$ sudo puppetca --sign nomad.grinder.com

Eller så skriver vi under allt på en gång:

$ sudo puppetca --sign --all

Nu kan du starta klienter i stridsläge. Men först måste du ange namnet på Puppet-servern i konfigurationsfilen (som standard är dess namn helt enkelt marionett):

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

Lansering av kunder:

$ sudo /etc/init.d/puppet start

Ange beskrivningsspråk

Som nämnts ovan använder Puppet ett eget språk för att beskriva det slutliga tillståndet för operativsystemet, med hjälp av vilket systemadministratören specificerar vilken form OS-komponenterna ska föras till för att det ska uppnå önskat tillstånd. Detta är ett ganska komplext språk, som ändå är mycket enklare än något programmeringsspråk. Om du är åtminstone ytligt bekant med bash-skriptspråket kommer du lätt att förstå Puppet-språket. Nyckelelementet i språket är resurserna som används för att beskriva vilken form en av OS-komponenterna ska konverteras till. Till exempel, följande enkla resurs beskriver det önskade tillståndet för filen /etc/passwd:

# vi /etc/puppet/manifests/site.pp
file("/etc/passwd":
ägare => "rot"
}

Här är filen resurstypen. Det finns flera dussin av dem totalt, allt från resurser som hanterar filer, som i det här exemplet, till paket och tjänster. Raden /etc/passwd är namnet på resursen.

När det gäller filtypen är namnet detsamma som sökvägen till filen, men i vissa andra typer kan namnet vara godtyckligt. Linjeägaren => "root" beskriver hur man ställer in ägarattributet till root, det vill säga att ägaren till den angivna filen måste vara en administratör.

Varje typ av resurs har sin egen uppsättning attribut som är tillgängliga för modifiering, plus att det finns speciella metaattribut som kan användas i vilken resurs som helst. En av de viktiga egenskaperna hos resurser är förmågan att länka till dem. Detta kan användas för att bilda beroendekedjor. Följande post skapar /etc/group-resursen, som beror på /etc/passwd-resursen (beroenden anges med attributet require meta):

# vi /etc/puppet/manifests/site.pp
file("/etc/group":
kräver => Fil["/etc/passwd"],
ägare => "rot",
}

Detta betyder att /etc/group-resursen kan konfigureras (förs till den beskrivna formen) endast när /etc/passwd-resursen är konfigurerad. Resurser kan grupperas i samlingar av resurser som kallas klasser. Detta är nödvändigt för att kombinera resurser som liknar betydelse och typ av uppgift som utförs till en abstrakt resurs. Till exempel, för enkelhets skull, kan vi kombinera installationen och lanseringen av nginx-webbservern till en abstrakt resurs med samma namn:

# vi /etc/puppet/manifests/site.pp
klass nginx(
package("nginx":
se till => installerat
}
service("nginx":
se till => kör,
kräver => Paket["nginx"],
}
}

Här används paketresurstypen för att installera nginx-paketet på systemet, och tjänsten används för att starta tjänsten med samma namn. Med require tvingar vi systemet att starta tjänsten endast om paketet har installerats. Bekvämligheten med klasser är att de också kan inkluderas beroende på:

# vi /etc/puppet/manifests/site.pp
service("squid":
se till => kör,
kräver => Klass["nginx"],
}

Som i riktiga OOP-språk kan klasser ärva från varandra och åsidosätta attribut:

# vi /etc/puppet/manifests/site.pp
klass passwd(
file("/etc/passwd":
ägare => "rot",
grupp => "rot",
}
}
klass passwd-bsd ärver passwd (
Fil["/etc/passwd"] ( grupp => "hjul" )
}

Här ärver klassen passwd-bsd från passwd för att åsidosätta gruppattributet för /etc/passwd-resursen (på BSD-system tillhör /etc/passwd hjulgruppen, så vi skapade en separat klass för sådana system). Senare kommer vi att titta på ett mer korrekt och självklart sätt att välja alternativa attributvärden med hjälp av villkor.

Variabler är en av de integrerade komponenterna i alla programmeringsspråk, och Puppet har dem också. Variabler börjar med ett $-tecken och kan innehålla valfritt tal, sträng eller booleskt värde (true, false):

$want_apache = sant
$apache_version = "2.2.14"

En av de mest kraftfulla variabelrelaterade funktionerna i Puppet är dess integration med. Detta verktyg returnerar all maskinspecifik information i form av nyckel-värdepar, som omvandlas till variabler med samma namn i Puppet. Tillsammans med villkorliga instruktioner på Puppet-språket kan de användas för att ändra resursattribut beroende på maskinens egenskaper.

Till exempel kan passwd-klassen som beskrivs ovan enkelt skrivas om för att automatiskt välja ett attribut beroende på OS-typ (utan att själva klassen behövs):

# vi /etc/puppet/manifests/site.pp
file("/etc/passwd":
ägare => "rot",
grupp => $kärna? (
Linux => "root",
FreeBSD => "hjul",
},
}

Beroende på vilket OS detta fragment av manifestet kommer att analyseras på, kommer värdet på gruppattributet att vara antingen rot eller hjul. Utöver den villkorliga operatorn stöder Puppet-språket även casevalsoperatorn, som kan användas för att skapa en viss resurs beroende på värdet på en variabel:

# vi /etc/puppet/manifests/site.pp
case $operativsystem (
redhat: (tjänst("httpd": säkerställ => körs))
debian: (tjänst("apache": säkerställ => körs))
default: (tjänst ("apache2": säkerställ =>
löpning))
}

Den här koden definierar olika varianter av en resurs av typen tjänst beroende på operativsystem (tjänstnamnen kan skilja sig åt mellan Linux-distributioner, så vilken tjänst Puppet ska köras måste anges individuellt för var och en av dem).

Standardalternativet används om värdet på variabeln inte matchar något av de tidigare alternativen. Förutom de tidigare diskuterade fil-, paket- och tjänstresurstyperna, stöder Puppet ett stort antal andra resurstyper, inklusive de som skapats av tredjepartsutvecklare. Deras detaljerade beskrivningar, inklusive exempel, attribut och funktioner som stöds, finns i den officiella dokumentationen - http://docs.puppetlabs.com/references/stable/type.html. Nedan följer en lista och kort beskrivning av de mest använda:

Populära marionettresurstyper

• cron - hantera cron-jobb
• exec - kör skript och kommandon
• fil - filhantering
• filebucket - säkerhetskopiering av filer
• grupp - gruppledning
• värd - hantera poster i filen /etc/hosts
• gränssnitt - konfiguration av nätverksgränssnitt
• montera - montering av filsystem
• meddela - skicka ett meddelande till Puppet-loggfilen
• paket - pakethantering
• service - service management
• sshkey - hantera SSH-nycklar
• tidy - radera filer beroende på förhållandena
• användare - användarhantering
• zoner - Solaris-zonhantering

Det näst viktigaste elementet i Puppet-språket efter resurser är noder. Med deras hjälp kan administratören beskriva på vilka maskiner vissa resurser och klasser ska tillämpas. Det är med andra ord ett sätt att specificera en individuell konfiguration för var och en av de maskiner som deltar i Puppet-nätverket. Det enklaste exemplet på en nod ges i början av artikeln i avsnittet "Installation":

# vi /etc/puppet/manifests/site.pp
nod standard (
inkludera passwd
}

Detta är definitionen av standardnoden, som inkluderar passwd-resursen/klassen. Namnet default betyder "alla andra noder", så passwd-resursen/klassen definierad någonstans ovan kommer att konfigureras på var och en av dem. Nyckelordet include används här för bekvämlighets skull, alla klasser och resurser kan beskrivas direkt i nodbeskrivningen, men detta rekommenderas inte. Förutom standard kan du i nodnamnet ange maskinens nätverksnamn (då kommer alla resurser som beskrivs i noden att konfigureras endast på den här maskinen), eller ett godtyckligt namn (då kan denna nod ärvas av en annan nod) . För att förstå hur allt detta fungerar tillsammans med klasser och resurser, låt oss titta på ett exempel på ett färdigt Puppet-manifest som används för att konfigurera två nätverksmaskiner (en webbserver och en NTP-server):

# vi /etc/puppet/manifests/site.pp
# Installera och köra en SSH-server
klass sshd (
paket ( openssh-server: säkerställ => installerat)
tjänst(sshd:
namn => $operativsystem ? (
fedora => "sshd",
debian => "ssh",
default => "sshd",
},
aktivera => sant,
se till => kör,
}
}
# Installera och kör Apache
klass httpd(
paket ( httpd: säkerställ => installerat )
tjänst(httpd:
aktivera => sant,
se till => kör,
}
}
# Installera och starta en NTP-server
klass ntpd(
paket (ntp-server: säkerställ => installerat)
tjänst (
ntp-server:
aktivera => sant,
se till => kör,
}
}
# Basnoden, används endast som förälder till alla andra
nodbas (
inkludera sshd
}
# Noden där webbservern kommer att finnas
nod web.server.com ärver bas (
inkludera httpd
}
# NTP-servernod
noden ntp.server.com ärver bas (
inkludera ntpd
}

Denna till synes enkla konfiguration gör en hel del: Apache installeras och körs på maskinen på web.server.com och en NTP-server installeras och körs på maskinen. ntp.server.com. Dessutom installerar båda maskinerna en SSH-server. Det är osannolikt att denna konfiguration passar ens en administratör; det kommer att behöva förbättras på allvar för att lära ut hur man korrekt konfigurerar servrar, tar emot färska konfigurationer och andra filer från Puppets huvudserver.

Det visar dock tydligt kraften i Puppet. Med en enkel konfiguration fick vi maskinerna att installera och köra den nödvändiga programvaran själva och hålla den i fungerande skick (om servern kraschar kommer Puppet själv att konfigurera om för att få systemen till det tillstånd som krävs).

Fil server

Många fjärradministrationsuppgifter kan inte lösas utan att kopiera ytterligare filer till maskinerna. Dessa kan vara förberedda konfigurationer, webbsidor för Apache, paket som inte finns i det officiella förvaret och mycket mer. För att förenkla processen att överföra dessa filer till fjärrvärdar inkluderar Puppet en filserver.

Filserverinställningarna lagras i filen /etc/puppet/fileserver.conf. För att tvinga Puppet att visa innehållet i en specifik katalog till klienter, måste du lägga in några rader i den:

# vi /etc/puppet/filserver.conf
sökväg = /var/puppet/filer
tillåt *.server.com

Dessa två rader indikerar att katalogen /var/puppet/files bör vara tillgänglig för alla värdar på server.com-domänen. Dessutom kan vi ange det fullständiga domännamnet för en tillåten maskin eller dess IP-adress, och även klippa bort oönskade med hjälp av neka-direktivet. Alla filer i den katalogen kan sedan flyttas till klienten med hjälp av filresursen. Till exempel:

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

httpd.conf-filen, som finns på servern i katalogen /var/puppet/files/httpd, kommer att kopieras till måldatorn längs den sökväg som anges i resursnamnet.

Slutsatser

I den här artikeln har vi täckt en mycket liten del av Puppets kapacitet. I själva verket är detta ett komplext system, som bara kan beskrivas fullständigt på sidorna i en bok. Samtidigt är Puppet väldigt lätt att konfigurera och underhålla, speciellt eftersom du kan hitta många exempel på dess konfiguration på webben.

Info

• Puppet använder HTTP-protokollet, så det kan köras under en webbserver för att förbättra prestandan.
• Puppet kan användas för att automatiskt konfigurera och underhålla en enda lokal dator.
• Genom att kombinera Puppet, nätverks-OS-installation (pxe-install) och självbyggande installationsbilder kan du skapa ett helt självkonfigurerande nätverk av maskiner som kan distribueras med bara ett kommando.
• Många stora företag använder Puppet i sitt arbete, som Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution och SugarCRM.

Länkar

• http://docs.puppetlabs.com - Puppet Documentation
• http://docs.puppetlabs.com/guides/language_tutorial.html - Fullständig beskrivning av Puppet-språket
• http://docs.puppetlabs.com/references/stable/type.html - Resurstyper

Marionettär ett plattformsoberoende ramverk som tillåter systemadministratörer att utföra vanliga uppgifter med hjälp av kod. Koden låter dig utföra olika uppgifter från att installera nya program till att kontrollera filbehörigheter eller uppdatera användarkonton. Marionettöverlägsen inte bara under den första installationen av systemet, utan under hela systemets livscykel. I de flesta fallen marionett används i klient/serverkonfiguration.

Det här avsnittet visar installation och konfiguration Marionett i en klient/server-konfiguration. Detta enkla exempel visar hur man installerar Apache använder sig av Marionett.

Installation

För installation Marionett skriv in i terminalen:

Sudo apt-get install puppetmaster

På klientdatorerna anger du:

Sudo apt-get installation marionett

inställningar

Innan du ställer in docka kanske du vill lägga till en post DNS CNAME För puppet.example.com, Var exempel.com- det här är din domän. Standardklienter Marionett kontrollera DNS för puppet.example.com som dockservernamn ( Dockmästare). Se Domain Name Service för ytterligare information om hur du använder DNS.

Om du inte tänker använda DNS kan du lägga till poster i filen /etc/hosts på servern och klienten. Till exempel i filen /etc/hosts Marionett server lägga till:

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

På varje Marionett Lägg till en post för servern i klienten:

192.168.1.16 meercat.example.com meercat marionett

Byt ut IP-adresserna och domännamnen från exemplet med dina faktiska server- och klientadresser och namn.

Låt oss nu ställa in några resurser för apache2. Skapa en fil /etc/puppet/manifests/site.pp innehållande följande:

Paket ( "apache2": säkerställ => installerad) tjänst ( "apache2": säkerställ => sant, aktivera => sant, kräver => Paket["apache2"])

Nod "meercat02.example.com" (inkludera apache2)

Byta ut meercat02.example.com till ditt nuvarande namn Marionett klient.

Det sista steget för detta enkla Marionett servern ska starta om tjänsten:

Sudo /etc/init.d/puppetmaster starta om

Nu på Marionett allt är konfigurerat på servern och det är dags att konfigurera klienten.

Låt oss först konfigurera tjänsten Marionett agent att lansera. Redigera /etc/default/puppet, ersätter värdet START på ja:

Sudo /etc/init.d/puppet start

Låt oss gå tillbaka till Marionett server för att signera klientcertifikatet med kommandot:

Sudo puppetca --sign meercat02.example.com

Kolla upp /var/log/syslog för eventuella konfigurationsfel. Om allt gick bra, paketet apache2 och dess beroenden kommer att installeras till Marionett klient.

Det här exemplet är väldigt enkelt och visar inte många av funktionerna och fördelarna. Marionett. För mer information se

För en tid sedan översteg listan över servrar i mina bokmärken 200. När antalet servrar ökar, slösar det enormt med tid att distribuera en ny konfiguration eller installera nya paket. Så jag bestämde mig för att använda docka.
Marionett(English puppet) är en plattformsoberoende klient-serverapplikation som låter dig centralt hantera konfigurationen av operativsystem och program installerade på flera datorer. Puppet är skriven på Ruby programmeringsspråk.

De säger också att puppet är ett fjärrkonfigurationshanteringssystem, vars mest kända representanter är de öppna systemen Cfengine och Puppet.

Efter att ha läst recensionerna bestämde jag mig för att använda docka.

Puppet server installation och konfiguration:
Installera en dockserver:
Installera puppet-server på OpenSuSE 11.4:

dragkedja i puppet-server

Låt oss ändra servernamnet till marionett:
/etc/HOSTNAME:

DNS-posten måste lösas till 127.0.0.2
cat /etc/hosts:

127.0.0.2 puppet.site marionett

Låt oss ge användaren rättigheter marionett:

Låt oss starta Puppet Master-tjänsten:

rcpuppetmasterd startar

Låt oss lägga till lanseringen av marionettdemonen till start:

chkconfig -en puppetmasterd

Konfigurera en dockserver:
Låt oss definiera katalogen där filerna ska lagras som marionettservern kommer att överföra till klientdatorer i manifest av filtypen.

vim /etc/puppet/filserver

sökväg /etc/puppet/files
tillåt *

mkdir /etc/puppet/files

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

Vi kommer att skapa en fil med allt innehåll för implementering och testning på klienter

tryck på /etc/puppet/files/puppettesting

Låt oss starta om dockservern:

rcpuppetmasterd startas om

Marionett använder sitt eget språk för att beskriva operativsystemets slutliga tillstånd, med hjälp av vilket systemadministratören indikerar till vilken form OS-komponenterna ska föras för att det ska uppnå önskat tillstånd. Tillståndet kan innebära närvaron av en specifik fil, mapp, pågående tjänster, installerade paket, uppdateringar och mer. Alla tillståndsinställningar beskrivs i filer eller manifest, som finns i katalogen: /etc/puppet/manifests. Dessa filer har namn som *.pp.

Låt oss skapa det enklaste manifest:
/etc/puppet/manifests/1.file.pp:

file("/tmp/puppettetesting":
källa => "puppet:///filer/puppettesting",
}

Så här använder du detta manifest:
puppet application 1.file.pp

Installera och konfigurera marionettklienten:

dragkedja i docka

Låt oss ge användaren dockrättigheter:

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

För att upprätta en anslutning till dockservern skickar dockklienten en begäran om att bekräfta certifikatet efter att denna begäran har bekräftats på servern, kommer dockklienten att börja använda manifesten som är avsedda för den. Vi skickar en begäran om att bekräfta certifikatet:

På servern kan vi se vilka bekräftelseförfrågningar som väntar:

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

Vi bekräftar:

puppetca --tecken "puppet-client.localdomain"

Det är dags att titta på de enklaste exemplen på att skapa manifest:
skapa en fil /etc/puppet/manifests/site.pp:

nod standard (
file("/tmp/puppettetesting":
källa => "puppet:///files/puppettesting",
}
service("ntp":
se till => kör,
aktivera => sant,
}
paket("htop":
se till => installerat,
}
}

standard - gäller för alla klienter
fil - det här avsnittet säger att man ska skapa eller skriva över filen /tmp/puppettetesting som finns på servern i katalogen /etc/puppet/files
tjänst: kontrollera om tjänsten körs, om den inte körs, starta den och lägg även till den vid start
paket: kontrollera om htop-paketet är installerat på klienten och om inte, installera det.

För att kontrollera, kör på klienten:

Som du kan se, på klienten, lades ntp till vid start, ntp-demonen lanserades, htop-paketet installerades och puppettetesting-filen kopierades till /tmp/-katalogen

info: Cachingkatalog för puppet-client.localdomain
info: Tillämpar konfigurationsversion "1370163660"
notis: / Stage[ main] // Nod[ default] / Service[ ntp] / säkerställa: se till ändrad "stoppad" till "running"
notis: / Stage[ main] // Nod[ default] / Package[ htop ] / säkerställ: skapad
notis: / Stage[ main] // Nod[ default] / File[ / tmp/ puppettesting] / säkerställ: definierat innehåll som "(md5)f2171ac69ba86781bea2b7c95d1c8e67"
notis: Färdig katalogkörning på 3,95 sekunder

I nästa artikel kommer jag att beskriva mer komplexa exempel på att skapa manifest och webbgränssnittet för marionettpaneler.

Populära marionettresurstyper
cron- hantera cron-jobb
exec- köra skript och kommandon
fil- filhantering
filebucket- säkerhetskopiering av filer
grupp- gruppledning
värd- hantera poster i filen /etc/hosts
gränssnitt- konfiguration av nätverksgränssnitt
montera- montering av filsystem
meddela- skicka ett meddelande till Puppet-loggfilen
paket- pakethantering
service- Service management
sshkey- SSH-nyckelhantering
städa- radera filer beroende på förhållandena
användare- Användarhantering
zoner- Solaris-zonhantering

Sergey Yaremchuk

Centraliserad konfiguration av UNIX-system med Puppet

Att hantera ett stort antal UNIX-system kan inte kallas bekvämt. För att ändra en parameter måste administratören kontakta varje maskin som bara kan hjälpa till delvis, och inte i alla situationer.

Det bör erkännas att Windows-nätverksadministratörer fortfarande har en mer fördelaktig position. Det räcker med att ändra grupppolicyinställningarna, och efter ett tag kommer alla datorer i nätverket, inklusive de med ett nyligen installerat operativsystem, att "lära sig" om innovationen, om det gäller dem, naturligtvis. När du ser tillbaka på den långa perioden av UNIX-utveckling kan du se att inget liknande någonsin slagit fast. Det finns lösningar som kickstart som hjälper till med den initiala installationen av operativsystemet, men vidareutveckling kommer att kräva betydande ansträngningar. Kommersiella lösningar, som BladeLogic och OpsWare, löser problemet med att automatisera inställningar endast delvis, deras främsta fördel är närvaron av ett grafiskt gränssnitt, och endast stora organisationer har råd att köpa dem. Det finns förstås projekt som erbjuder gratislösningar, men under hela sin existens har de inte kunnat skapa en stor community. Till exempel är Cfengine inte särskilt populärt bland administratörer, även om det förutom Linux kan användas i *BSD, Windows och Mac OS X. Detta kan bero på den relativa komplexiteten i att skapa konfigurationer. När du beskriver uppgifter är det nödvändigt att ta hänsyn till egenskaperna hos varje specifikt system och manuellt kontrollera sekvensen av åtgärder när du utför kommandon. Det vill säga, administratören måste komma ihåg att för vissa system bör du skriva adduser, för andra - useradd, ta hänsyn till placeringen av filer på olika system, och så vidare. Detta komplicerar processen att skriva kommandon i en storleksordning, det är mycket svårt att skapa den korrekta konfigurationen i farten, och det är nästan omöjligt att läsa de skapade konfigurationerna efter ett tag. Trots GPL-licensen är Cfengine i grunden ett enmansprojekt som kontrollerar alla förändringar och är inte särskilt intresserad av att bygga ett öppet samhälle. Som ett resultat är funktionerna hos Cfengine ganska tillfredsställande för utvecklaren, men för andra administratörer är det snarare en extra huvudvärk. För att förbättra Cfengine skapades olika tillägg av tredjepartsutvecklare, vilket ofta bara förvärrade situationen. Författaren till flera sådana moduler för Cfengine, Luke Kanies, bestämde sig så småningom för att utveckla ett liknande verktyg, men utan många av bristerna med Cfengine.

Dockfunktioner

Puppet, liksom Cfengine, är ett klient-serversystem som använder ett deklarativt språk för att beskriva uppgifter och bibliotek för att implementera dem. Klienter ansluter regelbundet (var 30:e minut som standard) till den centrala servern och får den senaste konfigurationen. Om de mottagna inställningarna inte stämmer överens med systemtillståndet kommer de att exekveras, och vid behov kommer en rapport om utförda operationer att skickas till servern. Meddelandeservern kan spara den till syslog eller en fil, skapa en RRD-graf och skicka den till angiven e-post. Ytterligare transaktions- och resursabstraktionslager ger maximal kompatibilitet med befintliga inställningar och applikationer, vilket gör att du kan fokusera på systemobjekt utan att oroa dig för skillnader i implementering och beskrivning av detaljerade kommandon och filformat. Administratören arbetar bara med objekttypen, Puppet tar hand om resten. Sålunda känner pakettypen till cirka 17 paketsystem. Det erforderliga systemet kommer att kännas igen automatiskt baserat på information om versionen av distributionen eller systemet, även om pakethanteraren kan ställas in med tvång.

Till skillnad från skript, som ofta är omöjliga att använda på andra system, kommer Puppet-konfigurationer skrivna av tredjepartsadministratörer oftast att fungera utan problem på något annat nätverk. Puppet CookBook har redan tre dussin färdiga recept. Puppet stöder för närvarande officiellt följande operativsystem och tjänster: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo och MySQL, LDAP.

Dockspråk

För att gå längre måste du först förstå språkets grundläggande beståndsdelar och förmågor. Språket är en av Puppets styrkor. Den beskriver de resurser som administratören planerar att hantera och de åtgärder de vidtar. Till skillnad från de flesta liknande lösningar tillåter Puppet språket att förenkla åtkomsten till alla liknande resurser på vilket system som helst i en heterogen miljö. En resursbeskrivning består vanligtvis av ett namn, typ och attribut. Låt oss till exempel peka på filen /etc/passwd och ställa in dess attribut:

file("/etc/passwd":

Ägare => rot,

Grupp => rot,

Läge => 644,

Nu kommer klienter som ansluter till servern att kopiera filen /etc/passwd och ställa in de angivna attributen. Du kan definiera flera resurser i en regel, separera dem med ett semikolon. Men vad händer om konfigurationsfilen som används på servern skiljer sig från klientens eller inte används alls? Till exempel kan denna situation uppstå när du konfigurerar VPN-anslutningar. I det här fallet bör du peka på filen med källdirektivet. Det finns två alternativ här du kan, som vanligt, ange sökvägen till en annan fil, och även använda de två URI-protokollen som stöds: fil och marionett. I det första fallet används en länk till en extern NFS-server i det andra alternativet, en NFS-liknande tjänst startas på Puppet-servern, som exporterar resurser. I det senare fallet är standardsökvägen relativt till dockans rotkatalog – /etc/puppet. Det vill säga, länken puppet://server.domain.com/config/sshd_config kommer att motsvara filen /etc/puppet/config/sshd_config. Du kan åsidosätta denna katalog med filebucket-direktivet, även om det är mer korrekt att använda avsnittet med samma namn i filen /etc/puppet/fileserver.conf. I det här fallet kan du begränsa åtkomsten till tjänsten till endast vissa adresser. Låt oss till exempel beskriva konfigurationssektionen:

Sökväg /var/puppet/config

Tillåt *.domain.com

Tillåt 127.0.0.1

Tillåt 192.168.0.*

Tillåt 192.168.1.0/24

Neka *.wireless.domain.com

Och sedan hänvisar vi till det här avsnittet när vi beskriver resursen:

source => "puppet://server.domain.com/config/sshd_config"

Före kolon står resursens namn. I de enklaste fallen kan du helt enkelt ange hela sökvägen till filen som namn. I mer komplexa konfigurationer är det bättre att använda ett alias eller variabler. Aliaset ställs in med aliasdirektivet:

file("/etc/passwd":

Alias ​​​​=> passwd

Ett annat alternativ för att skapa ett alias är bra när du har att göra med olika operativsystem. Låt oss till exempel skapa en resurs som beskriver filen sshd_config:

fil(sshdconfig:

Namn => $operativsystem ? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Standard => "/etc/ssh/sshd_config"

I det här exemplet står vi inför ett val. Filen för Solaris anges separat, för alla andra kommer filen /etc/ssh/sshd_config att väljas. Nu kan den här resursen nås som sshdconfig, beroende på operativsystemet kommer den önskade sökvägen att väljas. Till exempel anger vi att om sshd-demonen körs och en ny fil tas emot, bör tjänsten startas om:

tjänst(sshd:

Se till => sant,

Prenumerera => Fil

Variabler används ofta när man arbetar med användardata. Till exempel beskriver vi platsen för användarhemkataloger:

$homeroot = "/hem"

Nu kan filerna för en specifik användare nås som:

$(homeroot)/$namn

Parametern $name kommer att fyllas med användarens kontonamn. I vissa fall är det bekvämt att definiera ett standardvärde för någon typ. Till exempel, för exec-typen är det mycket vanligt att ange i vilka kataloger den ska leta efter den körbara filen:

Exec ( sökväg => "/usr/bin:/bin:/usr/sbin:/sbin" )

Om du behöver peka på flera kapslade filer och kataloger kan du använda parametern recurse:

file("/etc/apache2/conf.d":

Källa => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Återfall => "sant"

Flera resurser kan kombineras till klasser eller definitioner. Klasser är en fullständig beskrivning av ett system eller en tjänst och används separat:

klass linux (

Fil(

"/etc/passwd": ägare => rot, grupp => rot, läge => 644;

"/etc/shadow": ägare => rot, grupp => rot, läge => 440

Som i objektorienterade språk kan klasser åsidosättas. Till exempel, på FreeBSD är gruppägaren av dessa filer hjul. Därför, för att inte skriva om resursen helt, låt oss skapa en ny klass freebsd, som kommer att ärva linuxklassen:

klass freebsd ärver linux (

Fil["/etc/passwd"] ( grupp => hjul );

Fil["/etc/shadow"] ( grupp => hjul )

För enkelhetens skull kan alla klasser placeras i en separat fil, som måste inkluderas med hjälp av direktivet include. Definitioner kan ta flera parametrar som argument, men stöder inte arv och används när du behöver beskriva återanvändbara objekt. Låt oss till exempel definiera användarnas hemkatalog och de kommandon som behövs för att skapa ett nytt konto:

definiera user_homedir ($grupp, $fullnamn, $ingroups) (

User("$name":

Se till => närvarande,

Kommentar => "$fullnamn",

Gid => "$grupp",

Grupper => $ingroups,

Medlemskap => minimum,

Shell => "/bin/bash",

Hem => "/hem/$namn",

Kräv => Grupp[$group],

Exec("$name homedir":

Kommando => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

Skapar => "/home/$name",

Kräv => Användare[$name],

Nu, för att skapa ett nytt konto, gå bara till user_homedir:

user_homedir("sergej":

Grupp => "sergej",

Fullständigt namn => "Sergej Jaremchuk",

Ingrupper => ["media", " admin]

Det finns separata beskrivningar av noder som stöder arv, såväl som klasser. När en klient ansluter till Puppet-servern kommer motsvarande nodsektion att genomsökas och inställningar som endast är specifika för denna dator tillhandahålls. För att beskriva alla andra system kan du använda nodstandard. En beskrivning av alla typer finns i dokumentet "Typreferens", som måste läsas i alla fall, åtminstone för att förstå alla funktioner i Puppet-språket. Olika typer låter dig utföra specificerade kommandon, inklusive när vissa villkor är uppfyllda (till exempel ändra en konfigurationsfil), arbeta med cron, användaruppgifter och grupper, datorer, montera resurser, starta och stoppa tjänster, installera, uppdatera och ta bort paket , arbetar med SSH-nycklar, Solaris-zoner och så vidare. Så här kan du enkelt tvinga listan över paket i distributioner med hjälp av apt att uppdateras dagligen mellan 2 och 4 timmar:

schema (dagligen:

Period => dagligen,

Räckvidd =>

exec("/usr/bin/apt-get update":

Schema => dagligen

Uppdateringen för den perioden kommer att utföras av varje system endast en gång, varefter uppgiften anses avslutad och kommer att raderas från klientdatorn. Puppet-språket stöder andra välbekanta strukturer: villkor, funktioner, arrayer, kommentarer och liknande.

Installera Puppet

Puppet kräver Ruby (version 1.8.1 och högre) med OpenSSL-stöd och XMLRPC-bibliotek, samt Faster-biblioteket. Ubuntu 7.04-förrådet som användes för testinstallationen innehåller redan valppaketet:

$ sudo apt-cache sökdocka

~$ ruby ​​​​-rxmlrpc/client -e "puts:yep"

Japp

Om inga fel tas emot är allt du behöver redan inkluderat. Filer som beskriver den önskade konfigurationen av system kallas manifest i Puppet-terminologi. När den startas försöker demonen läsa filen /etc/puppet/manifests/site.pp om den saknas, visar den ett varningsmeddelande. När du testar kan du säga åt demonen att köras i fristående läge, vilket inte kräver ett manifest:

$ sudo /usr/bin/puppetmasterd --nonodes

Vid behov kan du koppla andra filer till site.pp, till exempel med klassbeskrivningar. För en testkörning kan du ange de enklaste instruktionerna i den här filen.

klass sudo(

File("/etc/sudoers":

Ägare => rot,

Grupp => rot,

Läge => 440,

nod standard (

Inkludera sudo

Alla konfigurationsfiler, både server och klient, finns i /etc/puppet. Filen fileserver.conf, som vi redan pratat om, är valfri och används endast om Puppet också kommer att fungera som en filserver. På Ubuntu exporterar den här filen /etc/puppet/files underkatalogen. ssl-underkatalogen innehåller certifikat och nycklar som kommer att användas för kryptering vid anslutning av klienter. Nycklar skapas automatiskt första gången du startar puppetmasterd, du kan skapa dem manuellt med kommandot:

$ sudo /usr/bin/puppetmasterd --mkusers

Filerna puppetd.conf och puppetmasterd.conf liknar varandra. De indikerar några parametrar för driften av demoner på klientsystemet och servern. Klientfilen skiljer sig endast i närvaro av serverparametern, som pekar på datorn på vilken puppetmasterd körs:

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# skicka en rapport till servern

rapport = sant

För att undvika att skriva allt manuellt kan du skapa en mall med Puppetd själv:

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

På samma sätt kan du skapa site.pp på servern:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

En annan fil, tagmail.conf, låter dig ange e-postadresser som rapporter ska skickas till. I det enklaste fallet kan du använda en rad:

Allt: [e-postskyddad]

Konfigurationsfilerna räcker inte för att klienten ska ansluta till servern. För att göra detta måste du också signera certifikaten.

Först, för att meddela servern om den nya datorn, skriv in kommandot på klientsystemet:

$ sudo puppetd --server grinder.com --waitforcert 60 –test

Brandväggen måste tillåta anslutningar på port 8140.

På servern får vi en lista över certifikat som måste signeras:

$ sudo puppetca –lista

nomad.grinder.com

Och signera klientcertifikatet:

$ sudo puppetca –sign nomad.grinder.com

Nu kan klienten fritt ansluta till servern och ta emot inställningar.

Tyvärr är det omöjligt att visa alla funktioner i Puppet i artikeln. Men som du kan se är detta ett funktionellt och flexibelt verktyg som låter dig lösa de flesta problemen med samtidig administration av ett stort antal system. Och viktigast av allt, projektet lyckades samla en liten men ständigt växande community. Låt oss därför hoppas att en bra idé inte kommer att tillåtas dö eller gå åt sidan.

Lycka till!

1. BladeLogic-projektets webbplats – http://www.bladelogic.com.
2. OpsWare-projektets webbplats är http://www.opsware.com.
3. Cfengine-projektets webbplats är http://www.cfengine.org.
4. Puppet-projektets webbplats är http://reductivelabs.com/projects/puppet.
5. Puppet CookBook - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
6. Snabbare bibliotek –

När antalet servrar du hanterar är mindre än tio, är det sällan någon tänker på deras centraliserade hantering, detta kanske inte krävs. När det finns dussintals servrar är centraliserad programvara och konfigurationshantering extremt användbar. När det finns hundratals och tusentals servrar är detta avgörande. Det finns många program av det här slaget, till exempel: Chef, CFEngine, Puppet... Det är det senare som kommer att diskuteras i det här inlägget.

Puppet anses vara en av de bästa lösningarna av detta slag. Det används av företag som Google, Citrix och Red Hat. Detta är en klient-serverapplikation skriven i programmeringsspråket Ruby, som distribueras i två versioner:

• Puppet Open Source - helt gratis version
• Puppet Enterprise - gratis för upp till 10 servrar, sedan krävs licenser

Låt oss överväga att installera Puppet Open Source-servern och agenten, som ingår i paketen för de flesta moderna distributioner. Härnäst kommer vi att prata om Ubuntu 12.04 Precise Pangolin.

Den bakre delen av Puppet kallas dockmästare, låt oss börja installationen därifrån:

:~# apt-get install puppetmaster

Och nu kunden:

:~# apt-get install marionett

I klientens konfigurationsfil /etc/puppet/puppet.conf du måste prata om servern genom att lägga till följande avsnitt:

Server=puppet.local report=true pluginsync=false

I det inledande skedet är det bättre att stänga av pluginsync.

Låt oss köra dockklienten så att den skapar en begäran om ett certifikat:

:~# puppetd --verbose --test info: Skapar en ny SSL-nyckel för linux.local info: Cachingcertifikat för ca info: Skapar en ny SSL-certifikatbegäran för linux.local info: Certifikatbegäran fingeravtryck (md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Avslutar; inget certifikat hittades och waitforcert är inaktiverat

På servern måste du kontrollera att certifikatbegäran har tagits emot och i så fall utfärda ett certifikat:

:~# puppetca --lista "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca - -sign linux.local notis: Signerad certifikatbegäran för linux.local notis: Tar bort filen Puppet::SSL::CertificateRequest linux.local på "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Upprepa föregående steg på klienten:

:~# puppetd --verbose --test info: Cachning av certifikat för linux.local info: Hämtar plugin info: Cachar certificate_revocation_list för ca info: Cachar katalog för linux.local info: Applicerar konfigurationsversion "1356278451" info: Skapar tillståndsfil / var/lib/puppet/state/state.yaml meddelande: Färdig katalogkörning på 0,02 sekunder

Jättebra, allt fungerar. Låt oss gå vidare till att skapa det första manifestet. Manifest, eller konfigurationer, beskrivs i ett särskilt deklarativt språk. Vi kommer genast att vänja oss vid bra saker, använda en modulär struktur och klasser. Låt oss till exempel skriva en modul som kommer att hålla filen uppdaterad /etc/hosts på alla våra servrar.

Låt oss kolla var dockan letar efter moduler:

:~# puppet application --configprint modulsökväg /etc/puppet/modules:/usr/share/puppet/modules

Skapa kataloger för din modul

:~# cd /etc/puppet/modules :~# mkdir-värdar; cd-värdar; mkdir manifesterar; cd manifesterar

Det första manifestet, även känt som huvudmodulfilen, ska anropas init.pp

Klassvärdar ( # puppet.local host ( "puppet.local": sure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local host ( "linux.local": säkerställ => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

Som standard letar dockan efter en fil /etc/puppet/manifests/site.pp för att ladda konfigurationen, låt oss ta den till följande form:

Nodstandard (inkludera värdar)

Vi kontrollerar manifestet på servern:

:~# puppet application --verbose /etc/puppet/manifests/site.pp info: Applicering av konfigurationsversion "1356281036" meddelande: /Stage//Host/ensure: skapad info: FileBucket adding (md5)notice: /Stage// Värd/försäkra: skapad meddelande: Färdig katalogkörning på 0,03 sekunder

På klienten:

:~# ll /etc/hosts rw-r--r-- 1 rotrot 290 dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: Cachingkatalog för linux.local info: Applying konfigurationsversion "1356283380" info: FileBucket adding (md5)notice: /Stage/Hosts/Host/ensure: skapat meddelande: /Stage/Hosts/Host/ensure: skapat meddelande: Färdig katalog körs på 0,04 sekunder :~# ll /etc /hosts -rw-r--r-- 1 rotrot 551 23 dec 20:43 /etc/hosts

När vi är säkra på att allt fungerar låter vi tjänsten starta, in /etc/default/puppet förändra:

# Starta docka på start? START=ja

Startar tjänsten

:~# service marionettstart

Puppet kommer att efterfråga puppetmaster-servern var 30:e minut för konfigurationsändringar och, om nödvändigt, justera systemet därefter.