Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen

This entry is part 7 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Vor einiger Zeit trat der Wunsch auf mit dem aktuellen Icinga-2-Modul für Puppet beliebe Objekte aus Hiera heraus zu erzeugen. Zum Beispiel aus folgender Hiera-Datei sollen ein Host-Objekt und zwei Service-Objekte gebaut werden.

---
monitoring::object:
  'icinga2::object::host':
    centos7.localdomain:
      address: 127.0.0.1
      vars:
        os: Linux
  'icinga2::object::service':
    ping4:
      check_command: ping4
      apply: true
      assign:
        - host.address
    ssh:
      check_command: ssh
      apply: true
      assign:
        - host.address && host.vars.os == Linux

In Puppet 4 lässt sich dies nun sehr einfach mit zwei Schleifen realisieren:

class { 'icinga2':
  manage_repo => true,
}
$default = lookup('monitoring::default')
lookup('monitoring::object').each |String $object_type, Hash $content| {
  $content.each |String $object_name, Hash $object_config| {
    ensure_resource(
      $object_type,
      $object_name,
      deep_merge($default[$type], $object_config))
  }
}

Hierbei sind sogar für jeden Objekt-Type auch noch Defaults in Hiera gesetzt, z.B. in einer Datei common.yaml, die immer gelesen wird.

---
monitoring::default:
  'icinga2::object::host':
    import:
      - generic-host
    target: /etc/icinga2/conf.d/hosts.conf
  'icinga2::object::service':
    import:
      - generic-service
    target: /etc/icinga2/conf.d/services.conf

Dieses Verfahren ist mit dem selben Code auf Objekte mit allen möglichen Objekt-Typen erweiterbar. Passt man den Funktionsaufruf von lookup entsprechend an, kann auch über die Hiera-Struktur gemerged werden.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features

This entry is part 2 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute steht der Blog um des Icinga Puppet-Modul ganz im Zeichen der Icinga-2-Features. Features lassen sich entweder über die main class aktivieren und via Hiera parametrisieren oder dediziert mittels einer eigenen Klasse deklarieren.

include ::mysql::server
include ::icinga2
mysql::db { 'icinga':
  user     => 'icinga',
  password => 'secret',
  host     => 'localhost',
  grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
  before   => Class['::icinga2']
}

Da die Klasse icinga2 auch über einen Parameter features verfügt über den die angegeben Features aktiviert werden, kann auch dieser Parameter nach Hiera ausgelagert werden. Nachfolgend wird für die MySQL-IDO-Anbindung das Passwort gesetzt und veranlasst, dass erstmalig das DB-Schema importiert wird. Alle anderen Parameter für das Feature idomysql, sowie alle für mainlog und checker sind die entsprechenden Default-Werte.

---
icinga2::features:
  - checker
  - notification
  - mainlog
  - idomysql
icinga2::feature::idomysql::password: secret
icinga2::feature::idomysql::import_schema: true

Das selbe erreicht man ebenfalls unter Verwendung der direkten Deklaration:

class { '::icinga2::feature::idomysql':
  password      => 'secret',
  import_schema => true,
}

Etwas anders verhält es sich, wenn man die Feature checker, notification oder mainlog explizit deklarieren möchte. Da diese die standardmäßig aktivierten Features sind, muss das entsprechende Feature vorher deaktiviert werden bzw. nur die anderen im Parameter features angegeben werden:

class { '::icinga2':
  features => [ 'checker', 'notification' ],
}
class { '::icinga2::feature::mainlog':
  severity => 'notice',
}

Der Weg über die Konfiguration über Hiera ist da doch wirklich eleganter. Die Deklaration ist übersichtlich

include ::icinga2

und auch in Hiera ist nicht viel zu hinterlegen:

---
icinga2::feature::manilog::severity: notice
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Reguläre Ausdrücke in Hiera verwenden

Ohne weiteres lassen sich in Hiera keine regulären Ausdrücke verwenden. Allerdings lässt Hiera sich mit einem weiteren Backend hierfür nachrüsten.

