MesosCon Europe

Dieses Jahr findet die MesosCon Europe in Amsterdam statt. Neben schönem Wetter und einer tollen Stadt erwartet uns ein breites Programm rund um das Apache Mesos Framework.
Mesos selbst ist ein Cluster Framework zur Verwaltung der im Rechenzentrum zur Verfügung stehenden Ressourcen (z.B. CPU, Ram, Storage). Ein Scheduler in Mesos bietet diese Ressourcen verschiedensten Applikationen an und startet diese. Insbesondere im Containerumfeld bietet Mesos in Kombinationen mit Marathon (ein Mesos Plugin) viele Möglichkeiten seine Applikationen zu verwalten.
Die kürzlich veröffentlichte Version 1.0 ist natürlich ein großes Thema. So bietet Mesos jetzt neben einer neuen HTTP API auch einen unified containerizer zum Starten verschiedener Container Formate. Auch im Networking Bereich bietet die neue Version neue Features, vor allem die Möglichkeit eine IP je Container zu vergeben gehört zu den Highlights. Nicht zuletzt wird der Release von einem neuen Autorisierungsmodell abgerundet.
Das breit angelegte Programm bietet in den nächsten zwei Tagen Vorträge zu vermutlich allen Themen rund um Mesos, Marathon, Microservices, Service Discovery, Storage, DC/OS und mehr, aber natürlich geben auch namhafte Firmen wie Twitter und Netflix Einsicht in ihre Setups, bei denen natürlich Mesos die Microservices verwaltet.
Ein Hackathon am Freitag lässt die Konferenz schön ausklingen. Leider geht es für uns vorher schon zurück nach Nürnberg.

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.

docker-compose

Docker LogoAuf der diesjährigen DockerCon in San Francisco wurden viele Neuerungen vorgestellt. Neben der eigentlichen Docker Engine wurde auch eine neue Version von Compose vorgestellt. Mit docker-compose kann man ganze Anwendungsumgebungen definieren und mit einem Befehl starten. Dies ist vor allem für Setups mit mehreren Containern hilfreich. Man definiert in einer zentralen Datei (docker-compose.yml) die benötigten Container und deren Parameter und führt den Befehl docker-compose up aus. Wer Vagrant benutzt erkennt sofort die parallelen zur Vagrantfile. Compose sorgt dann dafür, dass die Container wie definiert gestartet werden.
Die docker-compose.yml ist im einfachen YAML-Format gehalten. Im folgendem ein kurzes Beispiel aus der offiziellen Dokumentation:

web:
  build: ./web/
  ports:
   - "5000:3333"
  links:
   - redis
  volumes:
   - .:/code
redis:
  image: redis

In diesem Beispiel wird für den Container web ein Image mit Hilfe der ./web/Dockerfile gebaut (build: ./web/), der Port 5000 wird an den Container Port 3333 weitergeleitet, es wird ein Link zum Container redis erstellt und es wird das Volume /code gemountet. Für den redis Container wird einfach das Image von DockerHub heruntergeladen.
docker-compose up -d startet web und redis im Hintergrund und mit docker-compose ps werden die aktuell laufenden Container angezeigt. docker-compose stop beendet diese wieder.
Am Besten einfach selber ausprobieren. docker-compose selbst kann man einfach mit pip installieren.

# pip install -U websocket
# pip install -U docker-compose
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.

Verifying YAML

Wer Puppet mit Hiera und einem YAML Backend nutzt weiß das einfache Format sicherlich zu schätzen. Listen, Maps und Einzelwerte lassen sich schnell, einfach und leserlich abbilden:

Liste1: ["a", "b", "c"]
Liste2:
  - d
  - e
MapEins:
  eins: 1
  zwei: 2
  drei:
    drei: 3
key: value

Zur Interpretation der Datenstrukturen verlässt sich YAML auf eine fehlerfreie Einrückung der einzelnen Elemente, z.B. müssen in Liste2 die Element e und d mit gleich vielen Leerzeichen eingerückt werden. Im Prinzip eine sehr einfach Regel, allerdings ist vermutlich auch schon jeder in solch kleine Stolperfallen des YAML-Formats gelaufen. In Verbindung mit Puppet führt dies manchmal zu unklaren bzw. ungenauen Fehlermeldungen. Oftmals werden Fehler durch zu viele oder zu wenige Leerzeichen, Tabs, unsichtbare Sonderzeichen bzw. falsche Zeilenumbrüche verursacht. Aber soweit muss es nicht kommen, da es viele Möglichkeiten gibt die YAML-Syntax zu prüfen. In der Regel bietet jede Skript Sprache einen YAML-Parser, welche mehr oder weniger klare Fehlermeldungen ausgeben. Für ein kleines Beispiel habe ich ein Element falsch eingerückt und in verschiedenen Skript Sprachen geladen:

