sql >> Database teknologi >  >> RDS >> PostgreSQL

Automatisering af Barman med Puppet:it2ndq/barman (del to)

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:

  1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/) for at installere PostgreSQL på siden VM
  2. it2ndq/barman (http://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 "http://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 = '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 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_niveau i det mindste ved arkiv niveau
  • arkivtilstand til på
  • archive_command så WAL'erne kan kopieres på backup
  • en regel i pg_hba.conf for adgang fra backup

Alle disse parametre kan nemt indstilles gennem puppetlabs/postgresql modul. Derudover har vi på Barman-serveren brug for:

  • en PostgreSQL-forbindelsesstreng
  • et .pgpass fil 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 [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 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):

[email protected]:~$ sudo -iu postgres
[email protected]:~$ ssh-keygen
[email protected]:~$ 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
[email protected]:~$ sudo -iu barman
[email protected]:~$ 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 :

[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

På dette tidspunkt laver vi en første forbindelse i begge retninger mellem de to servere:

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

Vi kan køre barman check for at bekræfte, at Barman fungerer 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)

Hver linje skal læse "OK". Nu, for at udføre en sikkerhedskopi, skal du blot køre:

[email protected]:$ 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 check i 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 [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';
  }
}

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.


  1. Minimering af virkningen af ​​at udvide en IDENTITY-søjle – del 1

  2. Oracle Forms i R12/R12.2

  3. Sådan udpakkes en understreng i MySQL

  4. datetime til totalminute i sql