In het eerste deel van dit artikel hebben we Vagrant geconfigureerd om twee Ubuntu 14.04 Trusty Tahr virtuele machines uit te voeren, respectievelijk pg
genoemd. en backup
. In dit tweede deel bekijken we hoe je Puppet kunt gebruiken om een PostgreSQL-server op pg
in te stellen en te configureren. en maak er een back-up van via Barman vanuit de backup
doos.
Marionet:configuratie
Na het definiëren van de machines volgens het vorige artikel, moeten we de vereiste Puppet-modules specificeren die librarian-puppet
zal het voor ons regelen.
Er zijn twee modules vereist:
puppetlabs/postgresql
(http://github.com/puppetlabs/puppetlabs-postgresql/) om PostgreSQL te installeren op depg
VMit2ndq/barman
(http://github.com/2ndquadrant-it/puppet-barman) om Barman te installeren opbackup
Beide modules worden geïnstalleerd vanuit Puppet Forge. Voor de puppetlabs/postgresql
module, zullen we op dit moment maximaal versie 4.2.0 moeten gebruiken, aangezien de nieuwste versie (4.3.0) het postgres_password
verbreekt parameter die we later zullen gebruiken (zie dit pull-verzoek). Laten we een bestand maken met de naam Puppetfile
met deze inhoud in de projectdirectory:
forge "http://forgeapi.puppetlabs.com" mod "puppetlabs/postgresql", "<4.3.0" mod "it2ndq/barman" |
We kunnen nu de Puppet-modules en hun afhankelijkheden installeren door het volgende uit te voeren:
$ librarian-puppet install --verbose |
Hoewel dit niet essentieel is, verdient het de voorkeur om de optie --verbose
te gebruiken elke keer librarian-puppet
is gebruikt. Zonder dit is het commando erg stil en het is handig om van tevoren details te hebben over wat het doet. Bijvoorbeeld zonder --verbose
. te gebruiken , kom je er misschien achter dat je kostbare tijd hebt verspild met wachten tot een afhankelijkheidsconflict is opgelost, om vervolgens vele minuten later een fout te zien.
Na succesvolle voltooiing van de opdracht, a modules
map met de barman
en postgresql
modules en hun afhankelijkheden (apt
, concat
, stdlib
) wordt aangemaakt in onze werkdirectory. Bovendien, librarian-puppet
maakt de Puppetfile.lock
bestand om afhankelijkheden en versies van de geïnstalleerde modules te identificeren, en ze vast te zetten om toekomstige updates te voorkomen. Op deze manier wordt de volgende librarian-puppet install
runs zullen altijd dezelfde versie van de modules installeren in plaats van mogelijke upgrades (in het geval dat een upgrade nodig is, librarian-puppet update
zal het lukken).
Nu kunnen we Vagrant vertellen dat we een Puppet-manifest gebruiken om de servers in te richten. We wijzigen het Vagrantfile
als volgt:
Vagrant.configure("2") do |config| { :pg => { :ip => '192.168.56.221', :box => 'ubuntu/trusty64' }, :backup => { :ip => '192.168.56.222', :box => 'ubuntu/trusty64' } }.each do |name,cfg| config.vm.define name do |local| local.vm.box = cfg[:box] local.vm.hostname = name.to_s + '.local.lan' local.vm.network :private_network, ip: cfg[:ip] family = 'ubuntu' bootstrap_url = 'http://raw.github.com/hashicorp/puppet-bootstrap/master/' + family + '.sh' # Run puppet-bootstrap only once local.vm.provision :shell, :inline => <<-eos if [ ! -e /tmp/.bash.provision.done ]; then curl -L #{bootstrap_url} | bash touch /tmp/.bash.provision.done fi eos # Provision with Puppet local.vm.provision :puppet do |puppet| puppet.manifests_path = "manifests" puppet.module_path = [".", "modules"] puppet.manifest_file = "site.pp" puppet.options = [ '--verbose', ] end end end end |
Met de regels die we zojuist hebben toegevoegd, hebben we Vagrant de instructies gegeven om de VM's in te richten met behulp van manifests/site.pp
als het hoofdmanifest en de modules die zijn opgenomen in de modules
map. Dit is de definitieve versie van ons Vagrantfile
.
We moeten nu de manifests
. maken map:
$ mkdir manifests |
en schrijf daarin een eerste versie van site.pp
. We beginnen met een zeer eenvoudige installatie:
node backup { class { 'barman': manage_package_repo => true, } } node pg {} |
We kunnen nu de machines starten en dat zien op backup
er is een Barman-server met een standaardconfiguratie (en geen PostgreSQL op pg
nog). Laten we inloggen op backup
:
$ vagrant ssh backup |
en neem een kijkje op /etc/barman.conf
:
# Main configuration file for Barman (Backup and Recovery Manager for PostgreSQL) # Further information on the Barman project at www.pgbarman.org # IMPORTANT: Please do not edit this file as it is managed by Puppet! # Global options [barman] barman_home = /var/lib/barman barman_user = barman log_file = /var/log/barman/barman.log compression = gzip backup_options = exclusive_backup minimum_redundancy = 0 retention_policy = retention_policy_mode = auto wal_retention_policy = main configuration_files_directory = /etc/barman.conf.d |
De volgende stap is het uitvoeren van een PostgreSQL-instantie op pg
. We moeten op de hoogte zijn van de parameters die Barman vereist op de PostgreSQL-server, dus we moeten het volgende instellen:
wal_level
tenminste inarchive
niveauarchive_mode
naaron
archive_command
zodat de WAL's kunnen worden gekopieerd opbackup
- een regel in
pg_hba.conf
voor toegang vanafbackup
Al deze parameters kunnen eenvoudig worden ingesteld via de puppetlabs/postgresql
module. Bovendien hebben we op de Barman-server nodig:
- een PostgreSQL-verbindingsreeks
- een
.pgpass
bestand voor authenticatie - een SSH-opdracht
- om de SSH-sleuteluitwisseling uit te voeren
it2ndq/barman
genereert een privé/openbaar sleutelpaar in ~barman/.ssh
. Het automatisch uitwisselen van de sleutels tussen de servers vereist echter de aanwezigheid van een Puppet Master, wat verder gaat dan de doelstellingen van deze tutorial (het zal deel uitmaken van de volgende aflevering, die zich zal concentreren op het opzetten van een Puppet Master en de barman::autoconfigure
class) – daarom wordt deze laatste stap handmatig uitgevoerd.
We bewerken de site.pp
bestand als volgt:
node backup { class { 'barman': manage_package_repo => true, } barman::server {'test-server': conninfo => 'user=postgres host=192.168.56.221', ssh_command => 'ssh [email protected]', } file { '/var/lib/barman/.pgpass': ensure => 'present', owner => 'barman', group => 'barman', mode => 0600, content => '192.168.56.221:5432:*:postgres:insecure_password', } } node pg { class { 'postgresql::server': listen_addresses => '*', postgres_password => 'insecure_password', pg_hba_conf_defaults => false, } postgresql::server::pg_hba_rule {'Local access': type => 'local', database => 'all', user => 'all', auth_method => 'peer', } postgresql::server::pg_hba_rule {'Barman access': type => 'host', database => 'all', user => 'postgres', address => '192.168.56.222/32', auth_method => 'md5', } postgresql::server::config_entry { 'wal_level' : value => 'archive'; 'archive_mode' : value => 'on'; 'archive_command' : value => 'rsync -a %p [email protected]:/var/lib/barman/test-server/incoming/%f'; } class { 'postgresql::server::contrib': package_ensure => 'present', } } |
Nadat het manifest is gewijzigd, moet de bepaling opnieuw worden uitgevoerd:
$ vagrant provision |
Terwijl de machines draaien, kunnen we doorgaan met de sleuteluitwisselingen. We loggen in op pg
:
$ vagrant ssh pg |
en we maken het sleutelpaar voor de postgres
gebruiker, met behulp van ssh-keygen
, waarbij elk veld leeg blijft wanneer daarom wordt gevraagd (dus altijd op enter drukken):
[email protected]:~$ sudo -iu postgres [email protected]:~$ ssh-keygen [email protected]:~$ cat .ssh/id_rsa.pub |
Het laatste commando levert een lange alfanumerieke string op die moet worden toegevoegd aan de ~barman/.ssh/authorized_keys
bestand op backup
.
$ vagrant ssh backup [email protected]:~$ sudo -iu barman [email protected]:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys |
Op dezelfde manier kopiëren we de openbare sleutel van de barman
gebruiker in de authorized_keys
bestand van de postgres
gebruiker op pg
:
[email protected]:~$ cat .ssh/id_rsa.pub ssh-rsa ... [email protected]:~$ logout [email protected]:~$ logout $ vagrant ssh pg [email protected]:~$ sudo -iu postgres [email protected]:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys |
Op dit punt maken we een eerste verbinding in beide richtingen tussen de twee servers:
[email protected]:$ ssh [email protected] [email protected]:$ ssh [email protected] |
We kunnen barman check
uitvoeren om te controleren of Barman correct werkt:
[email protected]:~$ barman check all Server test-server: ssh: OK PostgreSQL: OK archive_mode: OK archive_command: OK directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) compression settings: OK minimum redundancy requirements: OK (have 0 backups, expected at least 0) |
Op elke regel moet "OK" staan. Om nu een back-up uit te voeren, voert u eenvoudig het volgende uit:
[email protected]:$ barman backup test-server |
Een realistische configuratie
De Barman-configuratie die tot nu toe is gebruikt, is heel eenvoudig, maar u kunt eenvoudig een paar parameters toevoegen aan site.pp
en profiteer van alle functies van Barman, zoals het bewaarbeleid en de nieuwe incrementele back-up die beschikbaar is in Barman 1.4.0.
We sluiten deze tutorial af met een realistische use case, met de volgende vereisten:
- elke nacht om 01:00 uur een back-up
- de mogelijkheid om een Point In Time Recovery uit te voeren naar elk moment van de afgelopen week
- altijd minimaal één back-up beschikbaar hebben
- een fout melden via
barman check
voor het geval de nieuwste back-up ouder is dan een week - incrementele back-up inschakelen om schijfruimte te besparen
We gebruiken het Puppet file
bron om een .pgpass
. te maken bestand met de verbindingsparameters en een cron
bron om de taak te genereren die elke nacht moet worden uitgevoerd. Ten slotte bewerken we de barman::server
om de vereiste Barman-parameters toe te voegen.
Het eindresultaat is:
node backup { class { 'barman': manage_package_repo => true, } barman::server {'test-server': conninfo => 'user=postgres host=192.168.56.221', ssh_command => 'ssh [email protected]', retention_policy => 'RECOVERY WINDOW OF 1 WEEK', minimum_redundancy => 1, last_backup_maximum_age => '1 WEEK', reuse_backup => 'link', } file { '/var/lib/barman/.pgpass': ensure => 'present', owner => 'barman', group => 'barman', mode => 0600, content => '192.168.56.221:5432:*:postgres:insecure_password', } cron { 'barman backup test-server': command => '/usr/bin/barman backup test-server', user => 'barman', hour => 1, minute => 0, } } node pg { class { 'postgresql::server': listen_addresses => '*', postgres_password => 'insecure_password', pg_hba_conf_defaults => false, } postgresql::server::pg_hba_rule {'Local access': type => 'local', database => 'all', user => 'all', auth_method => 'peer', } postgresql::server::pg_hba_rule {'Barman access': type => 'host', database => 'all', user => 'postgres', address => '192.168.56.222/32', auth_method => 'md5', } postgresql::server::config_entry { 'wal_level' : value => 'archive'; 'archive_mode' : value => 'on'; 'archive_command' : value => 'rsync -a %p [email protected]:/var/lib/barman/test-server/incoming/%f'; } } |
Conclusie
Met 51 regels Puppet-manifest zijn we erin geslaagd om een paar PostgreSQL/Barman-servers te configureren met instellingen die vergelijkbaar zijn met die van een productieserver. We hebben de voordelen van een Barman-server voor het afhandelen van back-ups gecombineerd met die van een infrastructuur die wordt beheerd door Puppet, herbruikbaar en versiebeheerbaar.
In de volgende en laatste post in deze serie artikelen zullen we bekijken hoe je een Puppet Master kunt gebruiken om bronnen tussen verschillende machines te exporteren, waardoor de VM's de parameters kunnen uitwisselen die nodig zijn voor een correcte werking via de barman::autoconfigure
class waardoor het hele installatieproces eenvoudiger wordt.