Hem › Råd › Master of puppets: Installera och konfigurera Puppets fjärrkonfigurationshanteringssystem. Master of puppets: Installera och konfigurera Puppet fjäInstallera marionett

Master of puppets: Installera och konfigurera Puppets fjärrkonfigurationshanteringssystem. Master of puppets: Installera och konfigurera Puppet fjäInstallera marionett

För att använda Puppet mer effektivt måste du förstå hur moduler och manifest är uppbyggda. Denna handledning går igenom hur dessa Puppet-komponenter fungerar genom att ställa in en LAMP-stack på en Ubuntu 14.04-server.

Krav

Installera Puppet (master och agent). Mer om detta -.
Möjligheten att skapa minst en virtuell Ubuntu 14.04-server för att tjäna Puppet-agentnoden.

Puppet Code Basics

Resurser

Dockkod består huvudsakligen av resurser. En resurs är en bit kod som beskriver systemets tillstånd och bestämmer vilka ändringar det behöver. Till exempel:

user("mitchell":
säkerställa => närvarande,
uid => "1000",
gid => "1000",
skal => "/bin/bash",
hem => "/hem/mitchell"
}

Resursdeklarationen har följande format:

resurstyp("resursnamn"
attribut => värde
...
}

För att se alla Puppet-resurstyper, utfärda kommandot:

marionettresurs --typer

Du kommer att lära dig mer om resurstyper i den här guiden.

Manifest

Ett manifest är ett orkestreringsmanus. Dockprogram med tillägget .pp kallas manifest. Standard Puppet-manifest är /etc/puppet/manifests/site.pp.

Klasser

Som i alla vanliga programmeringsspråk ansvarar klasserna för att organisera och återanvända delar av orkestreringen.

Inom en klassdefinition finns ett kodblock som beskriver hur klassen fungerar. När du väl har definierat en klass kan du använda den i manifest.

Klassdefinitionen har följande format:

klass exempel_klass(
...
koda
...
}

Den här koden definierar klassen exempel_klass. Puppet-koden kommer att vara i hängslen.

En klassdeklaration är den plats i koden där en viss klass anropas. Med en klassdeklaration bearbetar Puppet sin kod.

Klassdeklarationen kan vara vanlig och efter resurstyp.

En vanlig klassdeklaration läggs till i koden med hjälp av nyckelordet include.

inkludera exempel_klass

När den deklareras som en resurstyp deklareras klassen i resursformat:

class("exempel_klass":)

Denna deklaration låter dig lägga till klassparametrar till din kod som åsidosätter standardvärdena för klassattribut. Till exempel:

nod "värd2" (
klass ("apache": ) # använd apache-modul
apache::vhost ("example.com": # definiera vhost-resurs
port => "80",
docroot => "/var/www/html"
}
}

Moduler

En modul är en grupp av manifest och andra filer organiserade på ett fördefinierat sätt som gör det enkelt att dela och återanvända enskilda delar av orkestreringen. Moduler hjälper till att organisera Puppet-kod eftersom de kan användas för att separera kod i flera manifest.

Puppet-moduler lagras i katalogen /etc/puppet/modules.

Att skriva ett manifest

Du kan öva på att skriva Puppet-manifest, moduler och klasser genom att använda exemplet att installera en LAMP-stack på en Ubuntu-server (resultatet blir ).

Så för att orkestrera en Ubuntu 14.04-server och installera en LAMP-stack på den behöver du resurser för följande åtgärder:

installera apache2-paketet.
startar apache2-tjänsten.
paketinstallation MySQL-server, mysql-server.
startar mysql-tjänsten.
installerar php5-paketet
skapa ett PHP-testskript, info.php.
uppdatera apt-indexet innan du installerar varje paket.

Nedan hittar du tre exempel på Puppet-kod som kan användas för att uppnå en sådan LAMP-stackuppsättning.

Det första exemplet kommer att lära dig hur man skriver grundläggande manifest i en fil. Det andra exemplet hjälper dig att sätta ihop och använda en klass och modul baserad på tidigare skrivna manifest. Det tredje exemplet visar hur du använder förbyggda publika moduler för att installera en LAMP-stack.

Notera: För att testa är det bättre att använda en ny virtuell server.

Exempel 1: Installera LAMP med ett manifest

Puppet-manifestet kan skrivas på agentnoden och sedan köras med kommandot Puppet Application (du behöver inte ha en master- och agentinställning för att göra detta).