# gem install hiera-regex

Die Einbindung erfolgt wie gewohnt als zusätzliches Backend und der Angabe des Daten-Verzeichnisses.

---
:backends:
- regex
- yaml
...
:regex: /var/lib/hiera

Für die Daten in der Hierarchie muss es sich um yaml-Dateien handeln, die auch das Suffix .regex besitzen. Der eigentliche Name leitet sich je nach Verwendung ab, so lautet der komplette Dateiname z.B. für ein dynamisches %{domain}, domain.regex.
Beim Inhalt verhält es sich etwas besonders. Bei mir wollte die korrekte Auswertung nur erfolgen, wenn ich mindestens 3 Leerzeichen als Einrückung bei der Key/Value-Zuweisung verwendete.

---
- '(de|us|ca)\.netways\.de$':
   puppet::puppetmaster: puppet.netways.de
- '(in|my)\.netways\.de$':
   puppet::puppetmaster: puppet.in.netways.de
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Die Puppenkiste zurück in Nürnberg

CJToM1JWgAEulggEndlich wieder eine Puppet Fundamentals Schulung in Nürnberg. Am Mittwoch ging es pünktlich um 9:00 im Holiday Inn los. In großer Runde mit 11 Teilnehmern starteten wir mit einen Überblick der Komponenten, wie Puppet-Master, -Agent, Console, External Node Classifier und deren Zusammenspiel. Nach einem abendlichen Ausflug zum Reichsparteitagsgelände folgte gestern die erweiterte Einführung in die Puppet Konfigurationsprache. Den Tag ließen wir gemeinschaftlich bei einen Schäufele-Essen in Nürnbergs Alter Küch’n ausklingen. Am heutigen letzten Schulungstag steht Moduldesign, Hiera und das Konzept von Rollen und Profilen auf dem Programm. Die Schulung ist zwar noch noch nicht zu Ende und schon freue ich mich auf die nächsten Schulungen… und auch die alljährlich stattfindende Open Source Monitoring Conference nähert sich mit Riesenschritte heuer zum zehnten Mal.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Encrypted YAML als Hiera Backend

yamlHeute auch von mir etwas zum Thema Hiera. Möchte man gewisse Informationen in seinem Hieradata-Store nicht lesbar ablegen, bietet sich die Verwendung von eYaml an. Die Verschlüsselung macht besonders Sinn, wenn ein Versionierungstool zur Ablage verwendet wird.

# gem install hiera-eyaml
# eyaml createkeys

Nach Installation des Backend und dem Erzeigen der Schlüssel, müssen noch die Berechtigungen angepasst werden.

# cp -a ~/keys /etc/puppet/keys
# chown -R root:puppet /etc/puppet/keys
# chmod 0750 /etc/puppet/keys
# chmod 0640 /etc/puppet/keys/*.pem

Die Hiera-Konfiguration könnte wie folgt aussehen:

---
:backends:
  - eyaml
  - yaml
:hierarchy:
  - secure
  - "%{fqdn}
  - defaults
:yaml:
  :datadir: "/etc/puppet/hieradata"
:eyaml:
  :datadir: "/etc/puppet/hieradata"
:pkcs7_private_key: /etc/puppet/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppet/keys/public_key.pkcs7.pem

Die Datei secure wird nicht komplett verschlüsselt, sondern nur Werte, die als zu verschlüsseln gekennzeichnet werden.

  • eyaml edit /etc/puppet/hieradata/secure.eyaml
  • password mit Encryption Marker einschließen
  • password: DEC::PKCS7[strenggeheim]!

Beim verlassen von eyaml edit wird dann die Verschlüsselung der Werte vorgenommen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Hiera: Welche Daten bekommt Puppet?

