Schlagwort: puppet

Puppet: Klassen mit Parameteruebergabe in Hiera

prego Schreib einen Kommentar

Der dritte Teil beschaeft sich damit, wie man pro Node in Hiera eine eigene Konfigurationsdatei anlegen kann sowie mit Klassen denen Parameter uebergeben werden. Er baut auf den beiden vorherigen Hiera-Blogeintraegen (1 und 2) auf. Grundsaetzlich ist vorneweg zu sagen, dass das ganze mit Puppet 3 fuer eigene Module bedeutend einfacher ist, da dort Hiera und vor allem das autolookup bereits integriert ist. In Puppet 2.7 muss man fuer die gleiche Funktionalitaet eine Kruecke bauen, doch dazu spaeter mehr.

Zuerst wird die Hiera Konfiguration erweitert, so das pro Node eine eigene Konfigurationsdatei moeglich ist. Diese sollen unter hieradata/nodes/ liegen und dafuer in der die hiera.yaml die hierarchy Sektion wie folgt erweitern:

:hierarchy:
    - common
    - nodes/%{fqdn}

Danach den neuen Ordner anlegen:

 mkdir /etc/puppet/hieradata/nodes/

In Puppet 2.7 und Puppet 3 gibt es nun Unterschiede. Das haengt mit dem automatischen Parameterlookup zusammen der in Puppet 3 integriert ist, in Puppet 2.7 aber nicht. An der Hiera Konfiguration aendert sich nichts, aber die Module die ich bisher vorgestellt hatte muessen angepasst werden. Damit sich diese unter Puppet 2.7 genauso verhalten wie unter 3, muss man wie in der verlinkten Dokumentation die Parameter mit einer Hiera-Suche und Defaultparametern modifizieren.

Wie die Anpassung geht und wie man die das ganze in Hiera abbildet moechte ich im folgenden Anhand des apt-Moduls, das ich im Blogeintrag Puppet: ein Modul mit Template, Variablen und Bedingung (/etc/apt/sources.list) vorgestellt habe., zeigen.

Die init.pp wurde wie folgt geaendert:

class apt (
  $mirror  = hiera('apt::mirror', 'http://ftp.de.debian.org'),
  $release = hiera('apt::release', 'wheezy'),
  $source  = hiera('apt::source', false),
  ) {
 
  file { '/etc/apt/sources.list':
    ensure  => 'present',
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => template('apt/sources.list.erb'),
    }
}

Das Modul hatte ich wie folgt im Node eingebunden:

node 'client02.example.org' inherits default {
  class { 'apt':
    mirror => 'http://debianmirror.example.org/pub/linux/debian/debian/',
    source => true
  }
}

Die Einbindung erfolgt nun ueber die Datei hieradata/nodes/client02.example.org.yaml:

---
classes: apt
apt::mirror: http://debianmirror.example.org/pub/linux/debian/debian/
apt::source: true

Danach kann die komplette Nodekonfiguration aus der site.pp geloescht werden.

Puppet: Klassen in der Nodekonfiguration aus Hiera einbinden

prego Schreib einen Kommentar

Nachdem Hiera installiert ist moechte ich aufschreiben, wie man in der site.pp Klassen in der Nodekonfiguration aus Hiera einbindet. Dieser Blogeintrag baut inhaltlich auf der Struktur auf, die ich unter Puppet: Hiera und Puppet – Installation, Einrichten, Moduleinbindung beschrieben habe.

Im ersten Schritt werden die Klassen fuer den default Node extrahiert. Der Eintrag in meiner site.pp sieht vorher wie folgt aus:

node default {
  class { 'foo': }
  class { 'bar': }
  class { 'baz::moo': }
  include users::mmuster
}

Die Klassen werden dann in der folgenden Syntax in die common.yaml uebertragen:

---
classes:
  - foo
  - bar
  - baz:moo

Danach kann die Nodedefinition in der site.pp wie reduziert werden. Wichtig ist den abschliessenden whitespace nach dem Komma zu beruecksichtigen:

node default {
  hiera_include('classes','')
  include users::mmuster
}

Das ganze ist auch in der offiziellen Puppet Dokumentation beschrieben unter „Assigning Classes to Nodes With Hiera (hiera_include)„.

