L’intero codice usato in questo tutorial è presente su GitHub all’indirizzo https://github.com/2ndquadrant-it/vagrant-puppet-barman.

Configurare il Puppet Master: Vagrant

Innanzitutto, occorre modificare il Vagrantfile per avviare una terza macchina, chiamata puppet, che sarà il nostro Puppet Master. Questa macchina dovrà essere subito raggiungibile dagli agenti Puppet presenti su ognuna delle VM create, per cui, all’interno del primo script che lanciamo, configuriamo una entry per il suo indirizzo in /etc/hosts.

Sempre nello script inline dobbiamo abilitare l’agente Puppet. Questo è infatti disabilitato di default nelle distribuzioni derivate da Debian.

Infine, all’interno del Vagrantfile, andiamo ad effettuare una distinzione fra master e agenti. Il primo caricherà la propria configurazione direttamente da file, gli agenti lo faranno chiedendola al master e inviandogli i dati che devono scambiarsi con gli altri nodi. Per quest’ultima ragione un agente è impostato per girare anche sul master.

Il Vagrantfile prodotto è il seguente:

Vagrant.configure("2") do |config|
  {
    :puppet => {
      :ip      => '192.168.56.220',
      :box     => 'ubuntu/trusty64',
      :role    => 'master'
    },
    :pg => {
      :ip      => '192.168.56.221',
      :box     => 'ubuntu/trusty64',
      :role    => 'agent'
    },
    :backup => {
      :ip      => '192.168.56.222',
      :box     => 'ubuntu/trusty64',
      :role    => 'agent'
    }
  }.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 and enable the Puppet agent
      local.vm.provision :shell, :inline => <<-eos
        if [ ! -e /var/tmp/.bash.provision.done ]; then
          echo "192.168.56.220  puppet.local.lan        puppet puppetdb puppetdb.local.lan" >> /etc/hosts
          curl -L #{bootstrap_url} | bash
          puppet agent --enable
          touch /var/tmp/.bash.provision.done
        fi
      eos

      if cfg[:role] == 'master'
        # Puppet master needs RAM
        local.vm.provider "virtualbox" do |v|
          v.memory = 1024
        end

        # Provision the master 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

      # Puppet agents should be provisioned by the master
      local.vm.provision :puppet_server do |puppet|
        puppet.options = [
         '--verbose',
        ]
      end

    end
  end
end

Configurare il Puppet Master: Puppet

Una volta in possesso del Vagrantfile è il momento di andare a modificare il manifesto Puppet per attivare il master.
Prima di fare questo, però, è necessario installare altri due moduli: puppetlabs/puppetdb e stephenrjonson/puppet.

puppetlabs/puppetdb configura PuppetDB. PuppetDB utilizza un database PostgreSQL per raccogliere i fatti e le risorse esportate dai vari nodi dell’infrastruttura, in modo che questi possano scambiarsi informazioni e configurarsi uno in base agli altri.
stephenrjonson/puppet permette di configurare un server Puppet Master con Apache e Passenger, nonché di configurare gli agenti sui vari nodi della rete.

Modifichiamo quindi il Puppetfile in:

forge 'https://forgeapi.puppetlabs.com'
mod 'it2ndq/barman'
mod 'puppetlabs/postgresql'
mod 'puppetlabs/puppetdb'
mod 'stephenrjohnson/puppet'

Rispetto all’articolo precedente abbiamo rimosso la dipendenza dall’ultima versione su GitHub per il modulo it2ndq/barman, del quale è stata rilasciata la versione 1.0.0 (che utilizzeremo) negli ultimi giorni. Eseguiamo:

$ librarian-puppet install --verbose

A questo punto possiamo andare a modificare il manifesto site.pp, aggiungendo il nodo puppet e inserendo al suo interno il seguente frammento di codice per PuppetDB e il Puppet Master:

  # Setup PuppetDB
  class { 'puppetdb': }->
  # Setup Puppet Master, Apache and Passenger
  class { 'puppet::master':
    storeconfigs => true,
    autosign     => true,
    environments => 'directory',
  }->