Wie im erstem Teil der Blogserie erklärt kann man mit Hiera Daten und Puppetmodule trennen. Wichtig dabei ist, dass die Daten in Abhängigkeit von Eigenschaften von Hosts gespeichert und extrahiert werden können (z.B. Hostname, Betriebssystem, Hersteller des Raidcontrollers usw.). Somit kann man nicht nur in den Puppet Klassen selbst sondern auch im Backend auf verschiedenen Eigenschaften der Server reagieren. Dabei kann man alle Fakten verwenden die von facter -p geliefert werden und die von außen hinzu gegeben werden, z.B. durch einen external node classifier (ENC) wie Foreman.
Im erstem Teil wurde ein einfaches Beispiel einer Hiera-Konfiguration gezeigt. In komplexeren Umgebungen werden die Daten nicht aus einer Datei sondern je nach Fakten aus einer ganzen Hierarchie aus YAML Dateien oder anderen Backends angezogen. Zudem können die selben Daten in den verschiedenen Hierachiestufen wieder überschrieben oder zusammengefasst werden. Zum Beispiel soll für alle meine Server ein Backup erstellt werden, weshalb der Key “bareos::ensure: present” ganz oben in der Hierarchie gesetzt wird (base.yaml). Natürlich gibt es Ausnahmen, weshalb weiter unten in der Hierachie der selbe Key auf “absent” gestellt wird, was sicherstellt, dass Bareos nicht installiert und konfiguriert wird. Je nach Hierachie kann das ganze schnell unübersichtlich werden. Welche Daten Puppet aus Hiera bekommt, lässt sich aber trotzdem einfach und schnell herausfinden, indem man hiera in der Shell aufruft. Als Parameter muss man die Hiera Konfigurationsdatei angeben und natürlich den Namen des Schlüssels der geholt werden soll.

 hiera -c /etc/puppet/hiera.yaml "bareos::ensure" 

Wenn wir als Beispiel die hiera.yaml aus dem ersten Teil verwenden, müssen wir leider feststellen, dass keine Daten gefunden werden, da wir die benötigen Fakten environment, operatingsystem bzw. fqdn nicht an Hiera übergeben. Die Fakten kann man manuell an Hiera übergeben, entweder als key=value Paare direkt beim Aufruf oder besser in Form einer yaml (-y facts.yaml) oder json Datei (-j facts.json).

$ cat facts.yaml
environment: production
::fqdn: "server1.netways.de"
::operatingsystem: Debian

Diese Daten werden normalerweise von den Hosts geliefert und müssen hier manuell übergeben werden:

hiera -y facts.yaml -c /etc/puppet/hiera.yaml -h bareos::ensure

Viel wichtiger ist aber auf welche Art und Weise man Daten aus Hiera extrahieren kann. Verwendet man den Parameter -h, werden die Daten als merged Hash zurückgegeben, d.h. Keys die auf mehreren Ebenen existieren, werden zu einem Hash zusammengeführt, wobei bei Konflikten der erst gefundene Key verwendet wird. Verwendet man den Parameter -a, werden die Daten als flattend Array zurückgeliefert, das bedeutet, dass Keys die auf mehreren Ebenen gefunden werden, zu einem gemeinsamen Array zusammengeführt werden. Bei einem Aufruf ohne Parameter wird einfach der zu erst gefunden Key verwendet.
Passend zum Thema darf ich euch noch an das PuppetCamp in Düsseldorf am Donnerstag erinnern!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Weekly Snap: Heira, HTML Floats Upgraded & Logstash Quick Start

weekly snap6 – 10 October offered guides on Heira, Logstash and the new generation of floats in HTML, plus a few OSDC announcements along the way.
Eva started the week counting 50 days to the OSMC by sharing Alan Robertson’s talk: “Monitoring and Discovery with Limit”.
She went on to announce early bird specials for the OSDC in Berlin coming up in April, and tout the Call for Papers.
Achim then gave a short guide to Hiera, a key value backend for Puppet while Thomas W presented his updated quick start tutorial on Logstash.
Lastly, Marius celebrated “Flexible Box Layout Module” as the neo-“floating” containers in HTML.

Hiera: Ein Key Value Backend für Puppet

