Hvordan bruges dukkemoduler til automatisering af it-infrastruktur?

Tidligere brugte systemadministratorer shell-scripts til at køre deres servere, og denne metode havde ingen skalerbarhed. Det er en skræmmende opgave at konstant ændre scripts til hundreder eller tusinder af stadigt skiftende servere og deres systemkonfigurationer.

I denne artikel om marionetmoduler og manifester lad os se, hvordan vi kunne bruge marionetmoduler til automatisering af serveropsætning, programinstallation og systemadministration.

Denne blog vil dække følgende emner:

• Introduktion til marionetprogrammering
• Nøgleudtryk i Puppet Programming
• Marionetprogram Workflow
• Demonstration: Automatisering af installationen af ​​Apache & MySQL

Introduktion til marionetprogrammering

Marionet er et af de populært anvendte DevOps-værktøjer, der er meget brugt til konfigurationsstyring. Det bruges til at skabe konsistens i infrastrukturen. Puppet kan definere infrastruktur som kode, administrere flere servere og håndhæve systemkonfiguration og dermed hjælpe med at automatisere processen med infrastrukturadministration.

Marionet harsit eget konfigurationssprog, Marionet DSL . Som med andre DevOps-programmer, Puppet automatiserer ændringer og eliminerer manuelle script-drevne ændringer. Dog er Puppet ikke blot et andet shell-sprog, og det er heller ikke et rent programmeringssprog, såsom PHP. I stedet bruger Puppettil deklarativ modelbaseret tilgang til it-automatisering. Dette gør det muligt for Puppet at definere infrastruktur som kode og håndhæve systemkonfiguration med programmer.

Før vi går videre med demoen, skal vi se på et par centrale aspekter af marionetprogrammering.

sortering af en matrix i c ++ - programmet

Nøgleudtryk i Puppet Programming

Manifester

Et marionetprogram kaldes manifest og har et filnavn med .pp udvidelse. Marionetens standardhovedmanifest er /etc/puppet/manifests/site.pp . (Dette definererglobale systemkonfigurationer, såsom LDAP-konfiguration, DNS-servere eller andre konfigurationer, der gælder for hver node).

Klasser

Inden for disse manifester kaldes kodeblokke klasser andre moduler kan ringe. Klasser konfigurerer store eller mellemstore klumper af funktionalitet, såsom alle pakker, konfigurationsfiler og tjenester, der er nødvendige for at køre en applikation. Klasser gør det lettere at genbruge Puppet-kode og forbedre læsbarheden.

Ressourcer

Marionetkode består hovedsagelig af ressourceerklæringer. EN ressource beskriver et specifikt element om systemets ønskede tilstand. For eksempel kan det omfatte, at en bestemt fil skal eksistere, eller at en pakke skal installeres.

Marionetmoduler

Bortset fra de vigtigstesite.ppmanifestere,det gemmer manifesteri moduler .

Alle vores marionetkoder er organiseret i moduler, som er de grundlæggende byggesten til marionet, som vi kan genbruge og dele. Hvert modul administrerer en bestemt opgave i infrastrukturen, såsom installation og konfiguration af et stykke software.

Moduler indeholder marionetklasser, definerede typer, opgaver, opgaveplaner, kapacitet, ressourcetyper og plugins, f.eks. Tilpassede typer eller fakta. Installer moduler i marionettenmodul-sti. Puppet indlæser alt indhold fra hvert modul i modulstien, hvilket gør denne kode tilgængelig til brug.

Puppetlabs har foruddefinerede moduler, som vi kan bruge med det samme ved at downloade dem fra PuppetForge . Du kan også oprette et brugerdefineret marionetmodul, der passer til dine behov.

Marionetprogram Workflow

Vi bruger Puppets deklarative sprog til at beskrive systemets ønskede tilstand i filer kaldet manifest. Manifester beskriver, hvordan du skal konfigurere dine netværks- og operativsystemressourcer, såsom filer, pakker og tjenester.

Marionet kompilerer manifesterer sig i kataloger og det anvender hvert katalog på dets tilsvarende node for at sikre, at konfigurationen af ​​than knude er korrektpå tværs af din infrastruktur.

Demonstration: Automatisering af installationen af ​​Apache & MySQL

Denne artikel om marionetmoduler er praktisk, der viser to måder at bruge et marionetmodul på og også lærer dig, hvordan du gør det automatisere installationen af ​​en server konfigureret med disse to moduler.