I det här avsnittet lär du dig att skriva manifest som kommer att använda dessa typer av resursdeklarationer:

exec: Kör kommandon.
paket: installera paket.
service: service management.
fil: filhantering.

Skapar ett manifest

Skapa ett nytt manifest:

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

Lägg till följande kod för att deklarera de nödvändiga resurserna.

# kör kommandot "apt-get update".
exec("apt-update": # resurs exec "apt-update"
command => "/usr/bin/apt-get update" # kommando som den här resursen kommer att köras
}
# installera apache2-paketet
package("apache2":
require => Exec["apt-update"], # begär "apt-update" innan du installerar paketet
se till => installerat,
}
# starta apache2-tjänsten
service("apache2":
se till => kör,
}
# installera mysql-server
paket("mysql-server":
require => Exec["apt-update"], # begär "apt-update" genom att installera om
se till => installerat,
}
# starta mysql-tjänsten
service("mysql":
se till => kör,
}
# installera php5-paketet
package("php5":
require => Exec["apt-update"], # begär "apt-update" före installationen
se till => installerat,
}
# starta info.php-tjänsten
file("/var/www/html/info.php":
säkerställ => fil,
innehåll => "", # phpinfo-kod
kräver => Paket["apache2"], # begäran för paketet "apache2"
}

Tillämpa ett manifest

För att använda det nya manifestet anger du kommandot:

sudo puppet application --test

Den kommer att visa ett voluminöst resultat som visar alla förändringar i miljöns tillstånd. Om det inte finns några fel i utgången bör du kunna öppna din externa IP-adress eller domännamn i din webbläsare. Ett testtest kommer att visas på skärmen. PHP-sida med information om stacken. Detta betyder att Apache och PHP fungerar.

Nu är LAMP-stacken installerad på servern med Puppet.

Detta är ett ganska enkelt manifest eftersom det kan köras på en agent. Om du inte har en Puppet Master kommer andra agentnoder inte att kunna använda detta manifest.

Puppet Master-servern kontrollerar servertillståndsändringar var 30:e minut.

Exempel 2: Installation av en LAMP-stack med en modul

Försök nu att skapa en enkel modul baserad på LAMP-manifestet som du skrev i föregående avsnitt.

För att skapa en modul, skapa en ny katalog i modulkatalogen (dess namn måste matcha modulens namn). Denna katalog bör innehålla en manifestkatalog och en init.pp-fil. Filen init.pp anger Puppet-klassen (dess namn måste också matcha modulens namn).

Skapa en modul

Gå till Puppet master-servern och skapa en katalogstruktur för modulen:

cd /etc/puppet/modules
sudo mkdir -p lampa/manifester

Skapa och öppna filen init.pp i redigeraren:

sudo vi lamp/manifests/init.pp

Infoga lampklassen i filen:

klass lampa (
}

Kopiera innehållet i manifestet från avsnitt 1 och klistra in det i lampklassblocket. Du har nu en definition av lampklass. Andra manifest kommer att kunna använda denna klass som en modul.

Spara och stäng filen.

Använda en modul i huvudmanifestet

Nu kan du konfigurera huvudmanifestet och använda lampmodulen för att installera LAMP-stacken på servern.

Redigera följande fil på Puppet Master-servern:

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

Mest troligt på det här ögonblicket filen är tom. Lägg till följande rader:

nod standard ( )
nod "lamp-1" (
}

Notera: Byt ut lampa-1 med värdnamnet för din Puppet-agent som du vill installera stacken på.

Nodblocket låter dig ange Puppet-kod som bara gäller för vissa noder.

Standardblocket gäller alla agentnoder som inte har ett individuellt block (låt det vara tomt). Lamp-1-blocket kommer att appliceras på lamp-1-agentnoden.

Lägg till följande rad i detta block, som använder lampmodulen:

Spara och stäng filen.

Nu kommer Puppet-agentnoden att kunna ladda ner inställningar från masterservern och installera LAMP-stacken. Om du vill göra ändringar just nu, kör kommandot på agenten:

sudo marionettagent --test

Moduler är det bekvämaste sättet att återanvända Puppet-kod. Dessutom hjälper moduler dig att logiskt organisera din kod.

Exempel 3: Installation av LAMP med publika moduler

MySQL-modulen används på liknande sätt. Lägg till följande rader i nodblocket:

