I den første del af denne artikel konfigurerede vi Vagrant til at udføre to Ubuntu 14.04 Trusty Tahr virtuelle maskiner, henholdsvis kaldet pg og backup . I denne anden del vil vi se på, hvordan du bruger Puppet til at opsætte og konfigurere en PostgreSQL-server på pg og sikkerhedskopiere det via Barman fra backup boks.
Puppet:konfiguration 
Efter at have defineret maskinerne som i den foregående artikel, skal vi specificere de nødvendige Puppet-moduler, som librarian-puppet vil klare for os.
Der kræves to moduler:
puppetlabs/postgresql(https://github.com/puppetlabs/puppetlabs-postgresql/) for at installere PostgreSQL påsidenVMit2ndq/barman(https://github.com/2ndquadrant-it/puppet-barman) for at installere Barman påbackup
Begge moduler vil blive installeret fra Puppet Forge. Til puppetlabs/postgresql modul, skal vi højst bruge version 4.2.0 i øjeblikket, da den seneste version (4.3.0) bryder postgres_password parameter, vi skal bruge senere (se denne pull-anmodning). Lad os oprette en fil kaldet Puppetfile indeholdende dette indhold i projektbiblioteket:
forge "https://forgeapi.puppetlabs.com" mod "puppetlabs/postgresql", "<4.3.0" mod "it2ndq/barman" |
Vi kan nu installere Puppet-modulerne og deres afhængigheder ved at køre:
$ librarian-puppet install --verbose |
Selvom det ikke er vigtigt, er det at foretrække at bruge muligheden --verbose hver gang librarian-puppet anvendes. Uden den er kommandoen meget stille, og det er nyttigt at have detaljer om, hvad den laver på forhånd. For eksempel uden at bruge --verbose , kan du finde ud af, at du har spildt kostbar tid på at vente på, at en afhængighedskonflikt bliver løst, for så at se en fejl mange minutter senere.
Efter vellykket gennemførelse af kommandoen, en moduler mappe, der indeholder barman og postgresql moduler og deres afhængigheder (apt , sammenkæd , stdlib ) oprettes i vores arbejdsmappe. Derudover bibliotekar-puppet vil oprette Puppetfile.lock fil for at identificere afhængigheder og versioner af de installerede moduler og fastgøre dem for at forhindre fremtidige opdateringer. På denne måde, efterfølgende librarian-puppet installation runs vil altid installere den samme version af modulerne i stedet for mulige opgraderinger (i tilfælde af at en opgradering er påkrævet, librarian-puppet update vil gøre tricket).
Nu kan vi fortælle Vagrant, at vi bruger et Puppet-manifest til at klargøre serverne. Vi ændrer Vagrantfilen som følger:
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 = 'https://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 |
Med de linjer, vi lige har tilføjet, har vi givet Vagrant instruktionerne til at klargøre VM'erne ved hjælp af manifests/site.pp som hovedmanifest og modulerne inkluderet i modulerne vejviser. Dette er den endelige version af vores Vagrantfile .
Vi skal nu oprette manifesterne mappe:
$ mkdir manifests |
og skriv en første version af site.pp i den . Vi starter med en meget grundlæggende opsætning:
node backup {
class { 'barman':
manage_package_repo => true,
}
}
node pg {} |
Vi kan nu starte maskinerne og se det på backup der er en Barman-server med en standardkonfiguration (og ingen PostgreSQL på pg endnu). Lad os logge på backup :
$ vagrant ssh backup |
og tag et kig på /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 |
Det næste trin er at køre en PostgreSQL-instans på pg . Vi skal være opmærksomme på de parametre, der kræves af Barman på PostgreSQL-serveren, så vi skal indstille:
wal_niveaui det mindste vedarkivniveauarkivtilstandtilpåarchive_commandså WAL'erne kan kopieres påbackup- en regel i
pg_hba.conffor adgang frabackup
Alle disse parametre kan nemt indstilles gennem puppetlabs/postgresql modul. Derudover har vi på Barman-serveren brug for:
- en PostgreSQL-forbindelsesstreng
- et
.pgpassfil til godkendelse - en SSH-kommando
- for at udføre SSH-nøgleudveksling
it2ndq/barman genererer et privat/offentligt nøglepar i ~barman/.ssh . Automatisk udveksling af nøgler mellem serverne kræver dog tilstedeværelsen af en Puppet Master, som ligger uden for målene i denne tutorial (det vil være en del af den næste del, som vil fokusere på opsætningen af en Puppet Master og barman) ::autoconfigure klasse) – derfor vil dette sidste trin blive udført manuelt.
Vi redigerer site.pp fil som følger:
node backup {
class { 'barman':
manage_package_repo => true,
}
barman::server {'test-server':
conninfo => 'user=postgres host=192.168.56.221',
ssh_command => 'ssh example@sqldat.com',
}
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 example@sqldat.com:/var/lib/barman/test-server/incoming/%f';
}
class { 'postgresql::server::contrib':
package_ensure => 'present',
}
} |
Efter at have ændret manifestet, skal bestemmelsen køres igen:
$ vagrant provision |
Med maskinerne kørende kan vi fortsætte med nøgleudvekslingerne. Vi logger ind på pg :
$ vagrant ssh pg |
og vi opretter nøgleparret til postgres bruger ved hjælp af ssh-keygen , efterlader hvert felt tomt, når du bliver bedt om det (så du skal altid trykke på Enter):
example@sqldat.com:~$ sudo -iu postgres example@sqldat.com:~$ ssh-keygen example@sqldat.com:~$ cat .ssh/id_rsa.pub |
Den sidste kommando udsender en lang alfanumerisk streng, der skal føjes til ~barman/.ssh/authorized_keys fil på backup .
$ vagrant ssh backup example@sqldat.com:~$ sudo -iu barman example@sqldat.com:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys |
På samme måde kopierer vi den offentlige nøgle til barman bruger til authorized_keys fil af postgres bruger på side :
example@sqldat.com:~$ cat .ssh/id_rsa.pub ssh-rsa ... example@sqldat.com:~$ logout example@sqldat.com:~$ logout $ vagrant ssh pg example@sqldat.com:~$ sudo -iu postgres example@sqldat.com:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys |
På dette tidspunkt laver vi en første forbindelse i begge retninger mellem de to servere:
example@sqldat.com:$ ssh example@sqldat.com192.168.56.222 example@sqldat.com:$ ssh example@sqldat.com192.168.56.221 |
Vi kan køre barman check for at bekræfte, at Barman fungerer korrekt:
example@sqldat.com:~$ 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) |
Hver linje skal læse "OK". Nu, for at udføre en sikkerhedskopi, skal du blot køre:
example@sqldat.com:$ barman backup test-server |
En realistisk konfiguration
Barman-konfigurationen, der er brugt indtil videre, er meget enkel, men du kan nemt tilføje et par parametre til site.pp og drag fordel af alle funktionerne i Barman, såsom opbevaringspolitikkerne og den nye inkrementelle backup, der er tilgængelig i Barman 1.4.0.
Vi afslutter denne øvelse med en realistisk use case, med følgende krav:
- en backup hver nat kl. 01:00
- muligheden for at udføre en Point In Time-gendannelse til et hvilket som helst tidspunkt i den sidste uge
- altid at have mindst én tilgængelig sikkerhedskopi
- rapportering af en fejl via
barman checki tilfælde af at den nyeste backup er ældre end en uge - aktiverer trinvis sikkerhedskopiering for at spare diskplads
Vi bruger Puppet filen ressource til at oprette en .pgpass fil med forbindelsesparametrene og en cron ressource til at generere jobbet til at køre hver nat. Til sidst redigerer vi barman::serveren for at tilføje de nødvendige Barman-parametre.
Slutresultatet er:
node backup {
class { 'barman':
manage_package_repo => true,
}
barman::server {'test-server':
conninfo => 'user=postgres host=192.168.56.221',
ssh_command => 'ssh example@sqldat.com',
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 example@sqldat.com:/var/lib/barman/test-server/incoming/%f';
}
} |
Konklusion
Med 51 linjer af Puppet-manifest lykkedes det os at konfigurere et par PostgreSQL/Barman-servere med indstillinger, der ligner dem, vi måske ønsker på en produktionsserver. Vi har kombineret fordelene ved at have en Barman-server til at håndtere sikkerhedskopier med fordelene ved at have en infrastruktur administreret af Puppet, genbrugelig og versionsbar.
I det næste og sidste indlæg i denne serie af artikler vil vi se på, hvordan man bruger en Puppet Master til at eksportere ressourcer mellem forskellige maskiner, hvilket giver VM'erne mulighed for at udveksle de parametre, der kræves for korrekt funktion via barman::autoconfigure klasse, hvilket gør hele opsætningsprocessen nemmere.