Hur använder man dockmoduler för IT-infrastrukturautomation?

Tidigare använde systemadministratörer shell-skript för att köra sina servrar, och den här metoden hade ingen skalbarhet. Det är en skrämmande uppgift att ständigt ändra skript för hundratals eller tusentals ständigt föränderliga servrar och deras systemkonfigurationer.

I den här artikeln på marionettmoduler och manifest låt oss se hur vi kan använda marionettmoduler för att automatisera serverinstallation, programinstallation och systemhantering.

Den här bloggen kommer att täcka följande ämnen:

• Introduktion till marionettprogrammering
• Nyckelord i Puppet Programming
• Dockprogram arbetsflöde
• Demonstration: Automatisera installationen av Apache & MySQL

Introduktion till marionettprogrammering

Marionett är ett av de populära DevOps-verktygen som ofta används för konfigurationshantering. Det används för att åstadkomma konsistens i infrastrukturen. Puppet kan definiera infrastruktur som kod, hantera flera servrar och genomdriva systemkonfiguration, vilket hjälper till att automatisera processen för infrastrukturhantering.

Dockan harsitt eget konfigurationsspråk, Puppet DSL . Som med andra DevOps-program, Puppet automatiserar ändringar och eliminerar manuella skriptdrivna ändringar. Dock är dock inte bara ett annat skalspråk och inte heller ett rent programmeringsspråk, till exempel PHP. Istället använder Puppettill deklarativ modellbaserad strategi till IT-automatisering. Detta gör det möjligt för Puppet att definiera infrastruktur som kod och genomdriva systemkonfiguration med program.

Innan vi går vidare med demo, låt oss titta på några kärnaspekter av marionettprogrammering.

hur man öppnar aws cli

Nyckelord i Puppet Programming

Manifester

Ett marionettprogram kallas manifestera och har ett filnamn med .pp förlängning. Puppets standard huvudmanifest är /etc/puppet/manifests/site.pp . (Detta definierarglobala systemkonfigurationer, till exempel LDAP-konfiguration, DNS-servrar eller andra konfigurationer som gäller för varje nod).

Klasser

Inom dessa manifest kallas kodblock klasser andra moduler kan ringa. Klasser konfigurerar stora eller medelstora funktioner som alla paket, konfigurationsfiler och tjänster som behövs för att köra ett program. Klasser gör det lättare att återanvända Puppet-kod och förbättrar läsbarheten.

Resurser

Marionettkod består mestadels av resursdeklarationer. A resurs beskriver ett specifikt element om systemets önskade tillstånd. Det kan till exempel innehålla att en specifik fil ska finnas eller ett paket ska installeras.

Dockmoduler

Förutom huvudetsite.ppmanifestera,det lagrar manifesti moduler .

All vår marionettkod är organiserad i moduler som är de grundläggande byggstenarna för marionett som vi kan återanvända och dela. Varje modul hanterar en specifik uppgift i infrastrukturen, till exempel installation och konfigurering av en mjukvara.

Moduler innehåller dockklasser, definierade typer, uppgifter, uppgiftsplaner, kapacitet, resurstyper och plugins, till exempel anpassade typer eller fakta. Installera moduler i Puppetmodul-sökväg. Puppet laddar allt innehåll från varje modul i modulvägen, vilket gör den här koden tillgänglig för användning.

Puppetlabs har fördefinierade moduler som vi kan använda direkt genom att ladda ner dem från PuppetForge . Du kan också skapa en anpassad marionettmodul som passar dina behov.

Dockprogram arbetsflöde

Vi kommer att använda Puppets deklarativa språk för att beskriva systemets önskade tillstånd i filer som kallas manifest. Manifester beskriver hur du ska konfigurera dina nätverks- och operativsystemresurser, såsom filer, paket och tjänster.

Dockansamlingar manifesterar sig i kataloger och den tillämpar varje katalog på motsvarande nod för att säkerställa att konfigurationen av than nod är korrektöver din infrastruktur.

Demonstration: Automatisera installationen av Apache & MySQL

Den här artikeln om marionettmoduler är praktisk som visar två sätt att använda en marionettmodul och lär dig också hur man gör automatisera installationen av en server konfigurerad med dessa två moduler.