• • Oprettelse af et marionetmodul fra bunden - Apache-modul
  • Brug af et Puppet-modul fra PuppetForge - MySQL-modul
  • Automatisering af installationen af ​​dukkemodulerne fra marionetmester til marionetagent

Til at begynde med skal du sørge for, at du har en opsat marionetinfrastruktur klar, der inkluderer en marionetmasterserver og 2 marionetagenter.

• Marionetmester: Ubuntu 18.04
• Agent 1: Ubuntu 18.04
• Agent 2:CentOS7

Her er en oversigt over, hvad vi vil opnå i denne praktiske:

Så lad os begynde med det praktiske:

Oprettelse af et modul fra bunden

I dette marionetmodul beskæftiger vi os med opgaver som at downloade Apache-pakken, konfigurere filer og opsætte virtuelle værter.

• Gå til Puppet's modulkatalog fra Puppet Master, og opret Apache-biblioteket:

  cd / etc / marionet / moduler sudo mkdir apache

• Opret underkataloger inde fra apache-biblioteket: manifester, skabeloner, filer og eksempler.

  cd apache sudo mkdir {manifester, skabeloner, filer, eksempler}

• Naviger til manifestmappen:

  cd manifesterer

• Herfra vil vi adskille modulet i klasser baseret på målene for det kode afsnit.

init.pp -> for at downloade Apache-pakken

params.pp -> for at definere eventuelle variabler og parametre

config.pp -> til at administrere eventuelle konfigurationsfiler til Apache-tjenesten.

vhosts.pp -> for at definere de virtuelle værter.

Dette modul vil også gøre brug af Hiera (et indbygget opslagssystem til nøgleværdi-konfigurationsdata, der bruges til at adskille data fra Puppet-kode) -data, for at gemme variabler for hver node.

Trin 1: Download af Apache-pakke

Opret init.pp-klasse

Nu opretter vi eninit.ppfil under manifestmappen for at holde apache-pakken.
Da vi har 2 forskellige OS (ubuntu og CentOS7), der bruger forskellige pakkenavne til Apache, bliver vi nødt til at bruge en variabel$ apachename.

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

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

pakke ressource muliggør styring af en pakke. Dette bruges til at tilføje, fjerne eller sikre, at en pakke er til stede.

I de fleste tilfælde er navn af ressourcen (apache, ovenfor) skal være navnet på den pakke, der administreres. På grund af de forskellige navngivningskonventioner,vi kalder det faktiske navn på pakkenvidere med navn reference. Så navn , opfordrer til den endnu ikke udefinerede variabel$ apachename.

sikre reference sikrer, at pakken ertil stede.

Opret params.pp-fil

Detparams.ppfil definerer de nødvendige variabler. Mens vi kunne definere disse variabler inden forinit.ppfil, da flere variabler skal bruges uden for selve ressourcetypen ved hjælp af enparams.pp-fil giver mulighed for at definere variabler ihvisudsagn og bruges på tværs af flere klasser.

Lave enparams.ppfil og den 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 understøttet distro. ')}}

Uden for originalen init.ppklasse, skal hvert klassenavn forgrene sig fraapache. Vi kalder denne klasse som apache :: params . Navnet efter dobbelt kolon skal dele et navn med filen. Anhvissætning bruges til at definere parametrene, trække fra information leveret af Faktor , Puppet har facterinstallation som en del af selve installationen. Her vil Facter trække operativsystemfamilien ned (osfamilie) for at skelne om det errød hatellerDebian-baseret.

