PostgreSQL-implementatie en configuratie met Puppet

Puppet is open source software voor configuratiebeheer en implementatie. Opgericht in 2005, is multi-platform en heeft zelfs zijn eigen declaratieve taal voor configuratie.

De taken met betrekking tot beheer en onderhoud van PostgreSQL (of eigenlijk andere software) bestaat uit dagelijkse, repetitieve processen die monitoring vereisen. Dit geldt zelfs voor taken die worden uitgevoerd door scripts of opdrachten via een planningstool. De complexiteit van deze taken neemt exponentieel toe wanneer ze worden uitgevoerd op een enorme infrastructuur, maar het gebruik van Puppet voor dit soort taken kan dit soort grootschalige problemen vaak oplossen, aangezien Puppet de prestaties van deze bewerkingen op een zeer flexibele manier centraliseert en automatiseert.

Puppet werkt binnen de architectuur op client/server-niveau waar de configuratie wordt uitgevoerd; deze operaties worden vervolgens verspreid en uitgevoerd op alle clients (ook bekend als nodes).

Gewoonlijk draait het elke 30 minuten, het knooppunt van de agent verzamelt een reeks informatie (type processor, architectuur, IP-adres, enz.), ook wel feiten genoemd, en stuurt de informatie vervolgens naar de master die wacht op een antwoord om te zien of er nieuwe configuraties zijn om toe te passen.

Deze feiten stellen de master in staat om dezelfde configuratie voor elk knooppunt aan te passen.

Puppet is heel simpel gezegd een van de belangrijkste DevOps-tools vandaag beschikbaar. In deze blog zullen we het volgende bekijken...

De use case voor Puppet &PostgreSQL
Puppet installeren
Puppet configureren en programmeren
Puppet configureren voor PostgreSQL

De hieronder beschreven installatie en configuratie van Puppet (versie 5.3.10) werd uitgevoerd in een set hosts die CentOS 7.0 als besturingssysteem gebruikten.

De use case voor Puppet &PostgreSQL

Stel dat er een probleem is in uw firewall op de machines die al uw PostgreSQL-servers hosten, dan zou het nodig zijn om alle uitgaande verbindingen met PostgreSQL te weigeren en dit zo snel mogelijk te doen.

Puppet is de perfecte tool voor deze situatie, vooral omdat snelheid en efficiëntie belangrijk zijn. essentieel. We zullen het hebben over dit voorbeeld dat wordt gepresenteerd in de sectie "Puppet configureren voor PostgreSQL" door de parameter listen_addresses te beheren.

Puppet installeren

Er zijn een aantal algemene stappen die moeten worden uitgevoerd op master- of agenthosts:

Stap één

Bijwerken van /etc/hosts-bestand met hostnamen en hun IP-adres

192.168.1.85 agent agent.severalnines.com

192.168.1.87 master master.severalnines.com puppet

Stap twee

De Puppet-opslagplaatsen aan het systeem toevoegen

$ sudo rpm –Uvh https://yum.puppetlabs.com/puppet5/el/7/x86_64/puppet5-release-5.0.0-1-el7.noarch.rpm

Voor andere besturingssystemen of CentOS-versies is de meest geschikte repository te vinden in Puppet, Inc. Yum Repositories.

Stap drie

Configuratie van NTP-server (Network Time Protocol)

$ sudo yum -y install chrony

Stap vier

De chrony wordt gebruikt om de systeemklok van verschillende NTP-servers te synchroniseren en houdt zo de tijd gesynchroniseerd tussen de master- en agentserver.

Eenmaal chrony geïnstalleerd, moet het worden ingeschakeld en opnieuw worden gestart:

$ sudo systemctl enable chronyd.service

$ sudo systemctl restart chronyd.service

Stap vijf

Schakel de SELinux parameter uit

In het bestand /etc/sysconfig/selinux moet de parameter SELINUX (Security-Enhanced Linux) worden uitgeschakeld om de toegang op beide hosts niet te beperken.

SELINUX=disabled

Stap zes

Vóór de Puppet-installatie (master of agent) moet de firewall in deze hosts dienovereenkomstig worden gedefinieerd:

$ sudo firewall-cmd -–add-service=ntp -–permanent 

