PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Barkeeper mit Puppet automatisieren:it2ndq/barman (Teil 2)

Im ersten Teil dieses Artikels haben wir Vagrant so konfiguriert, dass er zwei virtuelle Ubuntu 14.04 Trusty Tahr-Maschinen mit dem Namen pg ausführt und Sicherung . In diesem zweiten Teil sehen wir uns an, wie man mit Puppet einen PostgreSQL-Server auf pg einrichtet und konfiguriert und sichern Sie es über Barman aus dem backup Feld.

Marionette:Konfiguration

Nachdem wir die Maschinen gemäß dem vorherigen Artikel definiert haben, müssen wir die erforderlichen Puppet-Module angeben, die librarian-puppet kümmert sich um uns.

Zwei Module sind erforderlich:

  1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/), um PostgreSQL auf dem pg zu installieren VM
  2. it2ndq/barman (http://github.com/2ndquadrant-it/puppet-barman), um Barman auf backup zu installieren

Beide Module werden von Puppet Forge installiert. Für puppetlabs/postgresql Modul müssen wir derzeit höchstens Version 4.2.0 verwenden, da die neueste Version (4.3.0) das postgres_password knackt Parameter, den wir später verwenden werden (siehe diese Pull-Anfrage). Lassen Sie uns eine Datei namens Puppetfile erstellen mit diesem Inhalt im Projektverzeichnis:

forge "http://forgeapi.puppetlabs.com"
mod "puppetlabs/postgresql", "<4.3.0"
mod "it2ndq/barman"

Wir können jetzt die Puppet-Module und ihre Abhängigkeiten installieren, indem wir Folgendes ausführen:

$ librarian-puppet install --verbose

Obwohl nicht unbedingt erforderlich, ist es vorzuziehen, die Option --verbose zu verwenden jedes Mal librarian-puppet wird genutzt. Ohne sie ist der Befehl sehr leise und es ist nützlich, im Voraus Details darüber zu haben, was er tut. Zum Beispiel ohne Verwendung von --verbose , stellen Sie möglicherweise fest, dass Sie wertvolle Zeit damit verschwendet haben, auf die Lösung eines Abhängigkeitskonflikts zu warten, nur um viele Minuten später einen Fehler zu sehen.

Nach erfolgreichem Abschluss des Befehls wird ein modules Verzeichnis, das den Barmann enthält und postgresql Module und ihre Abhängigkeiten (apt , concat , stdlib ) wird in unserem Arbeitsverzeichnis erstellt. Außerdem librarian-puppet erstellt die Puppetfile.lock Datei, um Abhängigkeiten und Versionen der installierten Module zu identifizieren und sie zu fixieren, um zukünftige Updates zu verhindern. Auf diese Weise nachfolgende librarian-puppet install Läufe installieren immer die gleiche Version der Module anstelle möglicher Upgrades (falls ein Upgrade erforderlich ist, librarian-puppet update wird es tun).

Jetzt können wir Vagrant mitteilen, dass wir ein Puppet-Manifest verwenden, um die Server bereitzustellen. Wir ändern die Vagrantfile wie folgt:

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

Mit den Zeilen, die wir gerade hinzugefügt haben, haben wir Vagrant die Anweisungen gegeben, die VMs mithilfe von manifests/site.pp bereitzustellen als Hauptmanifest und die in modules enthaltenen Module Verzeichnis. Dies ist die endgültige Version unseres Vagrantfile .

Wir müssen jetzt die Manifeste erstellen Verzeichnis:

$ mkdir manifests

und schreibe darin eine erste Version von site.pp . Wir beginnen mit einer sehr einfachen Einrichtung:

node backup {
  class { 'barman':
    manage_package_repo => true,
  }
}
node pg {}

Wir können jetzt die Maschinen starten und sehen das auf backup es gibt einen Barman-Server mit einer Standardkonfiguration (und kein PostgreSQL auf pg noch). Melden wir uns bei backup an :

$ vagrant ssh backup

und werfen Sie einen Blick auf /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

Der nächste Schritt ist das Ausführen einer PostgreSQL-Instanz auf pg . Wir müssen uns der Parameter bewusst sein, die Barman auf dem PostgreSQL-Server benötigt, also müssen wir Folgendes festlegen:

  • wal_level zumindest bei archiv Stufe
  • Archivmodus auf ein
  • archive_command damit die WALs auf backup kopiert werden können
  • eine Regel in pg_hba.conf für den Zugriff von backup

Alle diese Parameter können einfach über puppetlabs/postgresql eingestellt werden Modul. Zusätzlich benötigen wir auf dem Barman-Server:

  • eine PostgreSQL-Verbindungszeichenfolge
  • eine .pgpass Datei zur Authentifizierung
  • ein SSH-Befehl
  • um den SSH-Schlüsselaustausch durchzuführen

it2ndq/barman generiert ein privates/öffentliches Schlüsselpaar in ~barman/.ssh . Der automatische Austausch der Schlüssel zwischen den Servern erfordert jedoch die Anwesenheit eines Puppet Masters, was über die Ziele dieses Tutorials hinausgeht (es wird Teil der nächsten Folge sein, die sich auf die Einrichtung eines Puppet Masters und des Barkeepers konzentrieren wird ::automatisch konfigurieren Klasse) – daher wird dieser letzte Schritt manuell durchgeführt.

Wir bearbeiten die site.pp Datei wie folgt:

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

Nach Änderung des Manifests muss die Bereitstellung erneut ausgeführt werden:

$ vagrant provision

Wenn die Maschinen laufen, können wir mit dem Schlüsselaustausch fortfahren. Wir melden uns bei pg an :

$ vagrant ssh pg

und wir erstellen das Schlüsselpaar für postgres Benutzer mit ssh-keygen , jedes Feld leer lassen, wenn Sie dazu aufgefordert werden (also immer die Eingabetaste drücken):

[email protected]:~$ sudo -iu postgres
[email protected]:~$ ssh-keygen
[email protected]:~$ cat .ssh/id_rsa.pub

Der letzte Befehl gibt eine lange alphanumerische Zeichenfolge aus, die an ~barman/.ssh/authorized_keys angehängt werden muss Datei auf backup .

$ vagrant ssh backup
[email protected]:~$ sudo -iu barman
[email protected]:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys

Ebenso kopieren wir den öffentlichen Schlüssel des Barkeeper Benutzer in die authorized_keys Datei des postgres Benutzer auf 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

An dieser Stelle stellen wir eine erste Verbindung in beide Richtungen zwischen den beiden Servern her:

[email protected]:$ ssh [email protected]
[email protected]:$ ssh [email protected]

Wir können Barkeeper-Check durchführen um zu überprüfen, ob Barman richtig funktioniert:

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

In jeder Zeile sollte „OK“ stehen. Um nun eine Sicherung durchzuführen, führen Sie einfach Folgendes aus:

[email protected]:$ barman backup test-server

Eine realistische Konfiguration

Die bisher verwendete Barman-Konfiguration ist sehr einfach, aber Sie können leicht ein paar Parameter zu site.pp hinzufügen und nutzen Sie alle Funktionen von Barman, wie z. B. die Aufbewahrungsrichtlinien und das neue inkrementelle Backup, das in Barman 1.4.0 verfügbar ist.

Wir beenden dieses Tutorial mit einem realistischen Anwendungsfall mit den folgenden Anforderungen:

  • eine Sicherung jede Nacht um 1:00 Uhr
  • die Möglichkeit, eine Point-in-Time-Wiederherstellung zu einem beliebigen Zeitpunkt der letzten Woche durchzuführen
  • immer mindestens ein Backup verfügbar haben
  • Meldung eines Fehlers über Barkeeper-Check falls das neueste Backup älter als eine Woche ist
  • Zuwachssicherung aktivieren, um Speicherplatz zu sparen

Wir verwenden die Puppet Datei Ressource zum Erstellen einer .pgpass Datei mit den Verbindungsparametern und einem cron Ressource zum Generieren des Jobs, der jede Nacht ausgeführt wird. Schließlich bearbeiten wir den barman::server um die erforderlichen Barman-Parameter hinzuzufügen.

Das Endergebnis ist:

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

Schlussfolgerung

Mit 51 Zeilen Puppet-Manifest haben wir es geschafft, ein Paar PostgreSQL/Barman-Server mit Einstellungen zu konfigurieren, die denen ähneln, die wir uns auf einem Produktionsserver wünschen würden. Wir haben die Vorteile eines Barman-Servers zur Handhabung von Backups mit denen einer von Puppet verwalteten, wiederverwendbaren und versionierbaren Infrastruktur kombiniert.

Im nächsten und letzten Beitrag dieser Artikelserie werden wir uns ansehen, wie man einen Puppet Master verwendet, um Ressourcen zwischen verschiedenen Maschinen zu exportieren, sodass die VMs die für das korrekte Funktionieren erforderlichen Parameter über den barman::autoconfigure Klasse, die den gesamten Einrichtungsprozess vereinfacht.