$ python -c "import yaml; yaml.load( open('my.yaml', 'r'), Loader=yaml.CLoader  )"
yaml.scanner.ScannerError: mapping values are not allowed in this context
  in "my.yaml", line 8, column 8
$ ruby -e "require 'yaml'; YAML.load_file('my.yaml')"
/usr/share/ruby/psych.rb:370:in 'parse': (my.yaml): mapping values are not allowed in this context at line 8 column 8 (Psych::SyntaxError)
$ js-yaml my.yaml
JS-YAML: bad indentation of a mapping entry at line 8, column 8:
       zwei: 2
           ^

Ihr seht selbst, dass js-yaml den Fehler wohl am besten und klarsten darstellt. Natürlich will keiner immer wieder auf der Command-Line überprüfen ob die verwendeten YAML Dateien korrekt formatiert sind. Am besten soll dies der Editor bereits beim speichern der Datei anzeigen. Wer vim mit Syntastic verwendet muss nur dafür sorgen, dass js-yaml vorhanden ist. Dies installiert man am besten über den Node.js Paket Manager npm.

$ apt-get/yum/dnf install npm
$ npm install -g js-yaml

Wie man Syntastic für vim installiert könnt ihr hier nachlesen.

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.

Input/Output Muster visualisieren

In modernen Storage-Systemen wie Ceph hat man in der Regel verschiedene Arten und Möglichkeiten Caching zu realisieren. Bei einem einfachem Ceph Setup ist für gewöhnlich ein Schreib-Cache vorhanden der aus SSDs besteht. Verwendet man Ceph in Kombination mit QEMU/KVM so kann zusätzlich noch der sogenannte RBD-Cache aktiviert werden welcher bereits aus den Virtualisierungshosts Daten puffert.
Natürlich wird durch das Puffern der Daten das Lese- und Schreibmuster auf den endgültigem persistentem Datenträger (meist SAS- bzw. SATA-Platten) immer undurchsichtiger.
Mit Hilfe von blktrace kann man die Lese- und Schreibzugriffe auf dem Datenträger lokalisieren und seekwatcher erstellt einem ohne großen Aufwand auch noch ein Video davon.

# yum/apt-get install blktrace seekwatcher mencoder
# blktrace -d /dev/sda -o find
# seekwatcher -t find.blktrace.* -m -o find.mpg

Der erste Befehl schreibt alle aktuellen Aktivitäten von sda nach find.blktrace.x Dateien. seekwatcher erstellt anschließend ein Video.
Das erste Video zeigt ein `vagrant up` einer icinga2-Box. Die Box wird langsam heruntergeladen, das Image nochmals kopiert und dann geht es los mit der Installation. Das zweite Video zeigt ein `find /`. Jedes Quadrat zeigt einen Sector an und wird farbig sobald IO auf diesem stattfindet. Dieser blendet sich anschließend langsam wieder aus. Ich finde in diesen beiden Fällen kann man die IO-Muster schön interpretieren.


Für einen besseren Vergleich kann man sich die beiden Fälle auch in einer Grafik anzeigen lassen. Hat man noch Datenträger die sich drehen ist hier unter anderem der Seek Count interessant, aber seht selbst.
IO-Vergleich find / vs vagrant up

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.

Testumgebungen leicht gemacht mit Vagrant

