Puppet Module mittels r10k über Puppetfile deployen

Hier ein kurzer Überblick über mein aktuelles Management meiner Puppet Module und Manifests mittels r10k. Das Tool r10k kümmert sich darum, das aus einem Git-Branch innerhalb eines Repositories mit Puppet Code ein nutzbares Puppet Environment wird. Das unten stehende Setup läuft nun bereits seit einigen Monaten so produktiv und ich bin wirklich sehr zufrieden mit r10k.

Meine eigentliche r10k Konfiguration ist sehr einfach gehalten. Ich lasse ausschließlich ein Verzeichnis /etc/puppet/environments deployen, in dem ich alle Dateien und Verzeichnise ablege. Zwecks Performance handelt es sich bei diesem Verzeichnis um ein tmpfs. Ein globales Manifest oder globale Module gibt es nicht. Hiera liegt ebenfalls im environment Verzeichnis.

# /etc/environment.conf
---
:cachedir: /var/cache/r10k
:sources:
   :environments:
     remote: ssh://root@localhost/opt/puppet/environments.git
     basedir: /etc/puppet/environments

Hier ein kurzer Ausschnitt über den Aufbau des Git-Repositories. Der Masterbranch wurde von „master“ umbenannt in „production“, um hier mit Puppet auf einen gemeinsamen Nenner zu kommen. Aktuell gibt es zwei Branches: production und testing.

658084 drwxr-xr-x 10 root root 4.0K May 10 22:30 .
702437 drwxr-xr-x  3 root root 4.0K Dec 18  2014 ..
715811 -rw-r--r--  1 root root  207 Apr 30 21:50 environment.conf
832255 drwxr-xr-x 28 root root 4.0K Apr 30 21:57 forge/
658085 drwxr-xr-x  8 root root 4.0K Jul 14 22:56 .git
133592 drwxr-xr-x  4 root root 4.0K May 10 22:28 hieradata/
659093 drwxr-xr-x  2 root root 4.0K Apr 28 21:28 manifests/
659095 drwxr-xr-x 24 root root 4.0K May 10 21:59 modules/
718207 -rw-r--r--  1 root root 2.0K May 10 22:30 Puppetfile
727181 drwxr-xr-x 26 root root 4.0K Apr 30 21:56 puppetlabs/
658124 -rw-r--r--  1 root root    2 Dec 18  2014 README
727182 drwxr-xr-x 10 root root 4.0K Apr 30 21:56 theforeman/
659308 drwxr-xr-x  2 root root 4.0K Dec 18  2014 tools/

Die Modulpfade werden mit einer environment.conf konfiguriert. Dies hat den schönen Vorteil, das man hier sauber zwischen Testing und Production trennen kann und je nach Branch zusäzliche Verzeichnise ohne viel Aufwand einbringen kann. Die Trennung nach Quelle der Module ist einfach Geschmackssache und hat keinen wirklichen technischen Vorteil.

# environment.conf
modulepath = puppetlabs:theforeman:forge:modules:/etc/puppet/modules:/usr/share/puppet/modules
manifest = manifests
#config_version = get_environment_commit.sh
#environment_timeout = 180

Die eigentliche Logik für alle „externen“ Module liegt in der Datei „Puppetfile“. Dieses File wird von r10k je nach Wunsch bei jedem Deployment evaluiert. Dort können Module aus Git und SVN-Repos oder aber Module aus der Puppet Forge (Forge API) eingebunden werden. Hier noch eine Doku von Puppetlabs zum Thema Puppetfile. Hier meine momentane Konfiguration, mit der ich sehr glücklich bin (aufklappen, um die komplette Config zu sehen).

#!/usr/bin/env ruby
#^syntax detection

# puppetlabs
moduledir 'puppetlabs'
mod 'puppetlabs/acl'
mod 'puppetlabs/apt'
mod 'puppetlabs/activemq'
mod 'puppetlabs/apache'
mod 'puppetlabs/concat'
mod 'puppetlabs/corosync'
mod 'puppetlabs/dism'
mod 'puppetlabs/firewall'
mod 'puppetlabs/inifile'
mod 'puppetlabs/java'
mod 'puppetlabs/java_ks'
mod 'puppetlabs/mssql'
mod 'puppetlabs/mysql'
mod 'puppetlabs/ntp'
mod 'puppetlabs/postgresql'
mod 'puppetlabs/powershell'
mod 'puppetlabs/puppetdb'
mod 'puppetlabs/rabbitmq'
mod 'puppetlabs/reboot'
mod 'puppetlabs/registry'
mod 'puppetlabs/stdlib'
mod 'puppetlabs/vcsrepo'
mod 'puppetlabs/win_desktop_shortcut'
mod 'puppetlabs/xinetd'
# conflicts with theforeman/git
#mod 'puppetlabs/git'