Puppet: Hiera und Puppet – Installation, Einrichten, Moduleinbindung

prego Ein Kommentar

Hiera ist eine key-/value Datenbank von Konfigurationsdaten fuer Puppet. Als ersten Schritt moechte ich aufzeigen wie man es installiert, minimal einrichtet und testweise in ein Modul einbindet.

Zuerst muss auf dem Puppetmaster Server (ich arbeite unter Debian Wheezy) das folgende Paket inklusive seiner Abhaengigkeiten installiert werden:

aptitude install ruby-hiera-puppet

Nach der Installation muss eine Konfigurationsdatei fuer Hiera unter Puppet erzeugt werden. Die Datei ist per Definition die /etc/puppet/hiera..yaml. Sie hat folgenden Inhalt:

---
:backends:
    - yaml

:hierarchy:
    - common

:yaml:
    :datadir: '/etc/puppet/hieradata'

Erklaerung der hier gemachten Einstellungen:

  • —: Definiert den Beginn der Datei
  • :backends: Gibt das Format an in dem die die Daten vorliegen. In diesem Fall ist YAML definiert.
  • :hierarchy: Definiert die Hierarchie der Datenquellen. In diesem Fall gibt es nur eine moegliche Datenquelle ‚common‘
  • :yaml::datadir:Definiert fuer das YAML Backend das Verzeichnis in dem die Daten gespeichert sind. In diesem Fall das Verzeichnis /etc/puppet/hieradata

Sicherstellen das das gerade angesprochene Verzeichnis existiert:

mkdir -p /etc/puppet/hieradata

Anschliessend die folgende Datei common.yaml in dem Verzeichnis anlegen:

---
testmessage: hallo welt

Testen ob alles funktioniert kann man das ganze danach mit dem folgenden Aufruf:

hiera -c /etc/puppet/hiera.yaml testmessage

Zum Schluss noch ein Beispiel wie man den Wert nun in Puppet in einer Klasse ausliesst und in einer Datei speichert:

class hieratest {
    $testmessage = hiera("testmessage")
    file { '/tmp/hieratest.txt':
        content => inline_template("<%= testmessage %>n"),
    }
}

Wenn man daraus zum Beispiel ein Modul ‚hieratest‘ macht, auf einem Node einbindet und Puppet laufen laesst, dann findet man dort die Datei /tmp/hieratest.txt mit dem definierten Inhalt ‚hallo welt‘.

Puppet: Informationen des Nodes mit facter auslesen

prego Schreib einen Kommentar

In heterogenen Setups ist es wichtig das sich die Module und Klassen den nodespezifischen Eigenheiten anpassen. Dafuer koennen in Puppet Informationen aus facter verwendet werden.

Facter is an independent, cross-platform Ruby library designed to gather information on all the nodes you will be managing with Puppet. It is available on all platforms that Puppet is available.

Facter ist auch ein eigenstaendiges Tool. Nach dem Aufruf werden die zur Verfuegung stehenden Informationen ausgegeben.

Ein Anwendungsbeispiel ist mit einem Modul sicherzustellen, dass SSH installiert und der SSH Serverdienst auch laeuft. Auf Debian basierten Systemen heisst der Dienst ’ssh‘, waerend auf RedHat basierten Systemen der Dienst ’sshd‘ heisst. In einem Puppet Modul laesst sich das mit Informationen aus facter wie folgt abbilden:

class ssh_server {
  case $::osfamily {
    Debian: {
      $serviceName = 'ssh'
    }
    RedHat: {
      $serviceName = 'sshd'
    }
  }
 
  service { $serviceName:
    ensure => 'running',
  }

Aber nicht nur in den manifest Dateien kann man auf die Informationen aus facter zurueckgreifen, auch in den Templates stehen diese zur Verfuegung. Eine sinnvolle Modifikation des Templates jail.local.erb das ich in dem fail2ban Modul gezeigt habe ist, die Emails nicht an fail2ban@localhost sondern an fail2ban@FQDN zu verschicken. Dafuer muss die folgende Zeile geaendert werden:

  • alt: 
    destemail = fail2ban@localhost
  • neu: 
    destemail = fail2ban@<%= fqdn %>