$ sudo firewall-cmd –-reload

De Puppet Master installeren

Zodra de pakketrepository puppet5-release-5.0.0-1-el7.noarch.rpm aan het systeem is toegevoegd, kan de puppetserver-installatie worden uitgevoerd:

$ sudo yum install -y puppetserver

De parameter max. geheugentoewijzing is een belangrijke instelling om het bestand /etc/sysconfig/puppetserver bij te werken naar 2 GB (of naar 1 GB als de service niet start):

JAVA_ARGS="-Xms2g –Xmx2g "

In het configuratiebestand /etc/puppetlabs/puppet/puppet.conf is het nodig om de volgende parametrering toe te voegen:

[master]

dns_alt_names=master.severalnines.com,puppet



[main]

certname = master.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

De puppetserver-service gebruikt de poort 8140 om naar de node-verzoeken te luisteren, dus het is noodzakelijk om ervoor te zorgen dat deze poort wordt ingeschakeld:

$ sudo firewall-cmd --add-port=8140/tcp --permanent

$ sudo firewall-cmd --reload

Zodra alle instellingen in Puppet Master zijn gemaakt, is het tijd om deze service te starten:

$ sudo systemctl start puppetserver

$ sudo systemctl enable puppetserver

De Puppet Agent installeren

De Puppet-agent in de pakketrepository puppet5-release-5.0.0-1-el7.noarch.rpm wordt ook aan het systeem toegevoegd, de installatie van de puppet-agent kan meteen worden uitgevoerd:

$ sudo yum install -y puppet-agent

Het puppet-agent configuratiebestand /etc/puppetlabs/puppet/puppet.conf moet ook worden bijgewerkt door de volgende parameter toe te voegen:

[main]

certname = agent.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

De volgende stap bestaat uit het registreren van het agentknooppunt op de masterhost door het volgende commando uit te voeren:

$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true

service { ‘puppet’:

ensure => ‘running’,

enable => ‘true’

  }

Op dit moment is er op de masterhost een verzoek in behandeling van de marionetagent om een certificaat te ondertekenen:

Dat moet worden ondertekend door een van de volgende opdrachten uit te voeren:

$ sudo /opt/puppetlabs/bin/puppet cert sign agent.severalnines.com

$ sudo /opt/puppetlabs/bin/puppet cert sign --all

Eindelijk (en zodra de puppet master het certificaat heeft ondertekend) is het tijd om de configuraties toe te passen op de agent door de catalogus op te halen bij de puppet master:

$ sudo /opt/puppetlabs/bin/puppet agent --test

In deze opdracht betekent de parameter --test geen test, de instellingen die uit de master worden opgehaald, worden toegepast op de lokale agent. Om de configuraties van master te testen/controleren moet het volgende commando worden uitgevoerd:

$ sudo /opt/puppetlabs/bin/puppet agent --noop

Puppet configureren en programmeren

Puppet gebruikt een declaratieve programmeerbenadering waarbij het doel is om te specificeren wat te doen en het maakt niet uit op welke manier!

Het meest elementaire stukje code op Puppet is de bron die een systeemeigenschap specificeert, zoals commando, service, bestand, directory, gebruiker of pakket.

Hieronder staat de syntaxis van een bron om een gebruiker aan te maken:

user { 'admin_postgresql':

  ensure     => present,

  uid        => '1000',

  gid        => '1000',

  home       => '/home/admin/postresql'

}

Verschillende bronnen kunnen worden toegevoegd aan de voormalige klasse (ook bekend als een manifest) van bestanden met de extensie "pp" (het staat voor Puppet Program), niettemin kunnen verschillende manifesten en gegevens (zoals feiten, bestanden en sjablonen) zullen een module samenstellen. Alle logische hiërarchieën en regels worden weergegeven in het onderstaande diagram:

Het doel van elke module is om alle benodigde manifesten te bevatten om enkele opdrachten modulair. Aan de andere kant is het concept van klasse niet hetzelfde als in objectgeoriënteerde programmeertalen, in Puppet werkt het als een aggregator van bronnen.

De organisatie van deze bestanden heeft een specifieke mapstructuur die moet worden gevolgd:

Waarop het doel van elke map het volgende is:

