Hvordan bruke Puppet Modules for IT Infrastructure Automation?



En praktisk dukkeopplæring som snakker om å skrive en marionettmodul og bruke et manifest for å automatisere og vedlikeholde IT-infrastrukturen til en organisasjon.

Tidligere brukte systemadministratorer shell-skript for å kjøre serverne sine, og denne metoden hadde ingen skalerbarhet. Det er en skremmende oppgave å stadig endre skript for hundrevis eller tusenvis av stadig skiftende servere og deres systemkonfigurasjoner.

I denne artikkelen på dukkemoduler og manifestasjoner la oss se hvordan vi kan bruke marionettmoduler for å automatisere serveroppsett, programinstallasjon og systemadministrasjon.





Denne bloggen vil dekke følgende emner:

Introduksjon til dukkeprogrammering

Marionett er et av de populære DevOps-verktøyene som brukes mye for konfigurasjonsadministrasjon. Den brukes til å få til konsistens i infrastrukturen. Puppet kan definere infrastruktur som kode, administrere flere servere og håndheve systemkonfigurasjon, og dermed hjelpe til med å automatisere prosessen med infrastrukturadministrasjon.



Marionett harsitt eget konfigurasjonsspråk, Marionett DSL . Som med andre DevOps-programmer, Puppet automatiserer endringer, eliminerer manuelle manusdrevne endringer. Puppet er imidlertid ikke bare et annet skallsspråk, og det er heller ikke et rent programmeringsspråk, for eksempel PHP. I stedet bruker Puppettil deklarativ modellbasert tilnærming til IT-automatisering. Dette gjør det mulig for Puppet å definere infrastruktur som kode og håndheve systemkonfigurasjon med programmer.

Før vi går videre med demoen, la oss se på noen kjerneaspekter ved dukkeprogrammering.

hvordan du setter opp atom for python

Nøkkelord i Puppet Programming

Manifester

Et dukkeprogram kalles manifestere og har et filnavn med .pp Utvidelse. Puppets standard hovedmanifest er /etc/puppet/manifests/site.pp . (Dette definererglobale systemkonfigurasjoner, for eksempel LDAP-konfigurasjon, DNS-servere eller andre konfigurasjoner som gjelder for hver node).



Klasser

Innenfor disse manifestene kalles kodeblokker klasser andre moduler kan ringe. Klasser konfigurerer store eller mellomstore funksjoner som for eksempel alle pakkene, konfigurasjonsfilene og tjenestene som trengs for å kjøre et program. Klasser gjør det lettere å bruke Puppet-kode og forbedre lesbarheten.

Ressurser

Dukkekode består hovedsakelig av ressurserklæringer. EN ressurs beskriver et bestemt element om systemets ønskede tilstand. For eksempel kan det inkludere at en bestemt fil skal eksistere eller at en pakke skal installeres.

Marionettmoduler

Bortsett fra hovedsite.ppmanifestere,den lagrer manifestasjoneri moduler .

All dukkekoden vår er organisert i moduler som er de grunnleggende byggesteinene til dukken som vi kan gjenbruke og dele. Hver modul klarer en spesifikk oppgave i infrastrukturen, for eksempel å installere og konfigurere en programvare.

Moduler inneholder Puppet-klasser, definerte typer, oppgaver, oppgaveplaner, kapasiteter, ressurstyper og plugins, for eksempel tilpassede typer eller fakta. Installer moduler i Puppetmodul-bane. Puppet laster alt innhold fra hver modul i modulbanen, og gjør denne koden tilgjengelig for bruk.

Moduler - Marionettprogrammering - EdurekaPuppetlabs har forhåndsdefinerte moduler som vi kan bruke umiddelbart ved å laste dem ned fra PuppetForge . Du kan også lage en tilpasset dukkemodul som passer dine behov.

Puppet Program Workflow