# theforeman
moduledir 'theforeman'
mod 'concat_native', :git => 'https://github.com/theforeman/puppet-concat_native.git'
mod 'dhcp', :git => 'https://github.com/theforeman/puppet-dhcp.git'
mod 'dns', :git => 'https://github.com/theforeman/puppet-dns.git'
mod 'foreman', :git => 'https://github.com/theforeman/puppet-foreman.git'
mod 'foreman_proxy', :git => 'https://github.com/theforeman/puppet-foreman_proxy.git'
mod 'git', :git => 'https://github.com/theforeman/puppet-git.git'
mod 'puppet', :git => 'https://github.com/theforeman/puppet-puppet.git'
mod 'tftp', :git => 'https://github.com/theforeman/puppet-tftp.git'

# forge
moduledir 'forge'
mod 'acme/sysstat'
mod 'adrien/alternatives'
mod 'akumria/nullmailer'
mod 'crayfishx/gemsource'
mod 'darin/zypprepo'
mod 'duritong/trocla'
mod 'elasticsearch/logstash'
mod 'garethr/erlang'
mod 'hunner/hiera'
mod 'ispavailability/file_concat'
mod 'jdowning/rbenv'
mod 'liamjbennett/win_facts'
mod 'nanliu/staging'
mod 'pdxcat/collectd'
mod 'richardc/datacat'
mod 'rismoney/chocolatey'
mod 'rtyler/jenkins'
mod 'saz/memcached'
mod 'saz/sudo'
#mod 'spotify/puppetexplorer'
mod 'stahnma/epel'
mod 'thias/mailman'
mod 'thias/postfix'
mod 'thomasvandoren/etckeeper'
#mod 'wcooley/nss_pam_ldapd'
mod 'yguenane/authconfig'
mod 'ghoneycutt/dnsclient'

Wer genau hinsieht bemerkt hier das ich alle Module des Foreman Projekts immer aus dem GitHub Masterbranch ziehe. GitHub würde ich generell als Anlaufstelle für Foreman weiterempfehlen. Das Projekt Foreman bringt seine Updates nur sehr unregelmäßig in die Forge ein, wodurch man dann auf wichtige Features wie Support für den Puppetserver sehr lange warten oder gar komplett verzichten müsste.

Bei obiger Konfiguration handelt es sich um das Testing Environment. Das schöne an r10k in Zusammenhang mit einem Puppetfile ist, das auch hier das branchen ohne Probleme funktioniert. Währand ich mich in meinem Test-Environment z.B. immer auf die aktuellsten Versionen oder den Masterbranch bei GitHub ausrollen kann, ist es mir auch möglich Module auf gewisse Versionsstände zu pinnen.

# Pinnen auf einen commit (auch möglich: tags oder branches)
mod 'apache',
  :git    => 'https://github.com/puppetlabs/puppetlabs-apache',
  :commit => 'a0224412893d39463a4fde82887312b279f83e1b'

# Das ganze mit Modulen aus der Puppet Forge
mod 'puppetlabs/apache', '0.10.0'

Dadurch können alle Updates von externen Modulen „sanft“ eingeführt werden und durch alle Environments getestet werden.

Der Worklow bei der Modulentwicklung gestaltet sich dann wie folgt.

# Änderungen am Git-Repo durchführen und commiten
root@foreman01.linux-dev.de:/opt/puppet/environments.git
-bash# git commit -a -m "Neues Feature"
[production 9a5a113] Neues Feature
 1 file changed, 3 insertions(+)

# Push zum Remote
root@foreman01.linux-dev.de:/opt/puppet/environments.git
-bash# git push
Counting objects: 11, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 535 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To git@intern01.linux-dev.de:/opt/git/environments.git
   36a61ec..9a5a113  production -> production

# Deployment aller Branches via r10k
root@foreman01.linux-dev.de:/opt/puppet/environments.git/modules
-bash# r10k deploy environment -v -p
[R10K::Action::Deploy::Environment - INFO] Deploying environment /etc/puppet/environments/testing
[R10K::Action::Deploy::Environment - INFO] Deploying environment /etc/puppet/environments/production

[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/puppetlabs/acl
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/puppetlabs/apt
...
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/theforeman/concat_native
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/theforeman/dhcp
...
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/forge/sysstat
[R10K::Action::Deploy::Environment - INFO] Deploying module /etc/puppet/environments/production/forge/alternatives
...

Je nach Bedarf kann man r10 mit oder ohne den Parameter „-p“ ausführen. Mit „-p“ wird das Puppetfile evaluiert und die Module aus der Forge bzw. GitHub eingebunden. Lässt man den Parameter weg, werden ausschließlich die Environments ausgerollt. Empehlenswert ist evtl. auch einen Post-Commit Hook in der Repository für r10k einzurichten. Hat man mehrere Master im Einsatz können die Tools ansible oder mcollective hier unterstützen.