Automatizando o Barman com Puppet:it2ndq/barman (parte dois)

Na primeira parte deste artigo configuramos o Vagrant para executar duas máquinas virtuais Ubuntu 14.04 Trusty Tahr, respectivamente chamadas pg e backup . Nesta segunda parte veremos como usar o Puppet para configurar um servidor PostgreSQL em pg e faça backup via Barman do backup caixa.

Fantoche:configuração

Depois de definir as máquinas conforme o artigo anterior, precisamos especificar os módulos Puppet necessários que librarian-puppet vai administrar por nós.

São necessários dois módulos:

puppetlabs/postgresql (https://github.com/puppetlabs/puppetlabs-postgresql/) para instalar o PostgreSQL no pg VM
it2ndq/barman (https://github.com/2ndquadrant-it/puppet-barman) para instalar o Barman no backup

Ambos os módulos serão instalados a partir do Puppet Forge. Para o puppetlabs/postgresql módulo, teremos que usar no máximo a versão 4.2.0 no momento, pois a versão mais recente (4.3.0) está quebrando a postgres_password parâmetro que usaremos mais tarde (veja este pull request). Vamos criar um arquivo chamado Puppetfile contendo este conteúdo no diretório do projeto:

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

Agora podemos instalar os módulos Puppet e suas dependências executando:

$ librarian-puppet install --verbose

Embora não seja essencial, é preferível usar a opção --verbose toda vez que librarian-puppet é usado. Sem ele o comando fica muito tranquilo e é útil ter detalhes sobre o que está fazendo com antecedência. Por exemplo, sem usar --verbose , você pode descobrir que perdeu um tempo precioso esperando a resolução de um conflito de dependência, apenas para ver um erro muitos minutos depois.

Após a conclusão bem-sucedida do comando, um modules diretório contendo o barman e postgresql módulos e suas dependências (apt , concat , stdlib ) será criado em nosso diretório de trabalho. Além disso, librarian-puppet irá criar o Puppetfile.lock para identificar dependências e versões dos módulos instalados, fixando-os para evitar futuras atualizações. Dessa forma, a instalação do librarian-puppet runs irão sempre instalar a mesma versão dos módulos em vez de possíveis actualizações (caso seja necessária uma actualização, librarian-puppet update vai fazer o truque).

Agora podemos dizer ao Vagrant que estamos usando um manifesto Puppet para provisionar os servidores. Alteramos o Vgrantfile do seguinte modo:

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 = 'https://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

Com as linhas que acabamos de adicionar, demos ao Vagrant as instruções para provisionar as VMs usando manifests/site.pp como o manifesto principal e os módulos incluídos nos modules diretório. Esta é a versão final do nosso Vgrantfile .

Agora temos que criar os manifestos diretório:

$ mkdir manifests

e escreva nele uma primeira versão do site.pp . Vamos começar com uma configuração muito básica:

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

Agora podemos iniciar as máquinas e ver isso em backup existe um servidor Barman com uma configuração padrão (e nenhum PostgreSQL em pg ainda). Vamos fazer login no backup :

$ vagrant ssh backup

e dê uma olhada em /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

A próxima etapa é executar uma instância do PostgreSQL em pg . Devemos estar cientes dos parâmetros exigidos pelo Barman no servidor PostgreSQL, então precisamos definir:

wal_level pelo menos em arquivo nível
archive_mode para ligar
archive_command para que os WALs possam ser copiados no backup
uma regra em pg_hba.conf para acesso de backup

Todos esses parâmetros podem ser facilmente configurados através do puppetlabs/postgresql módulo. Além disso, no servidor Barman, precisamos:

uma string de conexão do PostgreSQL
um .pgpass arquivo para autenticação
um comando SSH
para realizar a troca de chave SSH

it2ndq/barman gera um par de chaves privada/pública em ~barman/.ssh . No entanto, a troca automática de chaves entre os servidores requer a presença de um Puppet Master, o que está além dos objetivos deste tutorial (será parte da próxima parcela, que se concentrará na configuração de um Puppet Master e do barman ::autoconfiguração class) – portanto, esta última etapa será realizada manualmente.

Editamos o site.pp arquivo da seguinte forma:

node backup {
  class { 'barman':
    manage_package_repo => true,
  }
  barman::server {'test-server':
    conninfo     => 'user=postgres host=192.168.56.221',
    ssh_command  => 'ssh example@sqldat.com',
  }
  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 example@sqldat.com:/var/lib/barman/test-server/incoming/%f';
  }
  class { 'postgresql::server::contrib':
    package_ensure => 'present',
  }
}

Tendo alterado o manifesto, a disposição deve ser executada novamente:

$ vagrant provision

Com as máquinas funcionando, podemos prosseguir com as trocas de chaves. Entramos em pg :

$ vagrant ssh pg

e criamos o par de chaves para o postgres usuário, usando ssh-keygen , deixando todos os campos vazios quando solicitado (sempre pressionando enter):

example@sqldat.com:~$ sudo -iu postgres
example@sqldat.com:~$ ssh-keygen
example@sqldat.com:~$ cat .ssh/id_rsa.pub

O último comando gera uma longa string alfanumérica que deve ser anexada ao ~barman/.ssh/authorized_keys arquivo em backup .

$ vagrant ssh backup
example@sqldat.com:~$ sudo -iu barman
example@sqldat.com:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys

Da mesma forma, copiamos a chave pública do barman usuário nas authorized_keys arquivo do postgres usuário em pg :

example@sqldat.com:~$ cat .ssh/id_rsa.pub
ssh-rsa ...
example@sqldat.com:~$ logout
example@sqldat.com:~$ logout
$ vagrant ssh pg
example@sqldat.com:~$ sudo -iu postgres
example@sqldat.com:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys

Neste ponto, fazemos uma primeira conexão em ambas as direções entre os dois servidores:

example@sqldat.com:$ ssh example@sqldat.com192.168.56.222
example@sqldat.com:$ ssh example@sqldat.com192.168.56.221

Podemos executar barman check para verificar se o Barman está funcionando corretamente:

example@sqldat.com:~$ 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)