Map

Beschrijving

manifesteert

Marionetcode

bestanden

Statische bestanden die naar knooppunten moeten worden gekopieerd

sjablonen

Sjabloonbestanden die moeten worden gekopieerd naar beheerde knooppunten (het kan worden aangepast met variabelen)

voorbeelden

Manifest om te laten zien hoe de module te gebruiken

De klassen (manifesten) kunnen door andere klassen worden gebruikt, zoals weergegeven in het onderstaande voorbeeld:de manifest init.pp op dev_accounts gebruiken de manifestgroepen uit de accountsmodule.

class dev_accounts {

  $rootgroup = $osfamily ? {

    'Debian'  => 'sudo',

    'RedHat'  => 'wheel',

    default   => warning('This distribution is not supported by the Accounts module'),

  }



  include accounts::groups



  user { 'username':

    ensure      => present,

    home        => '/home/admin/postresql',

    shell       => '/bin/bash',

    managehome  => true,

    gid         => 'admin_db',

    groups      => "$rootgroup",

    password    => '$1$7URTNNqb$65ca6wPFDvixURc/MMg7O1'

  }

}

In het volgende gedeelte laten we u zien hoe u de inhoud van de map met voorbeelden kunt genereren, evenals de opdrachten om elke module te testen en te publiceren.

Puppet configureren voor PostgreSQL

Voordat u de verschillende configuratievoorbeelden presenteert voor het implementeren en onderhouden van een PostgreSQL-database, moet u de PostgreSQL-poppenmodule (op de serverhost) installeren om al hun functionaliteiten te gebruiken:

$ sudo /opt/puppetlabs/bin/puppet module install puppetlabs-postgresql

Momenteel zijn duizenden modules klaar voor gebruik op Puppet beschikbaar in de openbare modulerepository Puppet Forge.

Stap één

Configureer en implementeer een nieuwe PostgreSQL-instantie. Hier vindt u alle benodigde programmering en configuratie om een nieuwe PostgreSQL-instantie in alle knooppunten te installeren.

De eerste stap is het maken van een nieuwe modulestructuurmap zoals eerder gedeeld:

$ cd /etc/puppetlabs/code/environments/production/modules

$ mkdir db_postgresql_admin

$ cd db_postgresql_admin; mkdir{examples,files,manifests,templates}

Vervolgens moet u in het manifestbestand manifests/init.pp de klasse postgresql::server opnemen die wordt geleverd door de geïnstalleerde module :

class db_postgresql_admin{

  include postgresql::server

}

Om de syntaxis van het manifest te controleren, is het een goede gewoonte om de volgende opdracht uit te voeren:

$ sudo /opt/puppetlabs/bin/puppet parser validate init.pp

Als er niets wordt geretourneerd, betekent dit dat de syntaxis correct is

Om u in de voorbeeldmap te laten zien hoe u deze module gebruikt, moet u een nieuw manifestbestand init.pp maken met de volgende inhoud:

include db_postgresql_admin

De voorbeeldlocatie in de module moet worden getest en toegepast op de hoofdcatalogus:

$ sudo /opt/puppetlabs/bin/puppet apply --modulepath=/etc/puppetlabs/code/environments/production/modules --noop init.pp

Ten slotte is het nodig om te definiëren tot welke module elk knooppunt toegang heeft in het bestand "/etc/puppetlabs/code/environments/production/manifests/site.pp" :

node ’agent.severalnines.com’,’agent2.severalnines.com’{

 include db_postgresql_admin

}

Of een standaardconfiguratie voor alle knooppunten:

node default {

 include db_postgresql_admin

}

Meestal controleren de knooppunten elke 30 minuten de hoofdcatalogus, niettemin kan deze query aan de knooppuntzijde worden geforceerd door het volgende commando:

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

Of als het de bedoeling is om de verschillen tussen de masterconfiguratie en de huidige node-instellingen te simuleren, kan het de nopp-parameter worden gebruikt (geen bewerking):

$ /opt/puppetlabs/bin/puppet agent -t --noop

Stap twee