class("mysql::server":
root_password => "lösenord",
}

Du kan också skicka MySQL-modulparametrar.

Lägg till en resurs som kopierar info.php till önskad plats. Använd källparametern. Lägg till följande rader i nodblocket:

file("info.php": # resursfilnamn
sökväg => "/var/www/html/info.php", # målsökväg
säkerställ => fil,
kräver => Klass["apache"], # apache-klass att använda
source => "puppet:///modules/apache/info.php", # plats att kopiera filen till
}

Denna klassdeklaration använder källparametern istället för innehåll. Det här alternativet använder inte bara innehållet i filen, utan kopierar det också.

Puppet kommer att kopiera filen puppet:///modules/apache/info.php till /etc/puppet/modules/apache/files/info.php.

Spara och stäng filen.

Skapa en info.php-fil.

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

Nu kommer Puppet-agentnoden att kunna ladda ner inställningar från masterservern och installera LAMP-stacken. Om du vill göra ändringar i agentmiljön just nu, kör kommandot på denna nod:

sudo marionettagent --test

Detta kommando kommer att ladda ner alla uppdateringar för den aktuella noden och installera stacken på den. För att säkerställa att Apache och PHP fungerar, öppna nodens IP-adress eller domän i en webbläsare:

http://lamp_1_public_IP/info.php

Slutsats

Du har nu grundläggande kunskaper i att arbeta med Puppet-moduler och manifest. Prova att skapa ett enkelt manifest och modul själv.

Puppet är utmärkt för att hantera programkonfigurationsfiler.

Taggar: ,
Lite poesi. Det verkar som att den här artikeln borde vara utgångspunkten för hela serien, men målgruppen är fortfarande mer erfarna användare av Open Source Puppet Labs-produkter som inte är nöjda med de individuella, dåligt integrerade modulerna med Puppet Forge. Som med alla fall av "bibliotek vs ramverk" är priset att betala att följa världsbilden hos författaren till den integrerade lösningen.

Lite om hur Puppet fungerar

Puppet är i första hand ett specifikt språk för att deklarativt specificera systemets slutliga tillstånd. Som jämförelse är GNU Makefile extremt lämplig, där det, förutom den direkta beskrivningen av beroenden, är möjligt att bli konstig till fullo.

Puppets abstraktion är ungefär så här ( bryta mönster - glöm allt du visste om programmeringstermer!).

Nodär en uppsättning konfigurationer för ett specifikt målsystem. I själva verket är detta ett specialfall av en klass.
Klassär en uppsättning deklarativ logik som ingår i nodkonfigurationen eller andra klasser. Klassen har varken instanser eller metoder, men den har parametrar och variabler definierade inom logiken. I själva verket är det snarare en procedur som kan ärva en annan procedur genom att helt enkelt lägga till kod och ha en inte så banal omfattning av variabler.
Typ- men det här ser mer ut som en klassisk klass - det förutsätter instanser med ett namn och definitivt givna parametrar, men inget mer. En specifik implementering av en typ kan skrivas som ett Puppet-skript via define , som skapar instanser av andra typer, eller som en Ruby-förlängning med en fantasi.
Resurs- dessa är faktiskt namngivna instanser av typer. Varje resursnamn är unikt inom en specifik typ inom nodkonfigurationen (katalogen).
Variabler– ja, kort sagt, det här är konstanter... Innan Puppet 4 var det ännu värre med deras omfattning. Nu är det tillräckligt: för användning utanför definitionsplatsen måste en fullständigt kvalificerad identifierare anges, förutom i fallet med klassarv.

Puppet kan användas för lokal distribution utan nätverk eller tillhörande infrastruktur. Detta kan användas för att skapa behållarbilder. Det finns till och med en hel rörelse som förespråkar att en centraliserad server ska överges.

På ett ideologiskt korrekt sätt består Puppet-infrastrukturen av en agent - en privilegierad tjänst på målsystemet - och en server som distribuerar värdefulla instruktioner i form av deklarativa resurskataloger på begäran från agenter. Säkerhet implementeras på nivån för den privata offentliga nyckelinfrastrukturen (X.509). Enkelt uttryckt samma mekanismer som i HTTPS, men med egen CA och obligatorisk verifiering klientcertifikat.

I en förenklad form ser distributionsproceduren ut ungefär så här:

