Tự động hóa Barman với Puppet:it2ndq / barman (phần hai)

Trong phần đầu tiên của bài viết này, chúng tôi đã định cấu hình Vagrant để thực thi hai máy ảo Ubuntu 14.04 Trusty Tahr, tương ứng được gọi là pg và backup . Trong phần thứ hai này, chúng ta sẽ xem xét cách sử dụng Puppet để thiết lập và định cấu hình máy chủ PostgreSQL trên pg và sao lưu nó qua Barman từ backup hộp.

Con rối:cấu hình

Sau khi xác định các máy theo bài viết trước, chúng ta cần chỉ định các mô-đun Con rối bắt buộc librarian-puppet sẽ quản lý cho chúng tôi.

Hai mô-đun được yêu cầu:

1. puppetlabs/postgresql (http://github.com/puppetlabs/puppetlabs-postgresql/) để cài đặt PostgreSQL trên pg VM
2. it2ndq/barman (http://github.com/2ndquadrant-it/puppet-barman) để cài đặt Barman trên backup

Cả hai mô-đun sẽ được cài đặt từ Puppet Forge. Đối với puppetlabs/postgresql , chúng tôi sẽ phải sử dụng tối đa phiên bản 4.2.0 vào lúc này, vì phiên bản mới nhất (4.3.0) đang phá vỡ postgres_password tham số chúng tôi sẽ sử dụng sau này (xem yêu cầu kéo này). Hãy tạo một tệp có tên là Puppetfile chứa nội dung này trong thư mục dự án:

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

Bây giờ chúng tôi có thể cài đặt các mô-đun Con rối và các phần phụ thuộc của chúng bằng cách chạy:

$ librarian-puppet install --verbose

Mặc dù không cần thiết nhưng bạn nên sử dụng tùy chọn --verbose mọi lúc librarian-puppet Được sử dụng. Nếu không có nó, lệnh sẽ rất yên tĩnh và sẽ hữu ích nếu bạn biết trước thông tin chi tiết về những gì nó đang làm. Ví dụ:không sử dụng --verbose , bạn có thể phát hiện ra rằng bạn đã lãng phí thời gian quý báu để chờ giải quyết xung đột phụ thuộc, chỉ để thấy lỗi nhiều phút sau đó.

Sau khi hoàn thành thành công lệnh, một modules thư mục chứa barman và postgresql mô-đun và các phụ thuộc của chúng (apt , concat , stdlib ) sẽ được tạo trong thư mục làm việc của chúng tôi. Ngoài ra, librarian-puppet sẽ tạo Puppetfile.lock để xác định các phụ thuộc và phiên bản của các mô-đun đã cài đặt, ghim chúng để ngăn các bản cập nhật trong tương lai. Bằng cách này, librarian-puppet install tiếp theo các lần chạy sẽ luôn cài đặt cùng một phiên bản của các mô-đun thay vì có thể nâng cấp (trong trường hợp cần nâng cấp, hãy librarian-puppet update sẽ thực hiện thủ thuật).

Bây giờ chúng ta có thể nói với Vagrant rằng chúng ta đang sử dụng một tệp kê khai Con rối để cung cấp cho các máy chủ. Chúng tôi thay đổi Vagrantfile như sau:

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

Với những dòng chúng tôi vừa thêm, chúng tôi đã cung cấp cho Vagrant hướng dẫn để cung cấp máy ảo bằng cách sử dụng manifests/site.pp dưới dạng tệp kê khai chính và các mô-đun được bao gồm trong modules danh mục. Đây là phiên bản cuối cùng của Vagrantfile của chúng tôi .

Bây giờ chúng ta phải tạo manifests thư mục:

$ mkdir manifests

và viết vào đó phiên bản đầu tiên của site.pp . Chúng tôi sẽ bắt đầu với một thiết lập rất cơ bản:

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

Bây giờ chúng tôi có thể khởi động máy và thấy điều đó trên backup có một máy chủ Barman với cấu hình mặc định (và không có PostgreSQL trên pg chưa). Hãy đăng nhập vào backup :

$ vagrant ssh backup

và xem qua /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

Bước tiếp theo là chạy một phiên bản PostgreSQL trên pg . Chúng ta phải biết các tham số được yêu cầu bởi Barman trên máy chủ PostgreSQL, vì vậy chúng ta cần đặt:

• wal_level ít nhất tại archive cấp độ
• archive_mode thành on
• archive_command để các WAL có thể được sao chép trên backup
• một quy tắc trong pg_hba.conf để truy cập từ backup

Tất cả các tham số này có thể được thiết lập dễ dàng thông qua puppetlabs/postgresql mô-đun. Ngoài ra, trên máy chủ Barman, chúng ta cần:

• một chuỗi kết nối PostgreSQL
• một .pgpass tệp để xác thực
• một lệnh SSH
• để thực hiện trao đổi khóa SSH

it2ndq/barman tạo cặp khóa riêng tư / công khai trong ~barman/.ssh . Tuy nhiên, việc tự động trao đổi khóa giữa các máy chủ yêu cầu sự hiện diện của Bậc thầy múa rối nằm ngoài mục tiêu của hướng dẫn này (nó sẽ là một phần của phần tiếp theo, sẽ tập trung vào việc thiết lập Bậc thầy múa rối và người phục vụ barman::autoconfigure class) - do đó bước cuối cùng này sẽ được thực hiện theo cách thủ công.

Chúng tôi chỉnh sửa site.pp tệp như sau:

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

Sau khi thay đổi tệp kê khai, điều khoản phải được chạy lại:

$ vagrant provision

Với máy đang hoạt động, chúng tôi có thể tiến hành trao đổi chính. Chúng tôi đăng nhập vào pg :

$ vagrant ssh pg

và chúng tôi tạo cặp khóa cho postgres người dùng, sử dụng ssh-keygen , để trống mọi trường khi được nhắc (vì vậy hãy luôn nhấn enter):

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

Lệnh cuối cùng xuất ra một chuỗi dài gồm chữ và số phải được nối vào ~barman/.ssh/authorized_keys tệp trên backup .

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

Tương tự, chúng tôi sao chép khóa công khai của barman người dùng vào authorized_keys tệp của postgres người dùng trên 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

Tại thời điểm này, chúng tôi thực hiện kết nối đầu tiên theo cả hai hướng giữa hai máy chủ:

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

Chúng ta có thể chạy barman check để xác minh rằng Barman đang hoạt động chính xác:

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

Mỗi dòng phải đọc “OK”. Bây giờ, để thực hiện sao lưu, chỉ cần chạy:

[email protected]:$ barman backup test-server

Cấu hình thực tế

Cấu hình Barman được sử dụng cho đến nay rất đơn giản, nhưng bạn có thể dễ dàng thêm một vài tham số vào site.pp và tận dụng tất cả các tính năng của Barman, chẳng hạn như các chính sách lưu giữ và sao lưu gia tăng mới có sẵn trong Barman 1.4.0.

Chúng tôi kết thúc hướng dẫn này với một trường hợp sử dụng thực tế, với các yêu cầu sau:

• bản sao lưu hàng đêm lúc 1:00 sáng
• khả năng thực hiện Khôi phục kịp thời cho bất kỳ thời điểm nào trong tuần trước
• luôn có sẵn ít nhất một bản sao lưu
• báo cáo lỗi qua barman check trong trường hợp bản sao lưu mới nhất cũ hơn một tuần
• bật tính năng sao lưu gia tăng để tiết kiệm dung lượng đĩa

Chúng tôi sử dụng tệp Puppet file tài nguyên để tạo .pgpass tệp với các tham số kết nối và cron tài nguyên để tạo ra công việc chạy hàng đêm. Cuối cùng, chúng tôi chỉnh sửa barman::server để thêm các thông số Barman cần thiết.

Kết quả cuối cùng là:

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

Kết luận

Với 51 dòng tệp kê khai Con rối, chúng tôi đã quản lý để định cấu hình một cặp máy chủ PostgreSQL / Barman với các cài đặt tương tự như những cài đặt chúng tôi có thể muốn trên máy chủ sản xuất. Chúng tôi đã kết hợp những ưu điểm của việc có máy chủ Barman để xử lý các bản sao lưu với những lợi thế của việc có cơ sở hạ tầng do Puppet quản lý, có thể tái sử dụng và có thể thay thế được.

Trong bài tiếp theo và bài cuối cùng của loạt bài này, chúng ta sẽ xem xét cách sử dụng Puppet Master để xuất tài nguyên giữa các máy khác nhau, do đó cho phép các máy ảo trao đổi các tham số cần thiết để hoạt động chính xác thông qua barman::autoconfigure giúp toàn bộ quá trình thiết lập dễ dàng hơn.