Vagrant Logo
Egal ob Softwareentwickler oder Systemadministrator, wer in der IT arbeitet kennt sicherlich den Satz “Bei mir funktioniert das!”. Damit man sich nicht ständig über verschiedene Versionen, Betriebssysteme und Einstellungen ärgert, wäre es schön, wenn jeder im Team die gleiche Entwicklungsumgebung verwenden kann. Hier kommt Vagrant ins Spiel.
Mit Vagrant kann man schnell und einfach virtuelle Maschinen starten und automatisch konfigurieren. Dabei werden alle wichtigen Einstellungen in einer zentralen Textdatei (Vagrantfile) definiert. Man beginnt in der Regel mit einem Basisimage mit vorinstalliertem Betriebssystem. Auf www.vagrantbox.es findet sicher jeder etwas passendes. Noch kurz das Netzwerk konfigurieren, Pakete installieren, Konfigurationsdateien über Shared Folders einbinden und die VM mit Vagrant starten und fertig ist die Testumgebung. Und das alles in einer kleinen Textdatei mit welcher der Kollege exakt die gleiche Umgebung in wenigen Minuten gestartet hat. Ist man erstmals angefixt entstehen schnell ganze Multitier-Testumgebungen zum Beispiel für Puppet, OpenNebula und Foreman. Und für wen virtuelle Maschinen ein alter Hut sind, Vagrant kann auch leichtgewichtige Docker Containern starten. Natürlich findet man viele Informationen dazu online oder aber man besucht unseren Vagrant Workshop und holt sich anschließend weitere Ideen auf der OSDC in Berlin. Mitchell Hashimoto, der Erfinder von Vagrant, hält dort übrigens einen Vortrag. Also schnell anmelden bevor alle Plätze weg sind!

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.

Monitoring Konfiguration automatisieren

Eine automatische Konfiguration von Server und Hardware ist mittlerweile dank Puppet und Co. in vielen IT-Abteilungen angekommen. Die Konfiguration des Monitoring erfolgt in vielen Fällen aber weiterhin mehr oder weniger manuell. Gründe dafür gibt es vermutlich viele. Zum Beispiel wenn Puppet und das Monitoring durch verschiedene Abteilungen betrieben wird oder es gibt Misstrauen gegenüber automatischer Konfiguration oder oftmals gibt es gut funktionierende Prozesse, wieso sollte ich diese ändern?
Allerdings sind alle Informationen die ich zum Überwachen der Server benötige auch in irgendeiner Form per Puppet, Hiera, Facter oder CMDB  verfügbar und müssen im Prinzip nur noch zu einer funktionierenden Konfiguration zusammengefügt werden. Wie kommt man am besten an die Informationen?
Beispiel 1: RaidController Checks automatisch erstellen

  • Puppet läuft und sammelt seine Fakten
    • darin ist auch ein Fakt enthalten, welches sich per lspci den vorhanden RaidController sucht
  • da ein LSI MegaRaid Controller verbaut ist wird StorCli installiert und ein entsprechendes Check Plugin
  • mit Hilfe des Icinga2 Puppet Moduls wird ein Service Check in die PuppetDB exportiert

Beispiel 2: VHost Checks automatisch erstellen

  • VHost sind im Hiera i.d.R. unter dem Key apache::vhost definiert
  • mit Hilfe von der Hiera Lookup Functions kann man Information aus hiera extrahieren
  • mit Hilfe des Icinga2 Puppet Moduls wird ein Service Check in die PuppetDB exportiert

Die Monitorserver realisieren anschließend die Checks aus der PuppetDB.
Das sind natürlich zwei einfache Beispiele. Will man flexibel bleiben muss man natürlich weiter in die Trickkiste greifen und z.B. ermöglichen, dass die Parameter der Service Checks auch überschreibbar sind.
 

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.

Ceph: Datenintegrität durch Scrubbing