Abbiamo così configurato il Puppet Master per accettare automaticamente connessioni da tutte le macchine (autosign) e distribuire i cataloghi, i fatti e le risorse esportate (storeconfig).
Infine, utilizziamo i directory environment di Puppet per distribuire il catalogo agli agenti. La directory standard per gli ambienti è /etc/puppet/environments e l’ambiente di default è production. Inseriamo quindi i nostri manifesti e moduli al suo interno. Poiché Vagrant già condivide la directory in cui si trova il Vagrantfile con le macchine create, possiamo fare un link simbolico a questa directory:

  # Have the manifest and the modules available for the master to distribute
  file {
    ['/etc/puppet/environments', '/etc/puppet/environments/production']:
      ensure => directory;
    '/etc/puppet/environments/production/modules':
      ensure => 'link',
      target => '/vagrant/modules';
    '/etc/puppet/environments/production/manifests':
      ensure => 'link',
      target => '/vagrant/manifests';
  }

A questo punto, su ogni nodo dell’infrastruttura, dovremo configurare l’agente. Esplicitiamo il Puppet Master, l’environment e il modo in cui deve essere eseguito. Eseguire l’agente via cron occupa meno risorse che farlo girare come demone:

  # Configure Puppet Agent
  class { 'puppet::agent':
    puppet_run_style => 'cron',
    puppet_server    => 'puppet.local.lan',
    environment      => 'production',
  }

Iniziamo adesso a condividere risorse fra i vari nodi. Poiché i nodi pg e backup avranno bisogno di comunicare fra loro via SSH, dovranno sapere qual è l’ip dell’altro server e averne la chiave all’interno di known_hosts. Provvediamo quindi ad esportare e raccogliere queste risorse su ogni nodo, ad esempio:

  @@host { 'backup_host':
    ensure       => 'present',
    name         => $::fqdn,
    host_aliases => $::hostname,
    ip           => '192.168.56.222',
  }

  @@sshkey { "${::hostname}_ecdsa":
    host_aliases => [ $::hostname, $::fqdn ],
    type         => 'ecdsa-sha2-nistp256',
    key          => $::sshecdsakey,
  }

  # Collect:
  Host <<| |>>
  Sshkey <<| |>>

barman::autoconfigure

Adesso, siamo liberi di andare a configurare il server PostgreSQL e il server Barman. Con la possibilità di usare l’autoconfigure, questa parte diventa molto più semplice rispetto all’articolo precedente.

Per il nodo backup basta infatti indicare di usare l’autoconfigure e quale ip deve esportare. La macchina Vagrant infatti possiede due indirizzi ip e noi dobbiamo forzare l’utilizzo di 192.168.56.222. Inoltre, andiamo a usare il pacchetto di PGDG, abilitando manage_package_repo:

  class { 'barman':
    autoconfigure       => true,
    exported_ipaddress  => '192.168.56.222/32',
    manage_package_repo => true,
  }

Sul nodo pg provvediamo a installare il server PostgreSQL e a dichiarare come -il server PostgreSQL- debba essere gestito da Barman, attraverso la classe barman::postgres. Questa classe esporta il cron per l’esecuzione del comando barman backup pg e la configurazione del server per Barman, che saranno importati dal server backup tramite autoconfigure:

  # Configure PostgreSQL
  class { 'postgresql::server':
    listen_addresses     => '*',
  }

  # Export the parameters required by Barman
  class { 'barman::postgres':
    retention_policy        => 'RECOVERY WINDOW OF 1 WEEK',
    minimum_redundancy      => 1,
    last_backup_maximum_age => '1 WEEK',
    reuse_backup            => 'link',
    backup_hour             => 1,
    backup_minute           => 0,
  }

Test

È possibile testare tutto quello che abbiamo visto finora clonando il progetto su GitHub ed eseguendo, all’interno della directory creata:

$ librarian-puppet install --verbose
$ vagrant up
$ vagrant provision
$ vagrant provision

Il sistema deve infatti effettuare tre provision (il primo è all’interno del primo vagrant up) prima che tutte le risorse esportate siano raccolte dai nodi. A questo punto possiamo entrare nella macchina backup e controllare che il backup possa essere effettuato:

$ vagrant ssh backup
root@backup:~# barman backup all
Starting backup for server pg in /var/lib/barman/pg/base/20150320T114208
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Backup size: 18.7 MiB. Actual size on disk: 18.7 MiB (-0.00% deduplication ratio).
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for pg
        Older than first backup. Trashing file 000000010000000000000001 from server pg
        000000010000000000000002
        000000010000000000000002.00000028.backup

Conclusioni

Anche se la configurazione iniziale di un Puppet Master può essere laboriosa, i vantaggi sono enormi. Non solo la configurazione di Barman è più semplice, ma qualunque altra aggiunta all’infrastruttura ne risulta estremamente semplificata. Ad esempio, aggiungere un server Icinga o Nagios diventa molto più semplice quando ogni singolo server può esportare i servizi che devono essere monitorati (check_postgres o barman check --nagios).