Update de PostgreSQL-instantie om alle interfaces te beluisteren. De vorige installatie definieert een instantie-instelling in een zeer beperkende modus:alleen verbindingen op localhost mogelijk zoals kan worden bevestigd door de hosts die zijn gekoppeld aan poort 5432 (gedefinieerd voor PostgreSQL):

$ sudo netstat -ntlp|grep 5432

tcp        0 0 127.0.0.1:5432          0.0.0.0:* LISTEN   3237/postgres       

tcp6       0 0 ::1:5432                :::* LISTEN   3237/postgres

Om alle interfaces te kunnen beluisteren, moet de volgende inhoud in het bestand /etc/puppetlabs/code/environments/production/modules/db_postgresql_admin/manifests/init.pp staan

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

       }

}

In het bovenstaande voorbeeld is de klasse postgresql::server gedeclareerd en de parameter listen_addresses ingesteld op "*", dat wil zeggen alle interfaces.

Nu is poort 5432 gekoppeld aan alle interfaces, dit kan worden bevestigd met het volgende IP-adres/poort:“0.0.0.0:5432”

$ sudo netstat -ntlp|grep 5432

tcp        0 0 0.0.0.0:5432            0.0.0.0:* LISTEN   1232/postgres       

tcp6       0 0 :::5432                 :::* LISTEN   1232/postgres

Om de oorspronkelijke instelling terug te zetten:sta alleen databaseverbindingen van localhost toe, de parameter listen_addresses moet worden ingesteld op "localhost" of desgewenst een lijst met hosts opgeven:

listen_addresses = 'agent2.severalnines.com,agent3.severalnines.com,localhost'

Om de nieuwe configuratie van de masterhost op te halen, hoeft u deze alleen op het knooppunt op te vragen:

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

Stap drie

Maak een PostgreSQL-database. De PostgreSQL-instantie kan worden gemaakt met een nieuwe database en een nieuwe gebruiker (met wachtwoord) om deze database te gebruiken en een regel in het pg_hab.conf-bestand om de databaseverbinding voor deze nieuwe gebruiker toe te staan:

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

  }



   postgresql::server::db{‘nines_blog_db’:

     user => ‘severalnines’,          password=> postgresql_password(‘severalnines’,’passwd12’)

   }



   postgresql::server::pg_hba_rule{‘Authentication for severalnines’:

     Description =>’Open access to severalnines’,

     type => ‘local’,

database => ‘nines_blog_db’,

     user => ‘severalnines’,

address => ‘127.0.0.1/32’

         auth_method => ‘md5’

   }

}

Deze laatste bron heeft de naam "Authenticatie voor meerdere negens" en het bestand pg_hba.conf heeft nog een extra regel:

# Rule Name: Authentication for severalnines

# Description: Open access for severalnines

# Order: 150

local   nines_blog_db   severalnines 127.0.0.1/32    md5

Om de nieuwe configuratie van de masterhost op te halen, hoeft u deze alleen maar op te vragen op het knooppunt:

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

Stap vier

Maak een alleen-lezen gebruiker aan. Om een nieuwe gebruiker met alleen-lezen-rechten aan te maken, moeten de volgende bronnen worden toegevoegd aan het vorige manifest:

postgresql::server::role{‘Creation of a new role nines_reader’:

createdb   => false,

createrole => false,

superuser => false,     password_hash=> postgresql_password(‘nines_reader’,’passwd13’)

}

postgresql::server::pg_hba_rule{‘Authentication for nines_reader’:

     description =>’Open access to nines_reader’,

     type => ‘host’,

database => ‘nines_blog_db’,

     user => ‘nines_reader’,

address => ‘192.168.1.10/32’,

         auth_method => ‘md5’

   }

Om de nieuwe configuratie van de masterhost op te halen, hoeft u deze alleen maar op te vragen op het knooppunt:

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

Conclusie

In deze blogpost hebben we u de basisstappen laten zien om uw PostgreSQL-database te implementeren en te configureren via een automatische en aangepaste manier op verschillende knooppunten (dit kunnen zelfs virtuele machines zijn).

Dit soort automatisering kan u helpen effectiever te worden dan handmatig te doen en PostgreSQL-configuratie kan eenvoudig worden uitgevoerd door verschillende klassen te gebruiken die beschikbaar zijn in de puppetforge-repository