Bearbetning via TLS och X.509 (anslutningsetablering, CRL-uppdatering, kontroll av certifikatrestriktioner, etc.)
Agenten tar emot faktageneratorer från servern med cachning och alla saker (mer exakt, allt hämtas från lib/-mapparna i modulerna). Det är inte svårt att lägga till ditt eget Ruby-skript för att samla in information av intresse.
Agenten samlar in fakta om målsystemet och skickar det till servern. All fakta kan enkelt ses manuellt via marionettfaktasamtal. Dessa fakta är tillgängliga som globala variabler.
Servern sammanställer en katalog med resurser och skickar den till agenten. Under detta ligger ett helt lager av olika koncept.
Agenten hämtar allt som behövs från servern och för systemet till den angivna formen. Agenten själv vet inte vad den ska göra med resurser, den förlitar sig på implementeringen av leverantörer (den semantiska översättningen kommer att vara "implementerare", inte leverantör) av specifika typer av resurser. Vissa leverantörer är standard och ingår i Puppet-paket, medan resten dras från moduler.

För att njuta av alla läckerheter finns det ytterligare bullar i form av:

Modul- en samling deklarativa Puppet-skript, Ruby-tillägg för Puppet, filer, filmallar, Hiera-data och mycket mer. En mer korrekt term skulle vara "paket".
Miljö- en uppsättning skript, moduler och Hiera-data. När infrastrukturen blev mer komplex blev det oundvikligen nödvändigt att dela upp konfigurationen längre än standardindelningen efter noder. I grund och botten krävs detta för pilotinnovationer och banal åtkomstkontroll (när inte alla administratörer har tillgång till alla noder i IT-infrastrukturen).
Hiera- hierarkisk databas. Denna formulering kan vara mycket skrämmande. Det är förmodligen därför det ändrades i dokumentationen för senare versioner. Faktum är att detta är en extremt enkel och bekväm mekanism för att extrahera konfiguration från YAML- eller JSON-filer. Hierarki är möjligheten att specificera läsordningen för flera konfigurationsfiler - dvs. hierarki/prioritet för dessa filer.
- Förutom att hämta data via funktionsanrop, drar Puppet standardklassparametrar, vilket är huvudhöjdpunkten.
- Naturligtvis stödjer Hiera faktainterpolering och till och med anrop av specialfunktioner.
- I Puppet 4.3 implementerade vi samma funktion igen för att stödja inte bara den globala databasen, utan även den lokala för miljön och modulen, även om författaren redan har hittat flera problem i deras implementering (PUP-5983, PUP-5952 och PUP -5899), som omedelbart fixades av Puppet Labs.
- Flera strategier stöds för att extrahera värden från alla filer i hierarkin:
  - först - det första värdet som hittas av prioritet returneras
  - unik - samlar alla värden i en endimensionell array och tar bort dubbletter
  - hash - kombinerar alla hittade YAML Hash. Dubblettnycklar väljs efter prioritet.
  - deep är i grunden en rekursiv version av hash
- Det fina är att samplingsstrategin kan specificeras både när man anropar lookup()-funktionen, eftersom och i valfri hierarkifil genom den speciella lookup_options-nyckeln, som används aktivt i cfnetwork-modulen.
PuppetDB- i huvudsak ett lager av affärslogik runt en relationsdatabas (PostgreSQL), som låter dig spara rapporter om gjorda fakta och implementeringar och exportera resurser för efterföljande import till kataloger på andra noder eller val via speciella funktioner. Det finns även ett webbgränssnitt i form av Puppet Dashboard.
X.509 PKI- den redan nämnda certifikatinfrastrukturen, som är extremt bekväm att använda för andra tjänster utan att behöva hantera en separat infrastruktur.
MCollective- verkar vara en användbar sak för händelsebaserad lansering av uppgifter på en serverfarm, men författaren har en viss misstro mot säkerheten för en viss lösning.
Puppet Forge- en öppen plattform för publicering och nedladdning av moduler.
några andra funktioner i form av kontroller externa enheter typ av Cisco-utrustning och distribution på ren metall, men det är en annan historia

Anteckningar om säkerhet och tillgänglighet

Du måste förstå att Puppet Server blir en sårbar punkt i hela IT-infrastrukturen, eftersom... bestämmer den slutliga konfigurationen av alla system. I speciella fall är det vettigt att göra en separation - en separat server för kritiska infrastrukturelement med extremt begränsad åtkomst och manuell uppdatering och den andra för allt annat.