Med de endelige parametre defineret, skal vi kalde params.pp fil og parametrene tilinit.pp. For at gøre dette skal vi tilføje parametrene efter klassens navn, men før den åbne krøllede parentes({).

Såinit.ppsom vi oprettede tidligere, skulle se sådan ud:

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

Værdistrengen $ :: apache :: params :: værdi fortæller Puppet at trække værdierne fra apache moduler, params klasse efterfulgt af parameternavnet. Fragmentet arver :: apache :: params giver mulighed forinit.ppat arve disse værdier.

Trin 2: Administrer konfigurationsfiler

Apache-konfigurationsfilen vil være forskellig afhængigt af om du arbejder på et Red Hat- eller Debian-baseret system.

Du kan finde følgende afhængighedsfiler i slutningen af ​​denne demo:httpd.conf(Rød hat),apache2.conf(Debian).

• Kopier indholdet af httpd.conf ogapache2.confi separate filer og gem dem i filer vejviserpå / etc / puppetlabs / code / miljøer / produktion / moduler / apache / filer .
• Rediger begge filer til deaktiver holde i live. Du bliver nødt til at tilføje linjen KeepAlive slukket ihttpd.conffil. Hvis du ikke vil ændre denne indstilling, skal vi tilføje en kommentar øverst på hverfil:
  /etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf

#Denne fil administreres af marionet

Føj disse filer tilinit.ppfil, så Puppet kender placeringen af ​​disse filer på både masterserveren og agentnoder. For at gøre dette bruger vi fil ressource.

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

fil {'konfigurationsfil': sti => $ conffile, sikre => fil, kilde => $ confsource,}

Da vi har konfigurationsfilerne to forskellige placeringer, giver vi ressourcen det generiske navn konfigurationsfil med filen sti defineret som en parameter medstiattribut.

sikre sikrer, at det er en fil.

kilde giver placeringen på Puppet master for de filer, der er oprettet ovenfor.

Åbnparams.ppfil.

Vi definerer $ conffile og $ confsourcevariabler inden forhvisudmelding:

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

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

Vi skal tilføje parametrene til begyndelsen afapacheklassedeklaration iinit.ppfil, svarende til det foregående eksempel.

Når konfigurationsfilen ændres, skal Apache genstarte. For at automatisere dette kan vi bruge serviceressourceni kombination med underrette attribut, som kalder ressourcen til at køre, når konfigurationsfilen ændres:

/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 ressource bruger den allerede oprettede parameter, der definerede Apache-navnet på Red Hat og Debian-systemer.
har genstart attribut bruges til at udløse en genstart af den definerede tjeneste.

html-tabel i en tabel

Trin 3: Opret de virtuelle værtsfiler

Afhængigt af dit systems distribution styres den virtuelle værts filer forskelligt. På grund af dette indkapsler vi koden til virtuelle værter i enhviserklæring, svarende til den, der bruges iparams.ppklasse, men indeholder faktiske marionetressourcer.

• Indefraapache / manifesterer /mappe, opret og åbn envhosts.ppfil. Tilføj skelet afhvisudmelding:

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

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

Placeringen af ​​den virtuelle værtsfil på vores CentOS 7-server er/etc/httpd/conf.d/vhost.conf . Du skal oprette filen som en skabelon på Puppet master. Gør det samme for Ubuntu virtuelle værtsfilen, som findes på/etc/apache2/sites-available/example.com.conf, erstattereksempel.commed serverens FQDN.

• Naviger til skabeloner fil i apache modul, og opret derefter to filer til dine virtuelle værter:

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 kombineret

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 kombineretKræv alle tildelte

Vi bruger kun to variabler i disse filer: adminemail og server navn . Vi definerer disse på en node-for-node-basis inden forsite.ppfil.

• Gå tilbage tilvhosts.ppfil. De oprettede skabeloner kan nu henvises til i koden:

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

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

Begge distributionsfamilier ringer tilfilressource og tage titlen på den virtuelle værts placering på den respektive distribution. For Debian betyder dette endnu en gang henvisning til$ servernavnværdi. Detindholdattribut kalder de respektive skabeloner.

• Begge virtuelle værtsfiler refererer til to mapper. De er ikke på systemerne som standard. Vi kan skabe disse ved hjælp affilressource, hver inden forhvisudmelding. Det komplettevhosts.conffilen skal ligne:

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

klasse apache :: vhosts {hvis $ :: osfamily == 'RedHat' {fil {'/etc/httpd/conf.d/vhost.conf': sikre => fil, indhold => skabelon ('apache / vhosts-rh .conf.erb '),} fil {[' / var / www / $ servernavn ',' / var / www / $ servernavn / public_html ',' / var / www / $ servernavn / log ',]: sikre => bibliotek,}} elsif $ :: osfamily == 'Debian' {fil {'/etc/apache2/sites-available/$servername.conf': sikre => fil, indhold => skabelon ('apache / vhosts-deb. conf.erb '),} fil {[' / var / www / $ servername ',' / var / www / $ servername / public_html ',' / var / www / $ servername / logs ',]: sikre => bibliotek ,}} ellers {fail ('Dette er ikke en understøttet distro.')}}

Trin 4: Test modulet

• Naviger tilapache / manifesterer /bibliotek, kør marionetparser på alle filer for at sikre, at dukkekodningen er uden fejl:

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

Det skal returneres tomt uden problemer.

• Naviger til eksempler bibliotek iapachemodul. Opret eninit.ppfil og inkluderer de oprettede klasser. Erstat værdierne 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 modulet ved at køre marionet gælder med –Nå tag:
  sudo / opt / puppetlabs / bin / marionet gælder - ingen init.pp

Det skal ikke returnere nogen fejl og output, som det vil udløse opdateringer fra begivenheder. For at installere og konfigurere apache på Puppet master skal du køre igen uden–Nå, hvis det ønskes.

• Naviger tilbage til hoveddukkekataloget og derefter tilmanifesterer sigmappe (ikkeden der findes i Apache-modulet).

cd / etc / puppetlabs / code / miljøer / produktion / manifester

Lave ensite.ppfil,og inkluderer Apache-modulet for hver agentknude. Indtast også variablerne foradminemail og server navnparametre. Dinsite.ppskal ligne 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å dine administrerede noder automatisk tjekke med masteren en gang hvert 30. minut og anvende nye konfigurationer fra masteren. Du kan også manuelt påkalde Puppet agent-processen imellem automatiske agentkørsler. For at køre det nye modul manuelt på dine agentknudepunkter skal du logge på knudepunkterne og køre:

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

Nu hvor vi har lært, hvordan man opretter et modul fra bunden, skal vi lære at bruge et allerede eksisterende modul fra marionetens smedning af puppetlabs.

Brug et modul fra PuppetForge

Puppet Forge har allerede mange moduler, som serveren kan køre. Vi kan konfigurere disse lige så omfattende som et modul, du oprettede, og kan spare tid, da vi ikke behøver at oprette modulet fra bunden.

Sørg for, at du er i / etc / puppetlabs / code / miljøer / produktion / moduler bibliotek og installer Puppet Forges MySQL-modul af PuppetLabs. Dette installerer også alle forudsætningsmoduler.

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

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

Brug Hiera til at oprette databaser

Inden du opretter konfigurationsfilerne til MySQL-modulet, skal du overveje, at du måske ikke vil bruge de samme værdier på tværs af alle agentknudepunkter. For at forsyne Puppet med de korrekte data pr. Node bruger vi Hiera. Du bruger en anden rodadgangskode pr. Node og opretter således forskellige MySQL-databaser.

• Naviger til/ etc / marionetog oprette Hieras konfigurationsfilhiera.yamli det væsentligemarionetvejviser. Du bruger Hieras standardværdier:

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

--- version: 5 hierarki: - navn: Fælles sti: common.yaml standard: data_hash: yaml_data datadir: data

• Opret filenfælles.yaml. Det definerer standard rod adgangskode til MySQL:

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

mysql :: server :: root_password: 'password'

Vi brugerfælles.yamlfilnår en variabel ikke er defineret andetsteds. Dette betyder, at alle servere deler den samme MySQL-rodadgangskode. Disse adgangskoder kan også hashes for at øge sikkerheden.

• For at bruge MySQL-modulets standardindstillinger kan du tilføje en inkluderer ':: mysql :: server' linje tilsite.ppfil. I dette eksempel tilsidesætter du dog nogle af modulets standardindstillinger for at oprette en database for hver af dine noder.

Redigersite.ppfil med følgende værdier:

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 = > $ domæne,}} 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 => $ domæne,}}