Für ein Storage ist Datenintegrität natürlich eine wichtige Eigenschaft, welches in Ceph unter anderem durch das sogenannte Scrubbing umgesetzt wird. In den meisten Fällen werden Daten in Ceph repliziert gespeichert, d.h. jedes Objekt wird mehrfach gespeichert. Bei Scrubbing prüft Ceph ob die Kopien der gespeicherten Objekte gleich sind. Dabei wird in zwei verschiedene Arten von Scrubbing unterschieden. Das normale Scrubbing vergleicht (wenn möglich) täglich die Attribute und Größe der Objekte. Deep-Scrubbing hingegen berechnet wöchentlich die Prüfsummen der Objekte und vergleicht diese. Treten Unterschiede auf werden diese korrigiert.
Das prüfen der Integrität geht natürlich stark zu lasten der Festplatten, da jedes Objekt eingelesen wird. Deshalb gibt es verschiedene Parameter um die Last zu streuen. Generell versucht Ceph die Scrubs über den ganzen Tag bzw. Deep-Scrubs über die ganze Woche zu verteilen. Verwendet man aber die Standardeinstellungen kann dies schnell dazu führen, dass diese Verteilung nicht mehr funktioniert.

  • osd scrub load threshold = 0.5: Dies führt dazu, dass Scrubs nur bei einer Load von weniger als 0.5 durchgeführt werden. Bei einem Storage Server ist eine Load von 0.5 sehr schnell erreicht. Dieser Wert wird nicht an die Anzahl der Kerne adaptiert.
  • osd scrub min interval = 86400 (täglich): Gibt an, nach wie vielen Sekunden Scrubs durchgeführt werden können, falls die Load nicht zu hoch ist.
  • osd scrub max interval = 604800 (wöchentlich): Gibt an, nach wie vielen Sekunden Scrubs spätestens durchgeführt werden müssen. Der Load Threshold wird nicht berücksichtigt.
  • osd deep scrub interval = 604800 (wöchentlich): Gibt an, nach wie vielen Sekunden Deep-Scrubs durchgeführt werden müssen. Der Load Threshold wird nicht berücksichtigt

Laut Mailingliste und IRC-Logs werden Deep-Scrubs immer und ausschließlich von normalen Scrubs angestoßen, und zwar dann wenn der letzte (normale) Scrub schon länger als eine Woche vergangen ist. Hat das Storage eine Load größer von 0.5 (was im Normalbetrieb immer der Fall ist), dann ist der Parameter osd scrub min interval sinnlos und es wird nach einer Woche ein normaler Scrub durchgeführt. Diese Kombination kann dazu führen, dass Deep-Scrubs erst nach  osd scrub max interval + osd deep scrub interval durchgeführt werden. Im Standard Fall somit erst nach zwei Wochen. Je nach Startzeitpunkt der Intervalle werden alle Scrubs hintereinander durchgeführt was somit alle zwei Wochen im gleichen Zeitraum Last verursacht. Im Graphite und Grafana kann man solch ein Verhalten natürlich leicht erkennen 🙂

Ceph Deep Scrub

Ceph Deep Scrub


Zum Glück gibt es noch den Parameter osd max scrubs welcher mit der Standardeinstellung dazu führt, dass nur ein Scrub pro OSD zur gleichen Zeit stattfinden darf. Die Last auf den Storage hält sich somit in Grenzen und Anwender merken nichts davon.
 
 
 
 
 

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.

DevOpsDays Ghent

Ooups, this gallery does not have any images...

Zum fünfjährigen Geburtstag wurden die DevOpsDays wieder in Ghent veranstaltet. An zwei Tagen gab es Vorträge, Ignites und Open Spaces. Von den gehaltenen Vorträgen möchte ich besonders drei erwähnen. Lindsay Holmwood hat in seinen Vortrag 5 Years of metrics and monitoring einen Überblick gegeben wie man am besten Daten sammelt, speichert und analysiert. Ein besonders Augenmerk hat er auch auf die Darstellung der Daten gelegt. Spannend war auch der Vortrag von Brian Troutwine, welcher über komplexe Systeme gesprochen hat. Er ging vor allem darauf ein wie man diese kontrollieren kann und wann Automatisierung (nicht) sinnvoll ist. Nigel Kersten hielt einen interessanten Vortrag über die fehlerhafte menschliche Wahrnehmung und daraus resultierenden fehlerhaften Entscheidungen. Dieser hält übrigens auch einen Vortrag auf der nächsten OSDC in Berlin.


In den Ingites wurden in Kurzvorträgen neue Tools und andere interessante Dinge vorgestellt, unter anderem auch Icinga 2. Am Nachmittag gab es in mehreren abgegrenzten Bereichen offene Diskussionen über vorher vorgeschlagene Themen. Dort hatten die Teilnehmer die Möglichkeiten über alles was einem auf dem Herzen liegt zu diskutieren und Erfahrungen auszutauschen. Dort wurde quasi über alles geredet was DevOps aktuell beschäftigt wie z.B. Datenpersistenz und Docker, sammeln und analysieren mit Collectd, Grafana und Logstash, Metamodelle für Puppet-Module, flexibles Konfigurationsmanagement und sehr vieles mehr.

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.

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.

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.