Inoltre, nell’esempio abbiamo utilizzato un solo server PostgreSQL e un solo server Barman, ma in caso di infrastrutture complesse con molti database server è possibile dichiarare più server Barman e utilizzare host_group per identificare i server Postgres dei quali i diversi server Barman devono fare il backup.

Concludo con un ringraziamento speciale a Alessandro Franceschi per l’idea iniziale di aggiungere un sistema di autoconfigurazione al modulo Barman.

Puppet: configurazione

Dopo aver definito le macchine come nell’articolo precedente, occorre definire i moduli Puppet necessari, che lasceremo gestire a librarian-puppet.

I moduli sono due:

1. puppetlabs/postgresql (https://github.com/puppetlabs/puppetlabs-postgresql/) per installare PostgreSQL sulla VM pg
2. it2ndq/barman (https://github.com/2ndquadrant-it/puppet-barman) per installare Barman su backup.

Per il primo useremo la versione presente su Puppet Forge, per il secondo effettueremo il clone da GitHub del progetto, per poterne sfruttare le modifiche più recenti.

Creiamo nella directory corrente un file chiamato Puppetfile con questo contenuto:

forge "https://forgeapi.puppetlabs.com"
mod "puppetlabs/postgresql"
mod "it2ndq/barman", :git => "git://github.com/2ndquadrant-it/puppet-barman.git"

Possiamo ora installare il modulo Puppet e le sue dipendenze eseguendo:

$ librarian-puppet install --verbose

Per quanto non indispensabile, il consiglio è quello di utilizzare sempre l’opzione --verbose ogni volta che si usa librarian-puppet.  Il comando è molto silenzioso ed è bene avere dettagli su quello che sta facendo, prima di scoprire (ad esempio) di avere buttato tempo prezioso aspettando che risolvesse senza successo un complicato conflitto di dipendenze.

Al completamento del comando, all’interno della directory corrente sarà presente la nuova directory modules che conterrà i moduli richiesti (barman, postgresql) e le loro dipendenze (apt, concat, stdlib). Inoltre, sarà stato creato il file Puppetfile.lock, che identifica dipendenze e versioni dei moduli installati, fissandole a protezione di aggiornamenti futuri. In questo modo, i successivi librarian-puppet install installeranno le stesse identiche versioni definite nel Puppetfile.lock, invece di possibili aggiornamenti.

A questo punto, aggiungiamo alla configurazione di Vagrant il fatto di utilizzare un manifesto Puppet per effettuare il provisioning dei server al termine dell’installazione di Puppet.
Modifichiamo quindi il Vagrantfile in questo 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

Con le linee che abbiamo appena aggiunto, abbiamo dato a Vagrant l’istruzione di effettuare il provision delle macchine a partire dal file manifests/site.pp e che i moduli necessari al manifesto sono da cercare all’interno della directory modules. Il Vagrantfile è adesso nella sua forma definitiva.
Creiamo perciò la directory manifests all’interno della nostra directory di lavoro:

$ mkdir manifests

Andiamo quindi a scrivere in manifests una prima versione di site.pp, iniziando con una configurazione di default.

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

A questo punto, avviamo le due macchine virtuali. Se le avete distrutte al termine dell’articolo precedente, tutto quello che serve è eseguire:

$ vagrant up

Altrimenti, se le macchine sono ancora attive, occorreranno i comandi:

$ vagrant reload
$ vagrant provision

Possiamo osservare che sulla VM è stato creato un server Barman con una configurazione di base, senza alcun server configurato, connettendoci

$ vagrant ssh backup

e controllando il contenuto del file /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

Procediamo adesso ad avviare un server PostgreSQL sulla macchina virtuale pg, modificando il site.pp. Dobbiamo tenere presente di quali siano i parametri richiesti da Barman al server, per cui dovremo impostare:

• wal_level almeno a livello archive
• archive_mode a on
• archive_command in modo che i WAL possano essere copiati su Barman
• una regola nel pg_hba.conf per consentire l’accesso al database dal server backup

Tutti questi parametri sono facilmente configurabili attraverso il modulo puppetlabs/postgresql.

Inoltre, aggiungiamo i parametri minimi di configurazione per il backup del server PostgreSQL pg sul nodo backup. Avremo bisogno di:

• una stringa di connessione PostgreSQL
• un file .pgpass per l’autenticazione
• un comando per connettersi via SSH
• effettuare lo scambio delle chiavi SSH.

it2ndq-barman genera automaticamente una coppia di chiavi pubblica/privata in ~barman/.ssh/. Scambiare in automatico le chiavi richiede la presenza di un puppet master per l’esportazione delle risorse. Configurare un puppet master è fuori dagli obiettivi di questo tutorial (ma sarà parte del prossimo, incentrato proprio sull’utilizzo di un puppet master e della classe barman::autoconfigure), quindi questo ultimo passo sarà eseguito manualmente.
Modifichiamo quindi il file site.pp come segue:

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

Avendo modificato la configurazione delle macchine, è necessario rieseguire il provision:

$ vagrant provision

Quando le macchine sono su, possiamo procedere allo scambio di chiavi. Connettiamoci a pg:

$ vagrant ssh pg

e creiamo le chiavi per l’utente postgres, lasciando vuoto ogni campo durante l’esecuzione di ssh-keygen (ovvero, premendo sempre invio):

vagrant@pg:~$ sudo -iu postgres
postgres@pg:~$ ssh-keygen
postgres@pg:~$ cat .ssh/id_rsa.pub

L’ultimo comando emette una lunga stringa alfanumerica che deve essere inserita nel file ~barman/.ssh/authorized_keys su backup.

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

Allo stesso modo, copiamo la chiave dell’utente barman nel file authorized_keys dell’utente postgres su pg:

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

A questo punto, facciamo una prima connessione in entrambe le direzioni fra i due server:

postgres@pg:$ ssh barman@192.168.56.222
barman@backup:$ ssh postgres@192.168.56.221

Eseguiamo un barman check per verificare il corretto funzionamento di Barman:

barman@backup:~$ 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)

Ogni riga dovrebbe risultare OK. Adesso, per effettuare un backup, basterà lanciare:

barman@backup:$ barman backup test-server

Una configurazione realistica

La configurazione di Barman effettuata finora è molto semplice, ma è facilmente possibile aggiungere pochi parametri al site.pp per sfruttare al meglio tutte le feature di Barman, come le retention policy e il nuovo backup incrementale disponibile con Barman 1.4.0.

Concludiamo questo tutorial con un caso d’uso realistico, in cui i requisiti sono:

• un backup ogni notte alle 1:00;
• avere la possibilità  di effettuare una Point In Time Recovery in un qualunque istante di tempo nell’ultima settimana;
• avere sempre almeno un backup disponibile;
• segnalare un errore durante barman check nel caso il backup più recente sia più vecchio di una settimana;
• attivare il backup incrementale per risparmiare spazio su disco.

Usiamo quindi la risorsa file di Puppet per creare un .pgpass con i parametri di connessione al db e la risorsa cron per generare il job da ripetere ogni notte. Infine, modifichiamo il barman::server per aggiungere i parametri Barman necessari.
Il risultato finale è quello che segue:

node backup {
  class { 'barman':
    manage_package_repo => true,
  }
  barman::server {'test-server':
    conninfo                => 'user=postgres host=192.168.56.221',
    ssh_command             => 'ssh postgres@192.168.56.221',
    retention_policy        => 'RECOVERY WINDOW OF 1 WEEKS',
    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 barman@192.168.56.222:/var/lib/barman/test-server/incoming/%f';
  }
}

Conclusioni

Con 51 righe esatte di Puppet siamo riusciti a configurare una coppia di server PostgreSQL/Barman con delle impostazioni molto simili a quelle che potremmo volere in produzione. Abbiamo così combinato i vantaggi dell’avere un server Barman che gestisce i backup a quelli di avere un’infrastruttura gestita da Puppet, riutilizzabile e versionabile.

Nella prossima e ultima parte di questa serie di articoli vedremo come utilizzare un Puppet master per approfittare della possibilità di esportare risorse fra macchine diverse e così permettere alle due macchine di scambiarsi i parametri necessari al loro corretto funzionamento tramite la classe barman::autoconfigure.

Obiettivo di questo articolo, sviluppato in tre parti, sarà quello di automatizzare l’installazione di Barman e di configurarlo, sempre in modo automatico, per eseguire backup da un server PostgreSQL di test.
Questa prima parte è un aggiornamento di quanto scritto da Gabriele, ma con l’idea di creare due macchine virtuali invece di una sola.

it2ndq/barman è il modulo rilasciato da 2ndQuadrant Italia per gestire l’installazione di Barman tramite Puppet. Il modulo ha licenza GPLv3 ed è disponibile su GitHub all’indirizzo https://github.com/2ndquadrant-it/puppet-barman.
La procedura che segue è stata scritta avendo come base una Ubuntu 14.04 Trusty Tahr, ma può essere eseguita in modo simile su altre distribuzioni.

I requisiti

Per avviare il modulo per Barman su una macchina virtuale, abbiamo bisogno dei seguenti software:

• VirtualBox
• Vagrant
• Ruby >= 1.9
• Puppet
• librarian-puppet

Vagrant

Vagrant è un software per la gestione di macchine virtuali in grado di supportare numerosi software di virtualizzazione, con VirtualBox come default.

Installiamo quindi VirtualBox:

$ sudo apt-get install virtualbox virtualbox-dkms

L’ultima versione di Vagrant può essere scaricata dal sito e poi installata con il comando:

$ sudo dpkg -i /path/to/vagrant_1.7.2_x86_64.deb

Ruby

Per Ruby, il consiglio è di utilizzare rbenv, che permette di crearsi un ambiente di sviluppo Ruby in cui specificare la versione da usare.
Per installare rbenv il suggerimento è quello di usare rbenv-installer (https://github.com/fesplugas/rbenv-installer) e configurare Ruby per l’utente corrente, evitando così di sporcare l’ambiente Ruby di sistema.
Scarichiamo ed eseguiamo lo script:

$ curl https://raw.githubusercontent.com/fesplugas/rbenv-installer/master/bin/rbenv-installer | bash

Al termine, lo script chiederà di aggiungere le seguenti linee all’interno del file ~/.bash_profile:

export RBENV_ROOT="${HOME}/.rbenv"

if [ -d "${RBENV_ROOT}" ]; then
  export PATH="${RBENV_ROOT}/bin:${PATH}"
  eval "$(rbenv init -)"
fi

Ricarichiamo il ~/.bash_profile appena modificato:

$ exec bash -l

A questo punto installiamo una versione di Ruby e impostiamo l’utente per usare questa versione invece che quella di sistema:

$ rbenv install 2.1.5
$ rbenv global 2.1.5

Puppet

È necessario avere Puppet installato sulla macchina host. Installiamo quindi la gemma relativa:

$ gem install puppet

librarian-puppet

Infine, librarian-puppet è un tool per automatizzare la gestione dei moduli Puppet. Anche librarian-puppet è installabile come gemma:

$ gem install librarian-puppet

Vagrant: configurazione

Adesso che abbiamo le dipendenze a posto, possiamo iniziare a scrivere le configurazioni di Vagrant e Puppet per il nostro sistema di backup.
Iniziamo creando una directory in cui lavorare:

$ mkdir ~/vagrant_puppet_barman
$ cd ~/vagrant_puppet_barman

Vagrant ha bisogno di un file chiamato Vagrantfile dove leggere le configurazioni delle VM da avviare. Procediamo quindi con la scrittura del file.

Il seguente Vagrantfile avvia due VM Ubuntu Trusty, chiamate pg e backup, con indirizzi ip rispettivamente 192.168.56.221 e 192.168.56.222. Su entrambe le macchine verrà effettuato un provisioning attraverso uno script shell definito inline all’interno del file stesso. Tale script lancia puppet-bootstrap (https://github.com/hashicorp/puppet-bootstrap), uno script che automaticamente installa e configura Puppet su vari tipi di macchine. Siccome non è necessario che sia eseguito più di una volta, nello script inline è stato inserito un test per evitare ulteriori esecuzioni.

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
    end
  end
end

Un test

Abbiamo definito due Ubuntu contenenti Puppet. Questo non è ancora il Vagrantfile definitivo, ma già permette di creare le due macchine. Se siete curiosi, è possibile controllare che le due macchine siano effettivamente create con il comando:

$ vagrant up

e successivamente connettersi usando i comandi:

$ vagrant ssh pg
$ vagrant ssh backup

Infine, le macchine possono essere distrutte con:

$ vagrant destroy -f

Prime conclusioni

In questa prima parte di tutorial abbiamo visto come configurare le dipendenze e siamo arrivati ad avere le due macchine virtuali su cui andare a installare, via Puppet, PostgreSQL e Barman.
La scrittura del manifesto Puppet per l’installazione vera e propria sarà argomento del prossimo articolo, in uscita la prossima settimana. A presto!