Cada linha deve ler “OK”. Agora, para realizar um backup, basta executar:

example@sqldat.com:$ barman backup test-server

Uma configuração realista

A configuração do Barman usada até agora é muito simples, mas você pode adicionar facilmente alguns parâmetros ao site.pp e aproveite todos os recursos do Barman, como as políticas de retenção e o novo backup incremental disponível no Barman 1.4.0.

Concluímos este tutorial com um caso de uso realista, com os seguintes requisitos:

um backup todas as noites à 1h
a possibilidade de realizar uma recuperação pontual para qualquer momento da última semana
sempre ter pelo menos um backup disponível
informar um erro via barman check caso o backup mais recente tenha mais de uma semana
ativando o backup incremental para economizar espaço em disco

Usamos o arquivo Puppet recurso para criar um .pgpass arquivo com os parâmetros de conexão e um cron recurso para gerar o trabalho para ser executado todas as noites. Por fim, editamos o barman::server para adicionar os parâmetros Barman necessários.

O resultado final é:

node backup {
  class { 'barman':
    manage_package_repo => true,
  }
  barman::server {'test-server':
    conninfo                => 'user=postgres host=192.168.56.221',
    ssh_command             => 'ssh example@sqldat.com',
    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 example@sqldat.com:/var/lib/barman/test-server/incoming/%f';
  }
}

Conclusão

Com 51 linhas do manifesto Puppet conseguimos configurar um par de servidores PostgreSQL/Barman com configurações semelhantes às que poderíamos desejar em um servidor de produção. Combinamos as vantagens de ter um servidor Barman para fazer backups com as de ter uma infraestrutura gerenciada por Puppet, reutilizável e versionável.

No próximo e último post desta série de artigos veremos como usar um Puppet Master para exportar recursos entre diferentes máquinas, permitindo assim que as VMs troquem os parâmetros necessários para o correto funcionamento através do

barman::autoconfigure class tornando todo o processo de configuração mais fácil.