sql >> Databasteknik >  >> RDS >> PostgreSQL

Automatisera Barman med Puppet:it2ndq/barman (del två)

I den första delen av den här artikeln konfigurerade vi Vagrant för att köra två virtuella Ubuntu 14.04 Trusty Tahr-maskiner, respektive kallade pg och backup . I den här andra delen kommer vi att titta på hur man använder Puppet för att ställa in och konfigurera en PostgreSQL-server på pg och säkerhetskopiera den via Barman från backup box.

Puppet:konfiguration

Efter att ha definierat maskinerna enligt föregående artikel måste vi specificera de nödvändiga Puppet-modulerna som librarian-puppet kommer att hantera åt oss.

Två moduler krävs:

  1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/) för att installera PostgreSQL på sidan VM
  2. it2ndq/barman (http://github.com/2ndquadrant-it/puppet-barman) för att installera Barman på backup

Båda modulerna kommer att installeras från Puppet Forge. För puppetlabs/postgresql modulen måste vi som mest använda version 4.2.0 för tillfället, eftersom den senaste versionen (4.3.0) bryter postgres_password parameter som vi kommer att använda senare (se denna pull-begäran). Låt oss skapa en fil som heter Puppetfile som innehåller detta innehåll i projektkatalogen:

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

Vi kan nu installera Puppet-modulerna och deras beroenden genom att köra:

$ librarian-puppet install --verbose

Även om det inte är nödvändigt, är det att föredra att använda alternativet --verbose varje gång librarian-puppet är använd. Utan det är kommandot väldigt tyst och det är användbart att ha detaljer om vad det gör i förväg. Till exempel utan att använda --verbose , kan du upptäcka att du har slösat bort dyrbar tid på att vänta på att en beroendekonflikt ska lösas, bara för att se ett fel många minuter senare.

Efter framgångsrikt slutförande av kommandot, en moduler katalog som innehåller barman och postgresql moduler och deras beroenden (apt , konkat , stdlib ) kommer att skapas i vår arbetskatalog. Dessutom librarian-puppet kommer att skapa Puppetfile.lock fil för att identifiera beroenden och versioner av de installerade modulerna, fästa dem för att förhindra framtida uppdateringar. På detta sätt, efterföljande librarian-puppet installation runs kommer alltid att installera samma version av modulerna istället för möjliga uppgraderingar (om en uppgradering krävs, librarian-puppet update kommer att göra susen).

Nu kan vi berätta för Vagrant att vi använder ett Puppet-manifest för att tillhandahålla servrarna. Vi ändrar Vagrantfilen enligt följande:

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

Med raderna vi just har lagt till har vi gett Vagrant instruktionerna för att tillhandahålla virtuella datorer med manifests/site.pp som huvudmanifest och modulerna som ingår i modulerna katalog. Detta är den slutliga versionen av vår Vagrantfile .

Vi måste nu skapa manifesterna katalog:

$ mkdir manifests

och skriv i den en första version av site.pp . Vi börjar med en mycket grundläggande inställning:

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

Vi kan nu starta maskinerna och se det på backup det finns en Barman-server med en standardkonfiguration (och ingen PostgreSQL på pg än). Låt oss logga in på backup :

$ vagrant ssh backup

och ta en titt 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

Nästa steg är att köra en PostgreSQL-instans på pg . Vi måste vara medvetna om parametrarna som krävs av Barman på PostgreSQL-servern, så vi måste ställa in:

  • valnivå åtminstone vid arkiv nivå
  • arkivläge till på
  • archive_command så att WAL:erna kan kopieras på backup
  • en regel i pg_hba.conf för åtkomst från backup

Alla dessa parametrar kan enkelt ställas in via puppetlabs/postgresql modul. På Barman-servern behöver vi dessutom:

  • en PostgreSQL-anslutningssträng
  • ett .pgpass fil för autentisering
  • ett SSH-kommando
  • för att utföra SSH-nyckelutbytet

it2ndq/barman genererar ett privat/offentligt nyckelpar i ~barman/.ssh . Att automatiskt byta nycklar mellan servrarna kräver dock närvaron av en Puppet Master vilket är bortom målen för denna handledning (det kommer att ingå i nästa omgång, som kommer att fokusera på installationen av en Puppet Master och barman) ::autokonfigurera class) – därför kommer detta sista steg att utföras manuellt.

Vi redigerar site.pp fil enligt följande:

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

Efter att ha ändrat manifestet måste bestämmelsen köras om:

$ vagrant provision

Med maskinerna igång kan vi fortsätta med nyckelbyten. Vi loggar in på pg :

$ vagrant ssh pg

och vi skapar nyckelparet för postgres användare med ssh-keygen , lämnar varje fält tomt när du uppmanas (så tryck alltid på enter):

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

Det sista kommandot matar ut en lång alfanumerisk sträng som måste läggas till ~barman/.ssh/authorized_keys fil på backup .

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

På samma sätt kopierar vi den publika nyckeln till barman användare till authorized_keys filen för postgres användare på sid :

[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

Vid det här laget gör vi en första anslutning i båda riktningarna mellan de två servrarna:

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

Vi kan köra barman check för att verifiera att Barman fungerar korrekt:

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

Varje rad ska stå "OK". Nu, för att göra en säkerhetskopiering, kör helt enkelt:

[email protected]:$ barman backup test-server

En realistisk konfiguration

Barman-konfigurationen som har använts hittills är mycket enkel, men du kan enkelt lägga till några parametrar till site.pp och dra nytta av alla funktioner i Barman, såsom lagringspolicyerna och den nya inkrementella säkerhetskopieringen som finns tillgänglig i Barman 1.4.0.

Vi avslutar den här handledningen med ett realistiskt användningsfall, med följande krav:

  • en säkerhetskopia varje kväll klockan 01:00
  • möjligheten att utföra en Point In Time Recovery till vilken tidpunkt som helst under den senaste veckan
  • alltid ha minst en säkerhetskopia tillgänglig
  • rapporterar ett fel via barman check om den senaste säkerhetskopian är äldre än en vecka
  • aktiverar inkrementell säkerhetskopiering för att spara diskutrymme

Vi använder filen för Puppet resurs för att skapa en .pgpass fil med anslutningsparametrarna och en cron resurs för att skapa jobbet att köra varje natt. Slutligen redigerar vi barman::servern för att lägga till de nödvändiga Barman-parametrarna.

Slutresultatet är:

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

Slutsats

Med 51 rader av Puppet-manifest lyckades vi konfigurera ett par PostgreSQL/Barman-servrar med inställningar liknande de vi kanske vill ha på en produktionsserver. Vi har kombinerat fördelarna med att ha en Barman-server för att hantera säkerhetskopior med fördelarna med att ha en infrastruktur som hanteras av Puppet, återanvändbar och versionsbar.

I nästa och sista inlägg i den här artikelserien kommer vi att titta på hur man använder en Puppet Master för att exportera resurs mellan olika maskiner, vilket gör det möjligt för virtuella datorer att utbyta de parametrar som krävs för korrekt funktion via barman::autoconfigure klass vilket gör hela installationsprocessen enklare.


  1. Användning av Sqlite Stored Procedur i Android

  2. Hur LEAST() fungerar i MariaDB

  3. Hur man använder FILEGROUPPROPERTY() i SQL Server

  4. Kontrollera om filen finns eller inte i sql-servern?