Um Daten von den Puppet Modulen zu trennen wurde das Backend Hiera eingeführt. In der einfachsten Form werden Daten aus einer YAML-Datei geholt. Diese befüllen die Parameter der Puppet Klassen und können zudem abhängig von Eigenschaften der Hosts (genauer Fakten `facter -p`) gemacht werden (z.B. Hostname, Betriebssystem, Hersteller des Raidcontrollers usw.). Somit kann man nicht nur in den Puppet Klassen selbst sondern auch im Backend auf verschiedenen Eigenschaften der Server reagieren.
Hiera installiert man am besten über den Paketmanager. Ab der Version 3.x kommt Hiera als Abhängigkeit von Puppet mit. Die Konfigurationsdatei hiera.yaml ist relativ einfach und schnell erklärt und liegt für gewöhnlich in /etc/puppet/.

$ cat /etc/puppet/hiera.yaml
---
:backends:
  - yaml
:hierarchy:
  - "fqdn/%{::fqdn}"
  - "%{operatingsystem}"
  - base
:yaml:
  :datadir: '/hieradata/%{::environment}'
:logger: console

Als Backend werden YAML-Dateien verwendet, diese liegen im Verzeichnis /hieradata/%{::environment}. Der Key hierachy gibt an welche YAML-Dateien im speziellen angezogen werden. Die Einträge von hierachy werden von oben nach unten abgearbeitet und können Variablen enthalten welche von den Hosts geliefert werden (`facter -p`). Ein kurzes Beispiel:
Auf dem Debian Server server1.netways.de wird `puppet agent -t –environment testing` ausgeführt. Hiera sucht somit die Daten in folgenden Dateien in der angegeben Reihenfolge:
– /hieradata/testing/fqdn/server1.netways.de.yaml
– /hieradata/testing/Debian.yaml
– /hieradata/testing/base.yaml
Sollte eine der YAML-Dateien nicht existieren wird diese einfach übersprungen. Wann und wie Puppet Aufrufe an Hiera sendet wird im nächsten Blogpost von mir erklärt.
Mit Hiera kann man sehr einfach und schnell seine Daten aus den Puppet Module fern halten und flexibel auf seine eigene Infrastruktur reagieren. Durch verschiedenen Backends können auch andere Datenquellen wie z.B. eine CMDB angezogen werden. Mehr Ideen was man alles mit Hiera machen kann gibt es natürlich auch in unseren Puppet Architect Schulungen.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Reminder für das morgige Puppet Webinar

puppetUnsere Webinare erfreuen sich immer größerer Beliebtheit – trotzdem wollen wir es uns nicht nehmen lassen, kurz vorher noch einmal einen Reminder rauszuschicken!
Morgen früh um 10:30 Uhr, werden Markus und ich ein weiteres Puppet Webinar halten – diesmal aber mit dem Thema “Puppet: Aufbau einer Open Source Umgebung”, in dem wir uns näher mit Foreman beschäftigen wollen.
Bei Interesse sollte man sich gleich registrieren! Wer bisherige Webinare verpasst hat und es noch nicht kennt: Einfach in unserem Webinar Archiv vorbeischauen!
Übrigens: Als Vorbereitung empfiehlt es sich, die beiden bisherigen Puppet-Webinare Konfigurationsmanagement mit Puppet und Puppet: Aufbau einer Puppet Enterprise Umgebung anzusehen, um sich einen besseren Überblick über Puppet selbst zu verschaffen.
Wir freuen und schon auf morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Reminder für das morgige Puppet Webinar

PuppetIch möchte noch einmal auf das morgige Webinar zum Thema Puppet: Aufbau einer Puppet Enterprise Umgebung hinweisen. Ziel soll es sein, einen groben Überblick über die Funktionsweise und Möglichkeiten zu geben, aber auch die Unterschiede zur Open Source Variante herauszustellen.
Natürlich werden wir, wie bisher auch, detailliert auf Fragen eingehen und einige Beispiele demonstrieren, die in der Open Source Variante genauso hilfreich sein können.
Wer sich registrieren möchte, hat über unsere Webinarseite jetzt noch die Gelegenheit.
Bis morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".