Vi vil bruke Puppets erklærende språk for å beskrive ønsket tilstand i systemet i filer som kalles manifest. Manifester beskriver hvordan du skal konfigurere nettverks- og operativsystemressursene dine, for eksempel filer, pakker og tjenester.

Dukkekompilering manifesterer seg i kataloger og den bruker hver katalog på den tilsvarende noden for å sikre at konfigurasjonen av than node er riktigpå tvers av infrastrukturen din.

Demonstrasjon: Automatisering av installasjonen av Apache og MySQL

Denne artikkelen om dukkemoduler er praktisk som viser to måter å bruke en dukkemodul på, og som også lærer deg hvordan du gjør det automatisere installasjonen av en server konfigurert med disse to modulene.

Til å begynne med må du sørge for at du har satt opp en Puppet-infrastruktur som inkluderer en puppet master-server og to marionettagenter.

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

Her er en oversikt over hva vi vil oppnå i denne praktiske:


Så la oss begynne med praktisk:

Opprette en modul fra bunnen av

I denne dukkemodulen vil vi håndtere oppgaver som å laste ned Apache-pakken, konfigurere filer og sette opp virtuelle verter.

  • Fra Puppet Master navigerer du til Puppets modulkatalog og oppretter Apache-katalogen:
    cd / etc / puppet / modules sudo mkdir apache
  • Opprette underkataloger fra apache-katalogen: manifester, maler, filer og eksempler.
    cd apache sudo mkdir {manifester, maler, filer, eksempler}
  • Naviger til manifestkatalogen:
    cd manifesterer seg
  • Herfra vil vi skille modulen i klasser basert på målene for den delen av koden.

init.pp -> for å laste ned Apache-pakken

params.pp -> for å definere variabler og parametere

config.pp -> for å administrere eventuelle konfigurasjonsfiler for Apache-tjenesten.

vhosts.pp -> for å definere de virtuelle vertene.

Denne modulen vil også bruke Hiera (et innebygd oppslagssystem for nøkkelverdi-konfigurasjonsdata, brukt til å skille data fra Puppet code) -data, for å lagre variabler for hver node.

Trinn 1: Laste ned Apache-pakken

Opprett init.pp-klasse

Nå skal vi lage eninit.ppfilen under manifest-katalogen for å holde apache-pakken.
Siden vi har to forskjellige operativsystemer (ubuntu og CentOS7) som bruker forskjellige pakkenavn for Apache, må vi bruke en variabel$ apachename.

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

klasse apache {pakke {'apache': navn => $ apachename, sikre => til stede,}}

pakke ressurs tillater styring av en pakke. Dette brukes til å legge til, fjerne eller sikre at en pakke er tilstede.

I de fleste tilfeller er Navn av ressursen (apache, ovenfor) skal være navnet på pakken som administreres. På grunn av de forskjellige navnekonvensjonene,vi kaller det faktiske navnet på pakkenvidere med Navn referanse. Så Navn , krever den ennå udefinerte variabelen$ apachename.

sørge for referanse sikrer at pakken ertilstede.

Lag params.pp-fil

Deparams.ppfilen vil definere de nødvendige variablene. Mens vi kunne definere disse variablene iinit.ppfil, siden flere variabler må brukes utenfor selve ressurstypen, ved hjelp av enparams.pp-fil gjør det mulig å definere variabler ihvisuttalelser og brukes på tvers av flere klasser.

Lage enparams.ppfilen og følgende kode.

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

klasse apache :: params {if $ :: osfamily == 'RedHat' {$ apachename = 'httpd'} elsif $ :: osfamily == 'Debian' {$ apachename = 'apache2'} ellers {fail ('dette er ikke en støttet distro. ')}}

Utenfor originalen init.ppklasse, må hvert klassenavn forgrene seg fraapache. Vi kaller denne klassen som apache :: params . Navnet etter dobbelt kolon skal dele et navn med filen. Anhvissetning brukes til å definere parametrene, hentet fra informasjon gitt av Faktor , Puppet har facterinstallasjon som en del av selve installasjonen. Her vil Facter trekke ned operativsystemfamilien (osfamilie), for å se om det erRød hattellerDebian-basert.

