sql >> Database >  >> RDS >> PostgreSQL

Barman automatiseren met Puppet:it2ndq/barman (deel twee)

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:

  1. puppetlabs/postgresql (https://github.com/puppetlabs/puppetlabs-postgresql/) om PostgreSQL te installeren op de pg VM
  2. it2ndq/barman (https://github.com/2ndquadrant-it/puppet-barman) om Barman te installeren op backup

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 "https://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 = '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

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 in archive niveau
  • archive_mode naar on
  • archive_command zodat de WAL's kunnen worden gekopieerd op backup
  • een regel in pg_hba.conf voor toegang vanaf backup

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 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',
  }
}

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):

example@sqldat.com:~$ sudo -iu postgres
example@sqldat.com:~$ ssh-keygen
example@sqldat.com:~$ 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
example@sqldat.com:~$ sudo -iu barman
example@sqldat.com:~$ 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 :

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

Op dit punt maken we een eerste verbinding in beide richtingen tussen de twee servers:

example@sqldat.com:$ ssh example@sqldat.com192.168.56.222
example@sqldat.com:$ ssh example@sqldat.com192.168.56.221

We kunnen barman check uitvoeren om te controleren of Barman correct werkt:

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)

Op elke regel moet "OK" staan. Om nu een back-up uit te voeren, voert u eenvoudig het volgende uit:

example@sqldat.com:$ 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 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';
  }
}

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.


  1. Hoe gegevens genereren in MySQL?

  2. Oracle JDeveloper 12c gebruiken met Oracle Database 12c op Oracle Cloud Platform, deel 2

  3. LAGER LIKE vs iLIKE

  4. Hoe DIV werkt in MariaDB