Tillgängligheten för Puppet Server avgör möjligheten att hantera hela infrastrukturen. Det är vettigt att vara värd för Puppet Server på en virtuell maskin i ett mer tillförlitligt och snabbt återställbart tredjepartsmoln än dina egna möjligheter. Eller så bör du installera flera servrar.

I vilket fall som helst bör du inte installera andra tjänster på systemet där Puppet Server med klockor och visselpipor kommer att distribueras. Virtualisering och containerisering kan hjälpa dig.

Multi-master (flera separata Puppet Servers)

I det här fallet fungerar bara en server som en CA (Certificate Authority) - dess otillgänglighet betyder att det är omöjligt att lägga till nya noder.
- Puppet låter dig använda en tredjeparts X.509-infrastruktur om den inbyggda inte är tillfredsställande.
Hela konfigurationen (Environment) måste lagras i ett versionskontrollsystem och distribueras till varje server samtidigt.
Det enda som är gemensamt är PostgreSQL-databasen, vars organisation av hög tillgänglighet ligger utanför ramen för denna artikel.
Modulen cfpuppetserver stöder installationer som primär (med CA) och som sekundär server.

Vad väsentligt har förändrats sedan äldre versioner

Tillverkaren har en fullständig beskrivning.

Alla tjänster har flyttats till JVM, JRuby och Jetty. Trots de uppenbara fördelarna med integration finns det även nackdelar vad gäller minnesförbrukning.
Lambda-funktioner har lagts till för att bearbeta samlingar - nu finns det inget behov av att skära kryckor i Ruby eller pervertera via create_resources()
Ett verktyg för att bearbeta EPP-mallar har dykt upp - i princip samma ERB, men med Puppet DSL istället för Ruby,
Standardkatalogstrukturen för konfigurationsfiler har ändrats avsevärt
Tillagt stöd för dataleverantörer för miljöer och moduler (hack krävs inte längre).
Att tona ner rollen som den globala Hieran. Nytt och relaterat kommando är puppet lookup.

Installation

Denna process är ganska primitiv, men kräver att man följer en viss sekvens av steg. Eftersom att göra detta manuellt är en otacksam uppgift, kommer författaren att lära dig något dåligt, nämligen att ladda ner obegripliga skript från Internet och köra dem som root på ditt system.

De tre huvudsakliga serverkomponenterna är Puppet Server, PuppetDB och PostgreSQL. De kan alla packas in i en nod eller delas upp i två eller tre system. Puppet Server och Puppet DB kan köras flera gånger, men PostgeSQL är en enda felpunkt. Det finns olika tillvägagångssätt för PostgeSQL-replikering och klustring. Ett bekvämt tillvägagångssätt i fallet med huvud- och sekundärservrarna skulle vara Master + Read-Only Slave, som stöds i självaste PuppetDB som huvud- och skrivskyddad databasnod, men automatisering av sådana en installation tar tid och är därför ännu inte tillgänglig inkluderad i cfpuppetserver-modulen.

Själva konfigurationen kan enkelt lagras åtminstone på filsystem tillsammans med Puppet Server, men det är som att skriva skript på en produktionswebbserver. Den mest lämpliga lösningen är ett git-förråd. Verktyget r10k kan dra alla grenar av förvaret och distribuera dem till Puppet Server som separata miljöer. r10k är ganska dålig på att dra beroenden, så bibliotekarie-puppet används ovanpå. Det är värt att genast notera att den huvudsakliga kanoniska marionettmiljön är "produktion". Därför bör konfigurationsförrådet använda en gren som kallas "produktion" snarare än "master".

Systemkrav

Hårdvaran beskrivs av tillverkaren själv. Modulen cfpuppetserver stöder för närvarande endast Debian Jessie+ och Ubuntu Trusty+.

Konfiguration i Git

För r10k själv spelar platsen för förvaret ingen större roll - huvudsaken är dess tillgänglighet. Till exempel, för teständamål, kan förvaret vara värd på samma system och nås via file:// . Ett bra ställe att börja är konfigurationsexemplet codingfuture/puppet-exampleenv.