• • Skapa en dockmodul från grunden - Apache-modul
  • Med hjälp av en Puppet-modul från PuppetForge - MySQL-modul
  • Automatisera installationen av marionettmodulerna från marionettmästaren till marionettagenten

Till att börja med, se till att du har en Puppet-infrastruktur som är redo att innehålla en marionettmästarserver och två marionettagenter.

• Puppet Master: Ubuntu 18.04
• Agent 1: Ubuntu 18.04
• Agent 2:CentOS7

Här är en översikt över vad vi kommer att uppnå i denna praktiska:

Så låt oss börja med hands-on:

Skapa en modul från grunden

I den här dockmodulen kommer vi att hantera uppgifter som att ladda ner Apache-paketet, konfigurera filer och konfigurera virtuella värdar.

• Från Puppet Master navigerar du till Puppets modulkatalog och skapar Apache-katalogen:

  cd / etc / marionett / moduler sudo mkdir apache

• Skapa underkataloger inifrån apache-katalogen: manifest, mallar, filer och exempel.

  cd apache sudo mkdir {manifest, mallar, filer, exempel}

• Navigera till manifestkatalogen:

  cd-manifest

• Härifrån kommer vi att separera modulen i klasser baserat på målen för den delen av koden.

init.pp -> för att ladda ner Apache-paketet

params.pp -> för att definiera alla variabler och parametrar

config.pp -> för att hantera eventuella konfigurationsfiler för Apache-tjänsten.

vhosts.pp -> för att definiera de virtuella värdarna.

Denna modul kommer också att använda Hiera (ett inbyggt nyckel-värde konfigurationsdatasökningssystem, som används för att separera data från Puppet code) -data, för att lagra variabler för varje nod.

Steg 1: Ladda ner Apache-paketet

Skapa init.pp-klass

Nu ska vi skapa eninit.ppfil under manifest-katalogen för att hålla apache-paketet.
Eftersom vi har två olika operativsystem (ubuntu och CentOS7) som använder olika paketnamn för Apache, måste vi använda en variabel$ apachename.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

klass apache {paket {'apache': namn => $ apachename, försäkra => närvarande,}}

paket resurs möjliggör hantering av ett paket. Detta används för att lägga till, ta bort eller se till att ett paket finns.

I de flesta fall har namn av resursen (apacheovan) bör vara namnet på paketet som hanteras. På grund av de olika namngivningskonventionerna,vi kallar det faktiska namnet på paketetpå med namn referens. Så namn , kräver den ändå odefinierade variabeln$ apachename.

säkerställa referens säkerställer att paketet ärnärvarande.

Skapa fil params.pp

Deparams.ppfilen definierar de variabler som behövs. Medan vi kunde definiera dessa variabler inominit.ppfil eftersom fler variabler måste användas utanför själva resurstypen med hjälp av enparams.ppfilen möjliggör att variabler kan definieras iomuttalanden och används i flera klasser.

Skapa enparams.ppfilen och följande kod.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp

klass apache :: params {if $ :: osfamily == 'RedHat' {$ apachename = 'httpd'} elsif $ :: osfamily == 'Debian' {$ apachename = 'apache2'} annat {misslyckas ('detta är inte en distro som stöds. ')}}

Utanför originalet init.ppklass måste varje klassnamn förgrenas frånapache. Vi kallar den här klassen som apache :: params . Namnet efter dubbelpunkten ska dela ett namn med filen. Ettomuttalande används för att definiera parametrarna, hämtad från information från Faktor , Puppet har facterinstallation som en del av själva installationen. Här kommer Facter att dra ner operativsystemfamiljen (osfamilj), för att urskilja om det ärröd hattellerDebianbaserat.