Automatisering af installationen af ​​dukkemodulerne fra marionetmester til marionetagent

• Du kan køre disse opdateringer manuelt på hver node ved at SSHing ind i hver node og udstede følgende kommando:

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

• Ellers vil Puppet-agent-tjenesten på dine administrerede noder automatisk tjekke med masteren en gang hvert 30. minut og anvende nye konfigurationer fra masteren.

Katalog anvendt med succes på Ubuntu-agent

Kataloget blev anvendt med succes på CentOS-agenten

Således bliver hele installationen automatiseret på agentknudepunkterne ved blot at anvende kataloget.Kodefiler og afhængigheder, der bruges til denne demo, kan findes her .

Jeg håber, at denne demo har hjulpet dig med at få en klar idé om marionetmoduler og manifester og deres anvendelse til automatisering af it-infrastrukturen.I dette tilfælde bliver dit arbejde så let, bare angiv konfigurationerne i Puppet Master, og Puppet-agenter evaluerer automatisk hovedmanifestet og anvender modulet, der specificerer Apache og MySQL-opsætning. Hvis du sidder fast med spørgsmål, er du velkommen til at sende dem på .

Hvis du fandt dette Marionettevejledning relevant, tjek den af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka DevOps-certificeringskursus hjælper elever med at få ekspertise i forskellige DevOps-processer og -værktøjer såsom Puppet, Jenkins, Nagios og GIT til automatisering af flere trin i SDLC.

hvordan man kører atom python