PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Автоматизиране на барман с кукла:it2ndq/барман (част втора)

В първата част на тази статия конфигурирахме Vagrant да изпълнява две виртуални машини Ubuntu 14.04 Trusty Tahr, съответно наречени pg и резервно . В тази втора част ще разгледаме как да използваме Puppet за настройване и конфигуриране на PostgreSQL сървър на pg и го архивирайте чрез Barman от backup кутия.

Кукла:конфигурация

След като дефинираме машините съгласно предишната статия, трябва да посочим необходимите Puppet модули, които librarian-puppet ще управлява вместо нас.

Необходими са два модула:

  1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/), за да инсталирате PostgreSQL на pg VM
  2. it2ndq/barman (http://github.com/2ndquadrant-it/puppet-barman), за да инсталирате Barman на backup

И двата модула ще бъдат инсталирани от Puppet Forge. За puppetlabs/postgresql модул, ще трябва да използваме най-много версия 4.2.0 в момента, тъй като най-новата версия (4.3.0) нарушава postgres_password параметър, който ще използваме по-късно (вижте тази заявка за изтегляне). Нека създадем файл, наречен Puppetfile съдържащ това съдържание в директорията на проекта:

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

Вече можем да инсталираме модулите Puppet и техните зависимости, като изпълним:

$ librarian-puppet install --verbose

Въпреки че не е от съществено значение, за предпочитане е да използвате опцията --verbose всеки път библиотекар-марионетка се използва. Без него командата е много тиха и е полезно да имате подробности за това какво прави предварително. Например, без да използвате --verbose , може да разберете, че сте загубили ценно време в чакане на разрешаване на конфликт на зависимости, само за да видите грешка много минути по-късно.

При успешно завършване на командата, a modules директория, съдържаща barman и postgresql модули и техните зависимости (apt , конкат , stdlib ) ще бъде създаден в нашата работна директория. Освен това библиотекар-марионетка ще създаде Puppetfile.lock файл, за да идентифицира зависимостите и версиите на инсталираните модули, като ги закачи, за да предотврати бъдещи актуализации. По този начин последващо инсталиране на библиотекар-марионетка runs винаги ще инсталира една и съща версия на модулите вместо възможни надстройки (в случай, че е необходима надстройка, актуализация на библиотекаря-марионетка ще свърши работа).

Сега можем да кажем на Vagrant, че използваме манифест на Puppet за осигуряване на сървърите. Променяме Vagrantfile както следва:

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

С редовете, които току-що добавихме, дадохме на Vagrant инструкции за предоставяне на виртуалните машини с помощта на manifests/site.pp като основен манифест и модулите, включени в модулите директория. Това е последната версия на нашия Vagrantfile .

Сега трябва да създадем манифестите директория:

$ mkdir manifests

и напишете в него първа версия на site.pp . Ще започнем с много основна настройка:

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

Вече можем да стартираме машините и да видим това в backup има Barman сървър с конфигурация по подразбиране (и няма PostgreSQL на pg още). Нека влезем в backup :

$ vagrant ssh backup

и разгледайте /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

Следващата стъпка е стартиране на екземпляр на PostgreSQL на pg . Трябва да сме наясно с параметрите, изисквани от Barman на PostgreSQL сървъра, така че трябва да зададем:

  • wal_level поне в архив ниво
  • archive_mode до включено
  • архивна_команда така че WAL да могат да бъдат копирани в резервно копие
  • правило в pg_hba.conf за достъп от резервно копие

Всички тези параметри могат лесно да бъдат зададени чрез puppetlabs/postgresql модул. Освен това на сървъра на Barman ни трябва:

  • низ за връзка с PostgreSQL
  • .pgpass файл за удостоверяване
  • SSH команда
  • за извършване на обмен на SSH ключове

it2ndq/barman генерира частна/публична двойка ключове в ~barman/.ssh . Въпреки това, автоматичната размяна на ключовете между сървърите изисква присъствието на Puppet Master, което е извън целите на този урок (той ще бъде част от следващата част, която ще се фокусира върху настройката на Puppet Master и barman ::автоматично конфигуриране клас) – следователно тази последна стъпка ще бъде извършена ръчно.

Редактираме site.pp файл, както следва:

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

След промяна на манифеста, разпоредбата трябва да се изпълни отново:

$ vagrant provision

При работещи машини можем да продължим с размяната на ключове. Влизаме в pg :

$ vagrant ssh pg

и създаваме двойката ключове за postgres потребител, използвайки ssh-keygen , оставяйки всяко поле празно, когато бъдете подканени (така че винаги натискайте enter):

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

Последната команда извежда дълъг буквено-цифров низ, който трябва да бъде добавен към ~barman/.ssh/authorized_keys файл на резервно копие .

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

По подобен начин копираме публичния ключ на barman потребител в authorized_keys файл на postgres потребител на 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

В този момент правим първа връзка в двете посоки между двата сървъра:

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

Можем да изпълним барман проверка за да проверите дали Barman работи правилно:

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

Всеки ред трябва да гласи „OK“. Сега, за да направите резервно копие, просто изпълнете:

[email protected]:$ barman backup test-server

Реалистична конфигурация

Използваната досега конфигурация на Barman е много проста, но можете лесно да добавите няколко параметъра към site.pp и се възползвайте от всички функции на Barman, като например политиките за задържане и новото допълнително архивиране, достъпно в Barman 1.4.0.

Завършваме този урок с реалистичен случай на употреба, със следните изисквания:

  • резервно копие всяка вечер в 1:00 сутринта
  • възможността за извършване на Възстановяване във времето до всеки момент от последната седмица
  • винаги да разполагате с поне едно резервно копие
  • докладване за грешка чрез барман проверка в случай, че най-новото архивно копие е по-старо от седмица
  • активиране на инкрементално архивиране за спестяване на дисково пространство

Използваме Puppet файл ресурс за създаване на .pgpass файл с параметрите на връзката и cron ресурс за генериране на заданието, което да се изпълнява всяка вечер. Накрая редактираме barman::server за да добавите необходимите параметри на Барман.

Крайният резултат е:

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

Заключение

С 51 реда манифест на Puppet успяхме да конфигурираме чифт PostgreSQL/Barman сървъри с настройки, подобни на тези, които може да искаме на производствен сървър. Комбинирахме предимствата на наличието на Barman сървър за обработка на архиви с тези на инфраструктура, управлявана от Puppet, за многократна употреба и версия.

В следващата и последна публикация от тази поредица от статии ще разгледаме как да използваме Puppet Master за експортиране на ресурси между различни машини, като по този начин позволяваме на VM да обменят параметрите, необходими за правилното функциониране чрез barman::autoconfigure клас, което улеснява целия процес на настройка.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Изберете редове, които не присъстват в друга таблица

  2. Експортиране на AWS Postgres RDS таблица към AWS S3

  3. Как да изберете с помощта на клауза WITH RECURSIVE

  4. Защо само суперпотребител може да CREATE EXTENSION hstore, но не и на Heroku?

  5. PostgreSQL - как да изобразя дата в различна часова зона?