Seite wählen

NETWAYS Blog

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".