När parametrarna slutligen är definierade måste vi ringa params.pp filen och parametrarna tillinit.pp. För att göra detta måste vi lägga till parametrarna efter klassnamnet, men före den inledande lockiga fästet({).

Så deninit.ppsom vi skapade tidigare borde se ut så här:

klass apache ($ apachename = $ :: apache :: params :: apachename,) ärver :: apache :: params {package {'apache': name => $ apachename, ensure => present,}}

Värdesträngen $ :: apache :: params :: värde säger Puppet att dra värdena från apache moduler, params klass, följt av parameternamnet. Fragmentet ärver :: apache :: params tillåter attinit.ppatt ärva dessa värden.

Steg 2: Hantera konfigurationsfiler

Apache-konfigurationsfilen varierar beroende på om du arbetar på ett Red Hat- eller Debian-baserat system.

Du hittar följande beroendefiler i slutet av denna demo:httpd.conf(Röd hatt),apache2.conf(Debian).

• Kopiera innehållet i httpd.conf ochapache2.confi separata filer och spara dem i filer katalogpå / etc / puppetlabs / code / miljöer / produktion / moduler / apache / filer .
• Redigera båda filerna till inaktivera håll vid liv. Du måste lägga till raden KeepAlive avstängd ihttpd.conffil. Om du inte vill ändra den här inställningen bör vi lägga till en kommentar överst på varjefil:
  /etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf

#Denna fil hanteras av marionett

Lägg till dessa filer iinit.ppfil, så Puppet vet platsen för dessa filer på både huvudservern och agentnoderna. För att göra detta använder vi fil resurs.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

fil {'configuration-file': path => $ conffile, ensure => file, source => $ confsource,}

Eftersom vi har konfigurationsfilerna på två olika platser ger vi resursen det generiska namnet konfigurationsfil med filen väg definieras som en parameter medvägattribut.

säkerställa säkerställer att det är en fil.

källa ger platsen för Puppet-mastern för filerna som skapats ovan.

Öppnaparams.ppfil.

Vi definierar $ conffile och $ confsourcevariabler inomompåstående:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp

om $ :: osfamily == 'RedHat' {... $ conffile = '/etc/httpd/conf/httpd.conf' $ confsource = 'marionett: ///modules/apache/httpd.conf'} elsif $: : osfamily == 'Debian' {... $ conffile = '/etc/apache2/apache2.conf' $ confsource = 'marionett: ///modules/apache/apache2.conf'} annat {...

Vi måste lägga till parametrarna i början avapacheklassdeklaration iinit.ppsom liknar föregående exempel.

När konfigurationsfilen ändras måste Apache startas om. För att automatisera detta kan vi använda tjänstresurseni kombination med meddela attribut, som kommer att anropa resursen att köras när konfigurationsfilen ändras:

vad betyder övergående i Java

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

fil {'configuration-file': path => $ conffile, ensure => file, source => $ confsource, notify => Service ['apache-service'],} service {'apache-service': name => $ apachename, hasrestart => true,}

service resurs använder den redan skapade parametern som definierade Apache-namnet på Red Hat och Debian-system.
har omstart attribut används för att utlösa en omstart av den definierade tjänsten.

Steg 3: Skapa virtuella värdfiler

Beroende på ditt systems distribution kommer den virtuella värdens filer att hanteras annorlunda. På grund av detta kommer vi att koda koden för virtuella värdar i enomuttalande, liknande det som används iparams.ppklass men innehåller faktiska marionettresurser.

• Inifrånapache / manifesterar /katalog, skapa och öppna envhosts.ppfil. Lägg till skelettet avompåstående:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

klass apache :: vhosts {if $ :: osfamily == 'RedHat' {} elsif $ :: osfamily == 'Debian' {} annat {}}

Platsen för den virtuella värdfilen på vår CentOS 7-server är/etc/httpd/conf.d/vhost.conf . Du måste skapa filen som en mall på Puppet master. Gör detsamma för Ubuntu virtuella värdfiler, som finns på/etc/apache2/sites-available/example.com.conf, byter utexempel.commed serverns FQDN.

• Navigera till mallar fil i apache modul och skapa sedan två filer för dina virtuella värdar:

För Red Hat-system:
/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb

ServerAdmin ServerName ServerAlias ​​www. DocumentRoot / var / www // public_html / ErrorLog /var/www//logs/error.log CustomLog /var/www//logs/access.log kombinerat

För Debian-system:
/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb

ServerAdmin ServerName ServerAlias ​​www. DocumentRoot / var / www / html // public_html / ErrorLog /var/www/html//logs/error.log CustomLog /var/www/html//logs/access.log kombineratKräv alla beviljade

Vi använder bara två variabler i dessa filer: administratörsmeddelande och server namn . Vi kommer att definiera dessa på nod-för-nod-basis, inomsite.ppfil.

• Återgå tillvhosts.ppfil. Mallarna som skapas kan nu hänvisas till i koden:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

klass apache :: vhosts {if $ :: osfamily == 'RedHat' {file {'/etc/httpd/conf.d/vhost.conf': ensure => file, content => template ('apache / vhosts-rh .conf.erb '),}} elsif $ :: osfamily ==' Debian '{file {' /etc/apache2/sites-available/$servername.conf ': ensure => file, content => template (' apache /vhosts-deb.conf.erb '),}} else {fail (' Detta är inte en distro som stöds. ')}}

Båda distributionsfamiljerna ringer tillfilresurs och ta titeln på den virtuella värdens plats på respektive distribution. För Debian betyder detta än en gång att referera till$ servernamnvärde. Deinnehållattribut anropar respektive mallar.

• Båda virtuella värdfilerna refererar till två kataloger. De finns inte på systemen som standard. Vi kan skapa dessa med hjälp avfilresurs, var och en inomompåstående. Det fullständigavhosts.conffilen ska likna:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

klass apache :: vhosts {if $ :: osfamily == 'RedHat' {file {'/etc/httpd/conf.d/vhost.conf': ensure => file, content => template ('apache / vhosts-rh .conf.erb '),} fil {[' / var / www / $ servernamn ',' / var / www / $ servernamn / public_html ',' / var / www / $ servernamn / log ',]: försäkra => katalog,}} elsif $ :: osfamily == 'Debian' {file {'/etc/apache2/sites-available/$servername.conf': ensure => file, content => template ('apache / vhosts-deb. conf.erb '),} fil {[' / var / www / $ servernamn ',' / var / www / $ servernamn / public_html ',' / var / www / $ servernamn / loggar ',]: försäkra => katalog ,}} else {fail ('Detta är inte en distro som stöds.')}}

Steg 4: Testa modulen

• Navigera tillapache / manifesterar /katalog, kör marionettparser på alla filer för att säkerställa att Puppet-kodningen är utan fel:

sudo / opt / puppetlabs / bin / puppet parser validera init.pp params.pp vhosts.pp

Den ska returnera tom, utan problem.

• Navigera till exempel katalog iapachemodul. Skapa eninit.ppfilen och inkludera de skapade klasserna. Ersätt värdena för$ servernamnoch$ adminemailmed din egen:

/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp

sortera en matris c ++

serveremail = 'webmaster@example.com' $ servername = 'puppet.example.com' include apache include apache :: vhosts

• Testa modulen genom att köra marionett applicera med - Nej märka:
  sudo / opt / puppetlabs / bin / marionett tillämpa - ingen init.pp

Det ska inte returnera några fel och mata ut att det kommer att utlösa uppdateringar från händelser. För att installera och konfigurera apache på Puppet master, kör igen utan- Nej, om så önskas.

• Navigera tillbaka till huvuddockakatalogen och sedan tillmanifesterar sigmapp (inteden som finns i Apache-modulen).

cd / etc / puppetlabs / code / miljöer / produktion / manifest

Skapa ensite.ppfil,och inkludera Apache-modulen för varje agentnod. Mata också in variablerna föradministratörsmeddelande och server namnparametrar. Dinsite.ppbör likna följande:

/etc/puppetlabs/code/environments/production/manifests/site.pp

nod 'puppet-agent-ubuntu.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'puppet.example.com' include apache include apache :: vhosts} node 'puppet-agent-centos.example .com '{$ adminemail =' webmaster@example.com '$ servername =' puppet.example.com 'include apache include apache :: vhosts}

Som standard kontrollerar Puppet-agenttjänsten på dina hanterade noder automatiskt med mastern en gång var 30: e minut och tillämpar eventuella nya konfigurationer från mastern. Du kan också manuellt anropa Puppet-agentprocessen mellan automatiska agentkörningar. För att manuellt köra den nya modulen på dina agentnoder loggar du in på noderna och kör:

sudo / opt / puppetlabs / bin / puppet agent -t

Nu när vi har lärt oss hur man skapar en modul från grunden, låt oss lära oss hur man använder en befintlig modul från marionettens smide av marionettlabbar.

Använd en modul från PuppetForge

Puppet Forge har redan många moduler för servern att köra. Vi kan konfigurera dessa lika omfattande som en modul du skapade och kan spara tid eftersom vi inte behöver skapa modulen från grunden.

Se till att du är i / etc / puppetlabs / code / miljöer / produktion / moduler katalog och installera Puppet Forges MySQL-modul av PuppetLabs. Detta kommer också att installera alla nödvändiga moduler.

cd / etc / puppetlabs / code / miljöer / produktion / moduler

sudo / opt / puppetlabs / bin / puppet module install puppetlabs-mysql

Använd Hiera för att skapa databaser

Innan du skapar konfigurationsfilerna för MySQL-modulen, tänk på att du kanske inte vill använda samma värden i alla agentnoder. För att förse Puppet med rätt data per nod använder vi Hiera. Du kommer att använda ett annat rotlösenord per nod och därmed skapa olika MySQL-databaser.

• Navigera till/ etc / marionettoch skapa Hieras konfigurationsfilhiera.yamli huvudsakmarionettkatalog. Du kommer att använda Hieras standardvärden:

/etc/puppetlabs/code/environments/production/hiera.yaml

--- version: 5 hierarki: - namn: Gemensam sökväg: common.yaml standard: data_hash: yaml_data datadir: data

• Skapa filengemensam.yaml. Det definierar standard rot lösenord för MySQL:

/etc/puppetlabs/code/environments/production/common.yaml

mysql :: server :: root_password: 'lösenord'

Vi användergemensam.yamlfilnär en variabel inte definieras någon annanstans. Det betyder att alla servrar kommer att dela samma MySQL-root-lösenord. Dessa lösenord kan också hashas för att öka säkerheten.

• För att använda standardinställningarna för MySQL-modulen kan du lägga till en inkludera ‘:: mysql :: server’ linje tillsite.ppfil. I det här exemplet åsidosätter du dock vissa av modulens standardvärden för att skapa en databas för var och en av dina noder.

Redigerasite.ppfil med följande värden:

nod 'Puppetagent-ubuntu.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb_ $ {fqdn} ': user =>' myuser ', password =>' mypass ', dbname =>' mydb ', host => $ :: fqdn, grant => [' SELECT ',' UPDATE '], tag = > $ domain,}} nod 'Puppetagent-centos.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb _ $ {fqdn}': user => 'myuser', password => 'mypass', dbname => 'mydb', host => $ :: fqdn, grant => ['SELECT', ' UPPDATERING]], tag => $ domän,}}

Automatisera installationen av marionettmodulerna från marionettmästaren till marionettagenten

• Du kan köra dessa uppdateringar manuellt på varje nod genom att SSHing i varje nod och utfärda följande kommando:

sudo / opt / puppetlabs / bin / puppet agent -t

• Annars kontrollerar Puppet-agenttjänsten på dina hanterade noder automatiskt med mastern en gång var 30: e minut och tillämpar eventuella nya konfigurationer från mastern.

Katalogen tillämpades framgångsrikt på Ubuntu-agenten

Katalogen tillämpades framgångsrikt på CentOS-agenten

Således blir hela installationen automatiserad på agentnoderna genom att bara tillämpa katalogen.Kodfilerna och beroenden som används för denna demo finns här .

Jag hoppas att denna demo har hjälpt dig att få en tydlig uppfattning om dockmoduler och manifest och deras användning för att automatisera IT-infrastrukturen.I det här fallet blir ditt arbete så enkelt, bara ange konfigurationerna i Puppet Master och Puppet-agenter utvärderar automatiskt huvudmanifestet och tillämpar modulen som anger Apache- och MySQL-installation. Om du har problem med några frågor kan du gärna lägga upp dem på .

Om du hittade det här Puppet Tutorial relevant, kolla in av Edureka, ett pålitligt inlärningsföretag online med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka DevOps Certification Training-kursen hjälper eleverna att få expertis inom olika DevOps-processer och verktyg som Puppet, Jenkins, Nagios och GIT för att automatisera flera steg i SDLC.