Klona förvaret: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Installera Allmänna Inställningar administratörsåtkomst med hjälp av tips i kommentarerna:
- $EDITOR data/common.yaml
Låt oss skapa en nodkonfiguration:
- $MY_DOMAIN - rotdomännamn (till exempel example.org)
- $HOST_NAME - klientens värdnamn utan domän
- mkdir data/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - ställa in en nod med Puppet Server enligt förslag i kommentarerna
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - inställning av en godtycklig nod baserat på förslag i kommentarerna
Vi pushar till vår egen Git-server eller gör den tillgänglig lokalt på en nod med Puppet Server via rsync eller scp. Ett lokalt arkiv är bekvämt som ett mellansteg tills Git-servern distribueras från Puppet själv. På sätt och vis påminner detta om att sätta ihop en kompilator i flera steg.

Installera från grunden på ett rent system

Modulen cfpuppetserver låter dig installera allt med Puppet själv, men för den första installationen dupliceras de grundläggande operationerna av ett Bash-skript.

På målsystemet:

Ladda ner installationsskriptet: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Vi tittar igenom skriptet och rynkar pannan: less setup_puppetserver.sh
Kör: bash setup_puppetserver.sh
marionett.$(MY_DOMAIN) .
- Exempel med ett fjärrlager: bash setup_puppetserver.sh ssh:// [e-postskyddad]/puppet-conf
- Exempel med lokal: bash setup_puppetserver.sh file:///root/puppetconf/
Vi ser hur systemet blåser upp och inte installerar allt särskilt snabbt.
Om förvaret är avlägset:
- Skapa en SSH-nyckel för root: ssh-keygen -t rsa -b 2048
- Vi registrerar den publika nyckeln /root/.ssh/id_rsa.pub på den fjärranslutna Git-servern...
- ... och där satte vi upp en Git-hook genom att anropa följande kommando: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Vi börjar distribuera konfigurationen manuellt: /etc/puppetlabs/deploy.sh
Låt oss prova hur det fungerar på själva servern: /opt/puppetlabs/bin/puppet agent --test
Kontrollera dina nätverksinställningar, överspänningsskydd och SSH-åtkomst

Lägger till hanterade noder

