Automatyzacja Barmana z Puppet:it2ndq/barman (część druga)

W pierwszej części tego artykułu skonfigurowaliśmy Vagrant do uruchamiania dwóch maszyn wirtualnych Ubuntu 14.04 Trusty Tahr, odpowiednio nazwanych pg i kopia zapasowa . W drugiej części przyjrzymy się, jak używać Puppet do ustawienia i konfiguracji serwera PostgreSQL na pg i zrób kopię zapasową przez Barmana z kopii zapasowej pudełko.

Lalka:konfiguracja

Po zdefiniowaniu maszyn zgodnie z poprzednim artykułem, musimy określić wymagane moduły Puppet, które librarian-puppet będzie dla nas zarządzać.

Wymagane są dwa moduły:

1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/), aby zainstalować PostgreSQL na pg maszyna wirtualna
2. it2ndq/barman (http://github.com/2ndquadrant-it/puppet-barman), aby zainstalować Barmana na kopii zapasowej

Oba moduły zostaną zainstalowane z Puppet Forge. Dla puppetlabs/postgresql w tej chwili będziemy musieli używać co najwyżej wersji 4.2.0, ponieważ najnowsza wersja (4.3.0) łamie postgres_password parametr, którego będziemy używać później (zobacz to żądanie ściągnięcia). Stwórzmy plik o nazwie Puppetfile zawierające tę treść w katalogu projektu:

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

Możemy teraz zainstalować moduły Puppet i ich zależności, uruchamiając:

$ librarian-puppet install --verbose

Chociaż nie jest to konieczne, lepiej jest użyć opcji --verbose za każdym razem librarian-puppet Jest używane. Bez tego polecenie jest bardzo ciche i warto mieć wcześniej szczegółowe informacje na temat tego, co robi. Na przykład bez użycia --verbose , może się okazać, że zmarnowałeś cenny czas na oczekiwanie na rozwiązanie konfliktu zależności, a błąd pojawi się wiele minut później.

Po pomyślnym zakończeniu polecenia moduły katalog zawierający barman i postgresql moduły i ich zależności (apt , kontakt , stdlib ) zostanie utworzony w naszym katalogu roboczym. Ponadto librarian-puppet utworzy Puppetfile.lock plik, aby zidentyfikować zależności i wersje zainstalowanych modułów, przypinając je, aby zapobiec przyszłym aktualizacjom. W ten sposób kolejna instalacja bibliotekarza-puppet uruchamia zawsze zainstaluje tę samą wersję modułów zamiast możliwych uaktualnień (w przypadku, gdy wymagana jest aktualizacja, librarian-puppet update załatwi sprawę).

Teraz możemy powiedzieć Vagrantowi, że używamy manifestu Puppet do obsługi serwerów. Zmieniamy Vagrantfile w następujący sposób:

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

Dzięki wierszom, które właśnie dodaliśmy, przekazaliśmy firmie Vagrant instrukcje obsługi maszyn wirtualnych za pomocą manifests/site.pp jako główny manifest i moduły zawarte w modułach informator. To jest ostateczna wersja naszego Vagrantfile .

Musimy teraz utworzyć manifesty katalog:

$ mkdir manifests

i napisz w nim pierwszą wersję site.pp . Zaczniemy od bardzo podstawowej konfiguracji:

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

Możemy teraz uruchomić maszyny i zobaczyć to w kopii zapasowej istnieje serwer Barman z domyślną konfiguracją (i bez PostgreSQL na pg już). Zalogujmy się do backup :

$ vagrant ssh backup

i spójrz na /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

Następnym krokiem jest uruchomienie instancji PostgreSQL na pg . Musimy być świadomi parametrów wymaganych przez Barmana na serwerze PostgreSQL, dlatego musimy ustawić:

• wal_level przynajmniej w archiwum poziom
• tryb_archiwum do na
• archive_command aby WAL można było skopiować do kopii zapasowej
• reguła w pg_hba.conf dostęp z kopii zapasowej

Wszystkie te parametry można łatwo ustawić za pomocą puppetlabs/postgresql moduł. Dodatkowo na serwerze Barman potrzebujemy:

• ciąg połączenia PostgreSQL
• .pgpass plik do uwierzytelnienia
• polecenie SSH
• aby przeprowadzić wymianę kluczy SSH

it2ndq/barman generuje parę kluczy prywatny/publiczny w ~barman/.ssh . Jednak automatyczna wymiana kluczy między serwerami wymaga obecności Mistrza Marionetek, co wykracza poza cele tego samouczka (będzie to część następnej części, która skupi się na konfiguracji Mistrza Marionetek i barmana ::automatyczna konfiguracja class) – dlatego ten ostatni krok zostanie wykonany ręcznie.

Edytujemy site.pp plik w następujący sposób:

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

Po zmianie manifestu należy ponownie uruchomić zapis:

$ vagrant provision

Po uruchomieniu maszyn możemy przystąpić do wymiany kluczy. Logujemy się do pg :

$ vagrant ssh pg

i tworzymy parę kluczy dla postgres użytkownik, używając ssh-keygen , pozostawiając każde pole puste po wyświetleniu monitu (więc zawsze naciskaj klawisz Enter):

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

Ostatnie polecenie wyświetla długi ciąg alfanumeryczny, który należy dołączyć do ~barman/.ssh/authorized_keys plik w kopii zapasowej .

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

Podobnie kopiujemy klucz publiczny barmana użytkownika do authorized_keys plik postgres użytkownik na 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

W tym momencie nawiązujemy pierwsze połączenie w obu kierunkach między dwoma serwerami:

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

Możemy przeprowadzić czek barmański aby sprawdzić, czy Barman działa poprawnie:

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

Każda linia powinna brzmieć „OK”. Teraz, aby wykonać kopię zapasową, po prostu uruchom:

[email protected]:$ barman backup test-server

Realistyczna konfiguracja

Dotychczasowa konfiguracja Barmana jest bardzo prosta, ale możesz łatwo dodać kilka parametrów do site.pp i skorzystaj ze wszystkich funkcji Barmana, takich jak zasady przechowywania i nowa przyrostowa kopia zapasowa dostępna w Barman 1.4.0.

Kończymy ten samouczek realistycznym przypadkiem użycia, z następującymi wymaganiami:

• kopia zapasowa każdej nocy o 1:00
• możliwość wykonania odzyskiwania punktu w czasie do dowolnego momentu ostatniego tygodnia
• zawsze posiadanie co najmniej jednej dostępnej kopii zapasowej
• zgłoszenie błędu przez czek barmański w przypadku, gdy najnowsza kopia zapasowa jest starsza niż tydzień
• włączenie przyrostowej kopii zapasowej w celu zaoszczędzenia miejsca na dysku

Używamy Puppet pliku zasób do utworzenia .pgpass plik z parametrami połączenia i cron zasób do generowania zadania do uruchomienia każdej nocy. Na koniec edytujemy barman::server aby dodać wymagane parametry Barmana.

Wynik końcowy to:

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

Wniosek

Dzięki 51 linijkom manifestu Puppet udało nam się skonfigurować parę serwerów PostgreSQL/Barman z ustawieniami podobnymi do tych, których możemy potrzebować na serwerze produkcyjnym. Połączyliśmy zalety posiadania serwera Barman do obsługi kopii zapasowych z infrastrukturą zarządzaną przez Puppet, wielokrotnego użytku i wersjonowaną.

W następnym i ostatnim poście z tej serii artykułów przyjrzymy się, jak używać Puppet Master do eksportowania zasobów między różnymi maszynami, umożliwiając tym samym maszynom wirtualnym wymianę parametrów wymaganych do prawidłowego funkcjonowania za pośrednictwem barman::autoconfigure klasa ułatwiająca cały proces konfiguracji.