Når parametrene endelig er definert, må vi kalle params.pp filen og parametrene tilinit.pp. For å gjøre dette må vi legge til parametrene etter klassenavnet, men før den krøllete parentesen({).

init.ppsom vi opprettet tidligere, burde se slik ut:

klasse apache ($ apachename = $ :: apache :: params :: apachename,) arver :: apache :: params {pakke {'apache': navn => $ apachename, sikre => til stede,}}

Verdistrengen $ :: apache :: params :: verdi forteller Puppet å trekke verdiene fra apache moduler, params klasse, etterfulgt av parameternavnet. Fragmentet arver :: apache :: params tillaterinit.ppå arve disse verdiene.

Trinn 2: Administrer konfigurasjonsfiler

Apache-konfigurasjonsfilen vil være forskjellig, avhengig av om du jobber med et Red Hat- eller Debian-basert system.

finn største antall i java

Du finner følgende avhengighetsfiler på slutten av denne demoen:httpd.conf(Rød hatt),apache2.conf(Debian).

  • Kopier innholdet av httpd.conf ogapache2.confi separate filer og lagre dem i filer katalog / etc / puppetlabs / code / miljøer / produksjon / moduler / apache / filer .
  • Rediger begge filene til deaktivere holde i live. Du må legge til linjen KeepAlive av ihttpd.conffil. Hvis du ikke vil endre denne innstillingen, bør vi legge til en kommentar øverst på hverfil:
    /etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf
#Denne filen administreres av marionett

Legg til disse filene iinit.ppfil, slik at Puppet vil vite plasseringen av disse filene på både hovedserveren og agentnodene. For å gjøre dette bruker vi fil ressurs.

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

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

Fordi vi har konfigurasjonsfilene på to forskjellige steder, gir vi ressursen det generiske navnet konfigurasjonsfil med filen sti definert som en parameter medstiEgenskap.

sørge for sørger for at det er en fil.

kilde gir posisjonen til Puppet master for filene som er opprettet ovenfor.

Åpneparams.ppfil.

Vi definerer $ conffile og $ confsourcevariabler innenforhvisuttalelse:

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

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

Vi må legge til parametrene i begynnelsen avapacheklassedeklarasjon iinit.ppfil, i likhet med forrige eksempel.

Når konfigurasjonsfilen endres, må Apache starte på nytt. For å automatisere dette kan vi bruke tjenestressurseni kombinasjon med gi beskjed attributt, som vil kalle ressursen til å kjøre når konfigurasjonsfilen endres:

/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 ressurs bruker den allerede opprettede parameteren som definerte Apache-navnet på Red Hat og Debian-systemer.
har startet på nytt attributt brukes til å utløse en omstart av den definerte tjenesten.

Trinn 3: Opprett de virtuelle vertsfilene

Avhengig av systemets distribusjon administreres filene til den virtuelle verten annerledes. På grunn av dette vil vi legge koden for virtuelle verter i enhvisuttalelse, lik den som er brukt iparams.ppklasse, men inneholder faktiske dukkeressurser.

  • Fra innsiden avapache / manifesterer /katalog, opprette og åpne envhosts.ppfil. Legg til skjelettet tilhvisuttalelse:

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

klasse apache :: vhosts {if $ :: osfamily == 'RedHat' {} elsif $ :: osfamily == 'Debian' {} annet {}}

Plasseringen til den virtuelle vertsfilen på CentOS 7-serveren er/etc/httpd/conf.d/vhost.conf . Du må opprette filen som en mal på Puppet master. Gjør det samme for Ubuntu virtuelle vertsfilen, som ligger på/etc/apache2/sites-available/example.com.conf, erstatteeksempel.commed serverens FQDN.

  • Naviger til maler filen i apache modul og deretter opprette to filer for dine virtuelle verter:

For Red Hat-systemer:
/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb

ServerAdmin Servernavn ServerAlias ​​www. DocumentRoot / var / www // public_html / ErrorLog /var/www//logs/error.log CustomLog /var/www//logs/access.log kombinert

For Debian-systemer:
/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb

ServerAdmin Servernavn ServerAlias ​​www. DocumentRoot / var / www / html // public_html / ErrorLog /var/www/html//logs/error.log CustomLog /var/www/html//logs/access.log kombinertKrev alle gitt

Vi bruker bare to variabler i disse filene: administrasjonspost og Server navn . Vi vil definere disse på en node-for-node basis, innenforsite.ppfil.

  • Gå tilbake tilvhosts.ppfil. Malene som er opprettet kan nå henvises til i koden:

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

klasse apache :: vhosts {if $ :: osfamily == 'RedHat' {fil {'/etc/httpd/conf.d/vhost.conf': sikre => fil, innhold => mal ('apache / vhosts-rh .conf.erb '),}} elsif $ :: osfamily ==' Debian '{fil {' /etc/apache2/sites-available/$servername.conf ': sikre => fil, innhold => mal (' apache /vhosts-deb.conf.erb '),}} annet {fail (' Dette er ikke en støttet distro. ')}}

Begge fordelingsfamiliene ringer tilfilressurs og ta tittelen på den virtuelle vertens beliggenhet på den respektive distribusjonen. For Debian betyr dette nok en gang å referere til$ servernavnverdi. Deinnholdattributt kaller de respektive malene.

  • Begge virtuelle vertsfilene refererer til to kataloger. De er ikke på systemene som standard. Vi kan lage disse gjennom bruk avfilressurs, hver innenforhvisuttalelse. Det komplettevhosts.conffilen skal ligne på:

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

klasse apache :: vhosts {if $ :: osfamily == 'RedHat' {fil {'/etc/httpd/conf.d/vhost.conf': sikre => fil, innhold => mal ('apache / vhosts-rh .conf.erb '),} fil {[' / var / www / $ servernavn ',' / var / www / $ servername / public_html ',' / var / www / $ servername / log ',]: sikre => katalog,}} elsif $ :: osfamily == 'Debian' {file {'/etc/apache2/sites-available/$servername.conf': ensure => file, content => template ('apache / vhosts-deb. conf.erb '),} fil {[' / var / www / $ servername ',' / var / www / $ servername / public_html ',' / var / www / $ serververname / logs ',]: sikre => katalog ,}} annet {fail ('Dette er ikke en støttet distro.')}}

Trinn 4: Test modulen

  • Naviger tilapache / manifesterer /katalogen, kjør dukkeparser på alle filer for å sikre at dukkekodingen er uten feil:

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

Den skal komme tom, uten problemer.

  • Naviger til eksempler katalog iapachemodul. Lag eninit.ppfilen og inkluderer de opprettede klassene. Erstatt verdiene for$ servernavnog$ adminemailmed din egen:

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

serveremail = 'webmaster@example.com' $ servername = 'puppet.example.com' inkluderer apache inkluderer apache :: vhosts
  • Test modulen ved å kjøre marionett gjelder med –Nei stikkord:
    sudo / opt / puppetlabs / bin / marionett gjelder - ingen init.pp

Det skal ikke gi noen feil og sende ut at det vil utløse oppdateringer fra hendelser. For å installere og konfigurere apache på Puppet master, kjør igjen uten–Nei, hvis ønskelig.

  • Naviger tilbake til hoveddukkekatalogen og deretter tilmanifesterer segmappe (ikkeden som er tilstede i Apache-modulen).

cd / etc / puppetlabs / code / miljøer / produksjon / manifestasjoner

Lage ensite.ppfil,og inkluderer Apache-modulen for hver agentnode. Skriv også inn variablene foradministrasjonspost og Server navnparametere. Dinsite.ppskal ligne på følgende:

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

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

Som standard vil Puppet-agenttjenesten på de administrerte nodene dine automatisk sjekke med masteren en gang hvert 30. minutt og bruke nye konfigurasjoner fra masteren. Du kan også manuelt påkalle Puppet agent-prosessen mellom automatiske agentkjøringer. For å kjøre den nye modulen manuelt på agentnodene, logger du på nodene og kjører:

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

Nå som vi har lært hvordan vi lager en modul fra bunnen av, la oss lære å bruke en eksisterende modul fra marionettens smie av puppetlabs.

Bruk en modul fra PuppetForge

Puppet Forge har allerede mange moduler som serveren kan kjøre. Vi kan konfigurere disse like omfattende som en modul du opprettet, og kan spare tid siden vi ikke trenger å opprette modulen fra bunnen av.

Forsikre deg om at du er i / etc / puppetlabs / code / miljøer / produksjon / moduler katalogen og installer Puppet Forge’s MySQL-modul av PuppetLabs. Dette vil også installere eventuelle forutsette moduler.

cd / etc / puppetlabs / code / miljøer / produksjon / moduler

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

Bruk Hiera til å opprette databaser

Før du oppretter konfigurasjonsfilene for MySQL-modulen, bør du vurdere at du kanskje ikke vil bruke de samme verdiene på tvers av alle agentnoder. For å forsyne Puppet med de riktige dataene per node, bruker vi Hiera. Du vil bruke et annet rotpassord per node, og dermed opprette forskjellige MySQL-databaser.

  • Navigere til/ etc / marionettog opprett Hieras konfigurasjonsfilhiera.yamli hovedmarionettkatalog. Du vil bruke Hieras standardverdier:

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

hva er en nøkkelfeil
--- versjon: 5 hierarki: - navn: Felles sti: common.yaml standard: data_hash: yaml_data datadir: data
  • Opprett filenvanlig.yaml. Det vil definere standard rot passord for MySQL:

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

mysql :: server :: root_password: 'passord'

Vi brukervanlig.yamlfilnår en variabel ikke er definert andre steder. Dette betyr at alle servere vil dele det samme MySQL root-passordet. Disse passordene kan også hasjes for å øke sikkerheten.

  • For å bruke standardinnstillingene til MySQL-modulen kan du legge til en inkluderer ‘:: mysql :: server’ linje tilsite.ppfil. I dette eksemplet vil du imidlertid overstyre noen av modulens standardverdier for å opprette en database for hver av nodene dine.

Redigersite.ppfil med følgende verdier:

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

Automatisering av installasjonen av Puppet Modules fra puppet master til puppet agent

  • Du kan kjøre disse oppdateringene manuelt på hver node ved å SSHing inn i hver node og utstede følgende kommando:

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

  • Ellers vil Puppet-agenttjenesten på de administrerte nodene dine automatisk sjekke med masteren en gang hvert 30. minutt og bruke nye konfigurasjoner fra masteren.

Katalogen ble brukt på Ubuntu-agent

Katalogen ble brukt vellykket på CentOS-agenten

Dermed blir hele installasjonen automatisert på agentnodene ved å bare bruke katalogen.Kodefilene og avhengighetene som brukes til denne demoen finner du her .

Jeg håper denne demonstrasjonen har hjulpet deg med å få en klar ide om marionettmoduler og manifestasjoner og deres bruk for automatisering av IT-infrastrukturen.I dette tilfellet blir arbeidet ditt så enkelt, bare angi konfigurasjonene i Puppet Master og Puppet-agenter vil automatisk evaluere hovedmanifestet og bruke modulen som spesifiserer Apache og MySQL-oppsett. Hvis du har problemer med spørsmål, kan du gjerne legge dem ut på .

Hvis du fant dette Dukkeopplæring relevant, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk med mer enn 250 000 fornøyde elever spredt over hele verden. Edureka DevOps Certification Training-kurset hjelper lærere å få ekspertise i forskjellige DevOps-prosesser og verktøy som Puppet, Jenkins, Nagios og GIT for å automatisere flere trinn i SDLC.