Puppet Serverns fullständiga namn måste vara tillgängligt via DNS på den hanterade värden eller hårdkodat till /etc/hosts.
- Exempel: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
På noden med Puppet Server, kör följande skript /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Kopiera hela resultatet och klistra in det kommandorad på målsystemet.
Vi väntar på slutet av körningen och kör /opt/puppetlabs/bin/puppet agent --test . Vid första lanseringen kommer en begäran om certifikatsignering att genereras.
Vi går till Puppet Server-noden för att signera certifikatet.
- puppet cert list - vi kontrollerar certifikatsignaturen för extra paranoia.
- marionettcertifikat tecken $(HOST_NAME).$(MY_DOMAIN) - faktiskt, vi signerar certifikatet.
Vi återvänder till den hanterade noden och kör: /opt/puppetlabs/bin/puppet agent --test` igen. Detta kommer att tvinga driftsättningsproceduren att starta.
Vi väntar på att distributionen ska slutföras via Puppet Agent.
Det är allt, du har en minimal Puppet-infrastruktur redo!

Exempel på utdata från /root/genclientinit.sh

våldsamt slag</etc/cflocation fi if test ! -z ""; sedan echo -n >/etc/cflocationpool fi if test ! -z "\$http_proxy"; exportera sedan http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! vilken lsb-release | läsa; sedan apt-get installera lsb-release fi codename=\$(lsb_release -cs) om test -z "\$kodnamn"; eko sedan "Det gick inte att upptäcka korrekt kodnamn" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(kodnamn) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<puppet cert sign host.example.com" echo "Använd CTRL+C för att stoppa cykeln, om det misslyckas på grund av olika anledningar" vila 5 klar EOT

Modulbeskrivning

Komplett lista över Bash-parametrar för det initiala installationsskriptet

~# ./setup_puppetserver.sh Användning: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI för Git-förvaret
certname - fullständigt kvalificerat domännamn för värden
cflocation - initiering av faktumet cf_location
cflocationpool - initiering av fakta cf_location_pool
http_proxy - proxyserver för HTTP- och HTTPS-förfrågningar

Komplett lista över Bash-parametrar för Puppet-klientens initialiseringsskript

~# /root/genclientinit.sh Användning: ./genclientinit.sh [ [ []]]
Innebörden av parametrarna är densamma som i föregående skript.

cfpuppetserver klass

deployuser = "deploypuppet" - användarnamn för att automatiskt distribuera konfigurationsuppdateringar
deployuser_auth_keys = undef - lista över nycklar för $deployuser
repo_url = undef - repository URI (exempel: ssh://user@host/repo eller file:///some/path)
puppetserver = true - om Puppet Server-komponenten ska installeras på denna nod
puppetdb = true - om PuppetDB-komponenten ska installeras på denna nod
puppetdb_port = 8081 - port för PuppetDB
setup_postgresql = true - om PostgreSQL-komponenten ska installeras på denna nod (endast om PuppetDB-installationen är aktiverad)
service_face = "any" - namnet på cfnetwork::iface-resursen för att acceptera inkommande anslutningar
puppetserver_mem = auto - RAM för Puppet Server i megabyte (minst 192 MB)
puppetdb_mem = auto - RAM för PuppetDB i megabyte (minst 192 MB)
postgresql_mem = auto - RAM för PostgreSQL i megabyte (minst 128 MB)

klass cfpuppetserver::puppetdb

postgresql_host = "localhost" - databasadress
postgresql_listen = $postgresql_host - värdet går direkt till listen_addresses PostgreSQL-direktivet
postgresql_port = 5432 - databasport
postgresql_user = "puppetdb" - PuppetDB-användare i databasen
postgresql_pass = "puppetdb" - lösenord för PuppetDB-användaren i databasen
postgresql_ssl = false - aktivera anslutningskryptering baserat på Puppet PKI-certifikat

klass cfpuppetserver::puppetserver

autosign = false - SKA INTE användas i en stridsmiljö, förutom kanske i DMZ. Finns uteslutande för testautomatisering.
global_hiera_config = "cfpuppetserver/hiera.yaml" - sökväg till den förinställda Hiera-konfigurationsfilen enligt Puppet-kanoner (den första komponenten är namnet på modulen, resten är sökvägen under filerna/mappen i modulen)

Du kan hjälpa till och överföra en del medel för utvecklingen av webbplatsen

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, skript kan bara delvis hjälpa, 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 kommer du att märka att inget liknande någonsin slagit fast. Det finns lösningar som kickstart som hjälper till med den första installationen operativ system, men ytterligare förfining kommer att kräva betydande ansträngningar. Kommersiella lösningar som BladeLogic och OpsWare löser bara delvis problemet med att automatisera inställningar; deras främsta fördel är tillgängligheten GUI, och de kan endast köpas från stora organisationer. Det finns naturligtvis projekt som erbjuder gratislösningar, men under hela deras existens har de aldrig 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 att skapa konfigurationer. När du beskriver uppgifter måste du ta hänsyn till funktionerna i varje specifikt system och manuellt kontrollera sekvensen av åtgärder när du kö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 faktiskt ett enmansprojekt som kontrollerar alla förändringar och inte är särskilt intresserad av att bygga ett öppet samhälle. Som ett resultat är kapaciteten 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 cfengines brister.

Dockfunktioner

Puppet, liksom cfengine, är ett klient-serversystem som använder ett deklarativt, det vill säga ett obligatoriskt språk för att beskriva uppgifter och bibliotek för deras implementering. Klienter ansluter regelbundet (30 minuter 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. Servern kan spara meddelanden till syslog eller en fil, skapa en RRD-graf och skicka dem till en 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 endast med objekttypen, Puppet tar hand om resten. Sålunda känner pakettypen till om 17 paketsystem; det nödvändiga kommer att kännas igen automatiskt baserat på information om versionen av distributionen eller systemet, även om pakethanteraren vid behov kan tvingas fram.

Till skillnad från skript, som ofta inte är möjliga att använda på andra system, kommer Puppet-konfigurationer skrivna av tredjepartsadministratörer, för det mesta, att fungera utan problem på något annat nätverk. I Puppet CookBook [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] finns det 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å vidare måste du först förstå språkets grundläggande delar och förmågor. Språk är en av styrkor Marionett. Med dess hjälp beskrivs de resurser som administratören planerar att hantera och åtgärder. Till skillnad från de flesta liknande lösningar låter Puppet språket 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,

Nu kommer klienter, efter att ha anslutit till servern, att kopiera filen /etc/passwd och installera de angivna attributen. Du kan definiera flera resurser i en regel, separera dem med ett semikolon. Vad ska man göra 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 VPN-inställningar anslutningar. I det här fallet kan filen pekas på med hjälp av källdirektivet. Det finns två alternativ här, som vanligt, för att ange sökvägen till en annan fil; två URI-protokoll stöds också: fil och marionett. I det första fallet en länk till en extern NFS-server, i det andra alternativet lanseras en NFS-liknande tjänst 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 endast från vissa adresser. Låt oss till exempel beskriva konfigurationssektionen.

sökväg /var/puppet/config

tillåt *.domain.com

tillåt 192.168.0.*

tillåt 192.168.1.0/24

neka *.wireless.domain.com

Och sedan går 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 ett alias eller variabler som ett namn. Aliaset ställs in med hjälp av aliasdirektivet. fullständig sökväg till filen. I mer komplexa konfigurationer

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",

default => "/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 tas emot ny fil, bör du starta om tjänsten.

säkerställ => 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, anger de ofta 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.

"/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 kan anslutas med inkluderingsdirektivet. 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 hemkatalogen för användare och de kommandon som krävs för att skapa ett nytt konto.

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

user("$name":

säkerställa => närvarande,

kommentar => "$fullnamn",

gid => "$grupp",

grupper => $ingroups,

medlemskap => minimum,

skal => "/bin/bash",

home => "/hem/$namn",

kräver => Grupp[$grupp],

exec("$name homedir":

kommando => “/bin/cp -R /etc/skel /home/$name; /bin/chown -R $namn:$grupp /hem/$namn",

skapar => "/hem/$namn",

kräver => Användare[$namn],

Nu ska du skapa en ny konto kontakta bara user_homedir.

user_homedir("sergej":

grupp => "sergej",

fullständigt namn => “Sergej Jaremchuk”,

ingroups => ["media", "admin]

Det finns separata beskrivningar av noder som stöder arv 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, arbeta med SSH-nycklar, Solaris-zoner och så vidare. Så enkelt är det att tvinga listan över paket i distributioner med hjälp av apt att uppdateras varje dag mellan 2 och 4 timmar.

schema (dagligen:

period => dagligen,

intervall =>

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 (>= 1.8.1) med OpenSSL-stöd och XMLRPC-bibliotek, samt Faster-biblioteket [ http://reductivelabs.com/projects/facter]. Ubuntu 7.04-förrådet som användes för testinstallationen inkluderade redan valppaketet.

$ sudo apt-cache sökdocka

marionett — centraliserad konfigurationshantering för nätverk

puppetmaster - centraliserad kontrolldemon för konfigurationshantering

Under installationen kommer alla nödvändiga beroendepaket att installeras: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get installera puppet puppetmaster

Du kan kontrollera tillgängligheten för Ruby-bibliotek med kommandot.

$ ruby -ropenssl -e "puts:yep"

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

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 arbeta i offlineläge, i vilket fall manifestet inte krävs

$ 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.

file("/etc/sudoers":

ägare => rot,

grupp => rot,

Alla konfigurationsfiler för både servern och klienterna finns i /etc/puppet. Filen fileserver.conf som vi pratade om ovan ä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

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 de e-postadresser som rapporterna 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 på klientsystemet, skriv in kommandot:

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

info: Begär certifikat

varning: peer-certifikat kommer inte att verifieras i denna SSL-session

meddelande: Fick inte certifikat

Om en annan rad returneras bör du kontrollera serverns funktion.

$ ps aux | grep docka

docka 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 ruby/usr/sbin/puppetmasterd

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

På servern får vi en lista över certifikat som behöver signeras.

$ sudo puppetca --lista

nomad.grinder.com

Och vi signerar kundcertifikatet.

$ sudo puppetca –sign nomad.grinder.com

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

Tyvärr är det helt enkelt inte mö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 problem med samtidig administration av ett stort antal system. Om ditt arbete kräver att du konfigurerar flera 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.

Marionettär en plattformsoberoende struktur som tillåter systemadministratörer Utför 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 dockan 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-adresser och domännamn från exemplet till dina nuvarande adresser och namn på servern och klienterna.

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 ytterligare information se

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, skript kan bara delvis hjälpa, 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 endast med objekttypen, Puppet tar hand om resten. Pakettypen känner alltså till 17 paketsystem; det nödvändiga kommer att kännas igen automatiskt baserat på information om versionen av distributionen eller systemet, även om pakethanteraren vid behov 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å vidare måste du först förstå språkets grundläggande delar 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 låter Puppet språket 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 startas en NFS-liknande tjänst 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"

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

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ändarens 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, kontakta bara 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

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

$ 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

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!