Monitoring: alles ist geregelt. Aber!

Es könnte so einfach sein. Auf der einen Seite eine Reihe von Import- und Sync-Definitionen welche aus den unterschiedlichsten Quellen unsere zu überwachenden CI’s importieren. Excel, CMDB, Datenbanken, AWS, JSON, YAML, LDAP, VMware, Active Directory – alles geht. Quellen werden kombiniert, Daten angereichert und wo nötig geradegebogen. Egal wie mies die Daten sind, der Director wird’s schon richten.
Auf der anderen Seite stehen mächtige Apply-Regeln. Diese weisen regelbasiert aus einem liebevoll vorbereiteten Service-Katalog das zu was passt. Ausnahmen von der Regel sind knifflig, nämlich dann wenn wöchentlich jemand wieder einen Schwellwert anders haben möchte. Genau dort wo wir’s nicht bedacht haben, dort wo Konstrukte mit vars am Host schnell hässlich werden.

Auch hier hilft der Director, mit den “Custom Variable Overrides” fühlt es sich so an als würde man wirklich diesem einen Service auf dem einen Host einen anderen Schwellwert verpassen. Alles gut soweit. Die Regeln sitzen, für Schwellwerte sind die Overrides da.

Nun ist unsere Welt aber leider nicht perfekt. Und das ist auch gut so, sonst wäre sie furchtbar langweilig. Für unsere Regeln bedeutet das leider, dass sie im Laufe der Zeit immer umfangreicher und komplizierter werden. Bis wir erneut an dem Punkt angelangen, an dem wir wieder am liebsten alles selbst machen würden. Wir haben nämlich Angst, dass es kaputt wird wenn es ein Kollege anpackt.
Klar, der Director hat ein wunderbares Aktivitätslog, man kann hinterher mit dem Finger auf eben diesen Kollegen zeigen und es heroisch selbst wieder geradebiegen. Ein Klick auf “Restore” hilft dabei. Aber wenn man sich dann allein dadurch besser fühlt, dann hat man charakterlich durchaus noch Möglichkeiten an sich selbst zu arbeiten.
Zudem gab es vorher unnötigen Stress. Über zwei Wochen ist niemandem aufgefallen, dass die Checks für einen wichtigen Job auf ein paar Servern verschwunden sind. Am Wochenende ist das Ding an die Wand gerannt, das Monitoring blieb stumm. Bemerkt hat’s der Kunde, und wir mussten uns mal wieder so doofe Sprüche wie “Ja habt ihr denn kein Monitoring?” anhören. Und alles nur, weil jemand mal wieder eine simple doppelte Verneinung falsch verstanden hat.
Mit dem Director v1.5.0 sind die häufigsten Ausnahmen von der Regel jetzt ein Kinderspiel. Man muss die Apply-Regel gar nicht mehr anfassen, einfach auf besagtem Host die Services anzeigen lassen, einen wählen, Blacklist, fertig:

Im Hintergrund rendert der Director passende Ignore-Regeln und alles ist gut. Man kann wieder einen Task mehr an seine Kollegen delegieren und sich um Wichtigere Dinge kümmern. Also den Raspberry der den Wasserstand der Kaffeemaschine im Auge behält. Was in der v1.5.0 sonst noch alles neu ist steht im Release-Blogpost des Icinga-Blogs.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Die Extrawurst

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.
Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.
[Jeder ist ein Mimimi]
add_groups = "Mimimi"

Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:
[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"

Sobald wir uns neu anmelden sind wir Mitglied der Gruppe “Mimimi” und sehen nur noch Hosts welche “mi” enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens “Mimimi” existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:
[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"

Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:
[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"

Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:
[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"

VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:
[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"

Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"

Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:
[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.
Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.
Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen “Linux Benutzer” und/oder “Unix Benutzer” in die Gruppe “Nagstamon Lokal” kommen. Alle außer dem admin:
[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"

[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"

[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"

Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.
Das war’s auch schon, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Der kleine Ping erkundet die Welt

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.
Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.
Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.
Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.
Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.
Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.
Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.
Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als “Prüfung des Maximalen Tunnel Umfangs”, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.
Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der “Ruhigen Inneren Polizei”, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.
Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!
Die richtig coolen Jungs hingegen arbeiteten bei der “Beindruckend Großen Polizei”, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.
Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.
Weiter so, lieber kleiner Ping!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Was gibt's Neues vom Director?

Gleich zwei neue Releases stehen an, und während die v1.3.2 bereits vor einer Woche inoffiziell getagged wurde, werden bei der v1.4.0 gerade noch die letzten Kanten rund geschliffen. Wenn nichts dazwischen kommt werden dann Anfang nächster Woche beide gemeinsam offiziell angekündigt werden.

Director v1.4.0 Dashboard

Director v1.4.0 Dashboard

Warum aber gleich zwei Releases auf einmal?

Director v1.4.0 versucht zwar, optisch möglichst nah an seinem Vorgänger zu bleiben, ist aber unter der Haube in großen Teilen komplett neu. In diesem Zuge haben wir die System-Anforderungen minimal erhöht, PHP 5.4 anstelle von PHP 5.3 ist jetzt vonnöten. Wer beste Performance und minimalen Ressourcenverbrauch schätzt, sollte auf 7.x wechseln.

Property Modifier "Combine"

Property Modifier “Combine”


PHP 5.4 sollte in allen aktiv von uns unterstützten Linux-Distributionen verfügbar sein, lediglich Nutzer von RHEL/CentOS 6.x müssten deren Konfiguration auf die in den offiziellen SCLs (Software Collections) vorhandenen Pakete umstellen. Das Standardverhalten beim Packaging von Icinga Web 2 werden wir vermutlich heuer noch entsprechend umbauen.
Property Modifier "Array Filter"

Property Modifier “Array Filter”


Für all jene, die jetzt auf die Schnelle nicht umstellen können/wollen ist die neue Version 1.3.2 gedacht. Diese enthält eine ganze Menge kleinerer und größerer Bugfixes, welche seit der 1.3.1 entstanden sind. Zudem haben wir ein paar neue nützliche Import Property Modifier einfließen lassen. Da sie am bestehenden Verhalten nichts ändern, durften sie gemeinsam mit ein paar neuen CLI-Befehlen mit in dieses Patch-Release:

Einfachere Suche, flexiblere Tabellen

Sämtliche Tabellen unterstützen intern zwar weiterhin unsere mächtigen Filter-Funktionen, stellen in der GUI aber vorerst nur noch ein einfaches Suchfeld bereit. Einfach testen, mehrere Wörter kombinieren, auch wenn diese in unterschiedlichen Spalten stecken – es sollte ziemlich intuitiv sein.
Beim Umbau der Tabellen sind neue generische Features entstanden. So konnten wir ohne großen Aufwand an mehreren Stellen historische Darstellungen säuberlich nach Tagen getrennt übersichtlicher gestalten.

Director Deployment History

Historie der Deployment


 

Template Choices

Der Director trennt strikt zwischen Objekten und Templates und erlaubt bestimmte Optionen nur an Templates. Das hat einen einfachen Grund: Templates sollen von Icinga-Admins betreut werden, “normale” Objekte (also Hosts und Services) sollen aber durchaus Systembetreuer nutzen dürfen, die sich nicht täglich um’s Monitoring kümmern. Alles was potentiell “gefährlich” sein kann wird aus dem Grund dort nicht angeboten.

Host Template Choices: Dashboard, Table

Host Template Choices: Dashboard, Tabelle


Nun ist es aber nicht gerade intuitiv, bei jedem zweiten Host zusätzlich ein Template namens “Schnelle Checks” einzubinden. Also erstellt man sich jetzt sogenannte Choices, gibt denen einen schönen Namen – und bietet sie auf diese Weise elegant im Formular an.
Template Choice in Action

Template Choices in Aktion


 

Schnelleres Arbeiten mit einzelnen Services

Die letzten Director-Releases kamen mit so einigen neuen Tricks. Gerade die “Variable Overrides” werden gern genutzt. Sie erlauben das Ändern von Schwellwerten für einzelne Hosts auch dann, wenn der zugehörige Service eigentlich via Apply-Rule erstellt wird.

Mehrere Services auswählen


Die Version 1.4.0 legt jetzt den Fokus auf schnelleres Arbeiten mit einzelnen Services. Neu ist eine Übersicht aller Einzel-Services auf allen Hosts. Von hier kann man mit SHIFT/STRG-Klick mehrere Services auswählen und gemeinsam anpassen. Oder löschen. Selbiges geht auch in die andere Richtung bei den Hosts: mehrere auswählen, Service oder Service Set hinzufügen, wählen, speichern:
Mehrere Services auf einmal bearbeiten

Mehrere Services auf einmal bearbeiten

Autocompletion

Neu an Board ist endlich ein Mechanismus zur Autovervollständigung. Dieser hat bereits so einige Dropdownfelder abgelöst und wird in Zukunft noch intensiv für weitere Aufgaben genutzt werden.

Autovervollständigung

Autovervollständigung


Gerade Formulare welche potentiell viele Objekte verknüpfen müssen, können wir damit jetzt schonend für den Browser umsetzen. Dependencies, Ein Punkt der schon lange auf der Wunschliste steht, kommen damit jetzt in Reichweite!

Neue Dashboards und Dashlets

Wie schon der Screenshot eingangs gezeigt hat: das Dashboard wurde umgestaltet und aufgeräumt. Die Tabs passen zu den Dashlets, wenn man umschaltet wird optisch hervorgehoben, wo man sich befindet. Aber nicht nur das, es kamen viele neue Unter-Dashboards hinzu. Und, neu in Kombination mit den Tabs: im Zweispalten-Modus macht ein Doppelklick auf den Tab-Titel jetzt die aktuelle Spalte “groß”.

Mobiles Director Dashboard

Mobiles Director Dashboard


Das Layout wurde übrigens für breitere Bildschirme auf ein 50/50 Spaltenverhältnis umgestellt, statt wie bisher 33/66. Sehr viele Verbesserungen gab es auch beim mobilen Layout. Dashboards sind dort jetzt angenehmer und auch die Formulare wurden für mobile Nutzung optimiert:
Formulare - mobile

Formulare – mobile

Vererbung ist alles

Bugs im Template-Baum wurden gefixt, und ganz neu ist eine Übersicht welche die Nutzung von Templates anzeigt:

Template-Baum

Template-Baum


Zudem werden Apply-Regeln für Hostgruppen jetzt voll aufgelöst und Gruppenmitglieder sowie der Typ der Mitgliedschaft (direkt oder via Apply) werden angezeigt.
Benutzung von Templates

Benutzung von Templates

Berechtigungen

Damit wären wir auch schon beim nächsten Thema. Das Auflösen von Vererbung und Apply-Regeln erlaubt uns jetzt endlich, entsprechende Restrictions freizugeben. Begonnen haben wir mit dem was einige unserer Kunden am dringendsten benötigt hatten. Hostgruppen, unterschiedliche Prefix-basierte Filter, sogar einzelne Einträge in Data Lists können jetzt nur für bestimmte Rollen freigegeben werden.

Genutzte Custom Variablen

Eher an Admins richtet sich ein neues Feature, das eine Übersicht aller benutzten Custom Variablen und deren Varianten anzeigen kann:

Übersicht Custom-Variablen

Übersicht Custom-Variablen


Genutzte Varianten einer bestimmten Variable

Genutzte Varianten einer bestimmten Variable


An dieser Stelle möchten wir in Zukunft noch die Möglichkeit anbieten, gleich an Ort und Stelle umfangreiche Massen-Changes und Aufräumarbeiten vornehmen zu können.
Stark überarbeitet wurde übrigens auch die Inspect-Funktionalität. Wer tiefer in den Core blicken möchte findet dort jetzt detaillierte Informationen zu den verfügbaren Eigenschaften und Methoden der unterschiedlichen Objekt-Typen. Auch der aktuelle Status der einzelnen Komponenten lässt sich abrufen, wenn auch noch nicht sehr schön formatiert.

VMware vSphere/ESXi Import

Diese Funktionalität wurde im Kundenauftrag als dediziertes Icinga Web 2 Modul entwickelt. Vorerst stellt es “nur” eine Import-Quelle für den Icinga-Director bereit. Wir haben damit aber noch so einiges vor. So möchten wir das Modul so aufbohren, dass es in einem kleinen eigenen DB-Schema ein Subset der in vSphere verfügbaren Informationen vorhält und ständig aktuell hält.

VMware vSphere Import

VMware vSphere Import


Festhalten wollen wir vor allem:

  • Welche VM mit welchen Eigenschaften seit wann wo läuft
  • Eine Historie der Migrationen
  • Ein paar wenige aggregierte aktuell Kennzahlen/Performancewerte

Diese Informationen möchten wir dann gleich mehrfach nutzen:

  • Für schnellere und schonendere Check-Plugins, da diese darauf verzichten können bei jedem Aufruf mit teuren API-Abfragen die benötigten Komponenten zu suchen
  • Für ein kleines Visualisierungsmodul
  • Um Zusatz-Informationen via Hook anderen Modulen in Icinga Web 2 bereitzustellen, in erste Linie natürlich dem zentralen Monitoring-Modul.

Bei der Entwicklung wurde auf sämtliche SDKs von VMware verzichtet. Mit selbigen hatten wir bisher keine guten Erfahrungen gesammelt. Probleme beim Upgrade, Inkompatibilitäten anderen Bibliotheken und/oder je nach Sprache auch einfach vollständiger Entwicklungsstillstand machten das Leben schwer.
Bei diesem Modul sind wir jetzt einen anderen Weg gegangen und nutzen zu 100% eigenem Code. Der deckt natürlich nicht die volle API ab – aber all das was wir brauchen. Damit fällt einiges an Overhead weg, und wir haben bei Bedarf die Möglichkeit viel flexibler auf Inkonsistenzen bei neuen Releases reagieren zu können. Wir sprechen direkt mit der SOAP-Schnittstelle und schaffen es damit, einen ziemlich breiten Bereich von vSphere- und ESXi-Versionen abdecken zu können. Für Nutzer des Moduls heißt das: runterladen, aktivieren, loslegen.
Es wird jedenfalls nicht langweilig. Und in diesem Sinne wünsche ich schon mal ein schönes Wochenende!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Icinga Director 1.2.0 veröffentlicht

Gerade mal 4 Monate sind seit eploer 1.1.0 vergangen, und wenig mehr als 7 Monate seit unserer ersten stabilen Release. Der Icinga Director reifte schnell, und aus einem kleinen Icinga Web 2 Modul ist mittlerweile ein ziemlich großes Projekt erwachsen. Gestern haben wir die Version 1.2.0 freigegeben, vollgestopft mit neuen Features, Bugfixes und Usability-Verbesserungen.

Berechtigungen

Dies ist die erste Release mit offizieller Unterstützung für Berechtigungen. Die Aufgabe eines Icinga-Administrator ist es, Commands, Service- und Host-Vorlagen zu definieren und eventuell alle Schritte von Import/Sync bis zum Deployment der Konfiguration zu automatisieren. Hier setzt der Director an, er ist zuallererst ein mächtiges Automatisierungstool.
Viele wenn nicht gar die meisten Umgebungen haben aber dennoch immer noch so einige Aufgaben die sich schwer automatisieren lassen. Wer kennt nicht den Mitarbeiter der sich zweimal am Tag umentscheidet, ob den nun der Schwellwert für seine seit Monaten volle Platte bei 99,9 oder doch besser bei 99,8% liegen soll. Stehen gerade 3000 neue Router an, die (nachdem jeweils ein Ticket erstellt wurde) im Laufe der nächsten Monate überwacht werden sollen? Diese Aufgaben sind prädestiniert dafür, an andere delegiert zu werden!
Audit log
Konfigurationsvorschau, Core API inspection oder das Auditlog können sensible Informationen beinhalten. Solcherlei Berechtigungen gibt man also besser nur denen, die sie wirklich brauchen. Soll ein Auditor alle Änderungen sehen aber keinen administrativen Zugang erhalten? Auch das ist jetzt möglich. Alle Aktivitäten lassen sich jetzt außerdem zusätzlich ins Syslog schreiben, für den Fall dass man es anderweitig archivieren möchte.
 

Performance

Das Rendern der Konfiguration wurde enorm beschleunigt. In großen Live-Umgebungen benötigt das Deployment nur noch ein Fünftel der ursprünglichen Zeit. Eine mir bekannte Umgebung konnte heute übrigens ihr tausendstes (automatisiertes) Director-basiertes Deployment feiern. Das Ganze bei mehr als einer halben Million Einzeländerungen im Aktivitätslog.
 

Konfigurationsmöglichkeiten

Es ist jetzt möglich tief verschachtelte Assign-Regeln zu definieren, basierend auf allen Host- und/oder Service-Eigenschaften. Wer das “apply for” Feature von Icinga 2 vermisst hat darf sich jetzt auch freuen. Ein Team von Internap hat einen Großteils des Codes dafür beigetragen. Bei dieser Gelegenheit herzlichen Dank für die gute Arbeit!
Die Unterstützung für Icinga 2 DSL in Command-Definitionen wurde verbessert. Ein Blick auf die Screenshots im Support-Ticket #12928 gibt einen kleinen Eindruck von den schrägen Möglichkeiten, die sich dadurch ergeben. Ein paar versteckte Features wie die implizite Unterstützung von skip_key fanden ebenfalls ihren Weg in die neue Version.
Nested filter with apply forDirector - Icinga DSL Cluster Check Override inherited service vars Apply-for - Preview
 
Wolltest Du immer schon eine bestimmte Eigenschaft eines von einem Host-Template geerbten Services für nur einen Host überschreiben? Dies und ähnliche Features sind jetzt verfügbar!
DNS - Property Modifier

Automatisierung

Beim Arbeiten mit der Import/Sync-Funktionalität lassen sich viele kleine Verbesserungen entdecken. Es gibt neue “Property-Modifier”, und deren Ergebnis lässt sich jetzt auch dafür verwenden neue virtuelle Eigenschaften zu erstellen. Wer mit Datenfeldern arbeitet wird neben Usability-Verbesserungen die Möglichkeit entdecken, andere Objekte in einer Dropdown-Liste bereitzustellen und als String oder Array in Custom-Variablen zu nutzen.
 

Testing

Immer mehr Entwickler tragen Quellcode zum Icinga Director bei. Um den Einstieg zu erleichtern haben wir das Bootstrapping unserer Unit-Tests vereinfacht und entsprechende Dokumentation bereitgestellt.
 

GUI und Usability

Die Fehlerbehandlung in den Formularen wurde stark verbessert, eventuelle Exceptions werden an vielen Stellen gefangen und auf lesbare Weise dargestellt. Der Deployment-Button ist jetzt nicht mehr so versteckt, die Konfigurationsvorschau wurde verbessert und erlaubt jetzt vollständige Konfigurations-Diffs auch vor dem Ausrollen einer neuen Konfiguration.
Loop detection Multiedit - imports Confirm field removal
 
Loops bei der Vererbung werden jetzt freundlich dargestellt und lassen sich direkt im Frontend beheben. Ein verstecktes Juwel ist die “Multi-Edit”-Funktionalität. Mit SHIFT/ALT+Klick lassen sich mehrere Hosts auswählen. Deren Imports, Custom-Variablen und andere Eigenschaften lassen sich an dieser Stelle für alle ausgewählten Objekte auf einmal ändern. Fehler oder Warnungen in allen historischen Startup-Logs verlinken jetzt direkt zur entsprechenden Konfigurationsdatei und springen an die richtige Zeile.
 

Verwandte Module

Es gibt mehr und mehr zusätzliche Module welche vom Director bereitgestellte Hooks implementieren. AWS-Import für EC2-Instanzen, ELBs und Autoscaling-Gruppen. Datei-Import für CSV, JSON, YAML und XML. Wir hörten von verschiedenen erfolgreichen Import-Source-Implementierungen in unterschiedlichen Projekten und würden uns sehr freuen, noch mehr davon als freie Software bereitgestellt entdecken zu dürfen!
 
Import from AWS Fileshipper - Import files
 

Download

Der Icinga Director v1.2.0 ist hier verfügbar, und das entsprechende GIT-Repository findet sich natürlich auf GitHub.
 

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Sehr erfreut, Herr Director

Ihr kennt mich vermutlich, ich bin die Lydia. Habe hier das Monitoring zu verantworten. Höre alles, sehe alles. Schreie laut und schrill, wenn Feuer am Dach ist. Damit mich auch wirklich alle hören. Naja, und neuerdings habe ich einen neuen Director.
Zuerst war ich mehr als skeptisch. Ich bin keine Frau die sich gerne was vorschreiben lässt. Aber er ist ein freundlicher Kerl, mein Herr Director. Ein kollegialer Chef möchte er sein, aber dennoch Herr über meine Arbeit. Überwachungsdirektor sozusagen. Ich muss ja zugeben, dass ich da anfangs so meine Zweifel hatte. Aber anders als der typische Chef schüttet er mich nicht mit Arbeit zu, nein, er macht sie mir sogar leichter.
Director Dashboard v1.1.0
Klar, er ist ein Kontrollfreak, der Herr Director. Will alles wissen, alles sehen. Wer wann was geändert hat, wo das her kam und warum – alles schreibt er mit. Ist natürlich auch irre praktisch, denn normalerweise hatten die immer mich im Verdacht. Bin im Hause ja die Frau Monitoring. Geht etwas daneben, war ich’s. Und ich darf dann nachgraben, wühlen, suchen um irgendwann rauszufinden wer den Change eingestellt hat. Finde ich nichts, hab ich eh verloren.
Das ist jetzt alles ganz anders. Sollen die ihre Schwellwertänderungen doch selbst vornehmen. Neue Hosts eintragen? Dafür braucht ihr doch mich nicht. Ich stelle die entsprechenden Templates bereit, aber von dem alltäglichen Änderungswahnsinn will ich nichts mehr wissen. Seit die selbst verantwortlich sind denken sie auch viel mehr über das nach, was sie da einstellen. Das gefällt mir.
Mittlerweile läuft es so gut, dass ich mich gar nicht mehr ums Deployment kümmere. Das machen die Laufburschen des Herrn Director still und leise im Hintergrund. Die könnten das zwar rund um die Uhr, aber so weit reicht mein Vertrauen dann doch nicht. Weniger in den Director, als vielmehr in meine Kollegen die jetzt jederzeit ihre schrägen Wünsche bei dem einkippen können. Hab ihm also eingetrichtert, dass Änderungen am Monitoring nur zu Bürozeiten ausgerollt werden sollen. Das heißt natürlich nicht vor der Mittagspause und auch nicht kurz vor Feierabend. Man muss sich ja nicht künstlich Arbeit beschaffen.
Meine ganzen alten Konfigurationsbastel-Skripte habe ich längst weggeworfen. Die verstand außer mir eh keiner. Diese Drecksarbeit macht jetzt auch der Herr Director. Der passt da auf wie ein Schießhund, schaut alle paar Minuten in unser Active Directory. Taucht da ein neuer Server auf, wird der sofort überwacht. Wird einer deaktiviert, fliegt er wieder raus. Schöne Sache.
Guter Mann, der Herr Director. In der neuen Version gefällt er mich noch besser. Der darf bleiben. Ich wollte eh mal wieder Urlaub machen.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

SSHave your Puppets!

SSHave your Puppets! - Slide 01Diese Woche fand wieder das Config Management Camp in Gent (Belgien) statt, und wir von Netways waren wie immer mit dabei. Bernd hatte bei seinem Vortrag über das APIfizierte Icinga2 natürlich volles Haus. Ich hingegen hatte beschlossen mich einmal an einem Ignite-Talk zu versuchen. Dabei hat man für 20 Slides exakt 5 Minuten Zeit, jede wird für 15 Sekunden angezeigt.
Weil das so einfach ist wie es klingt, das Ganze natürlich auch gleich noch auf Englisch. Der Aufwand für die Vorbereitung war dabei fast größer als bei einem “gewöhnlichen” Vortrag. Man muss sich nämlich ganz schön konkrete Gedanken darüber machen, was man zu den einzelnen Slides sagen möchte.
Mein Titel war SSHave your Puppets! Die Message die ich vermitteln wollte lautet “Lasst eure Werkzeuge für euch arbeiten, es darf nicht andersrum sein”. Wenn sie das nicht tun sollten: passt sie an oder werft sie weg.
Als konkretes Beispiel nahm ich den Versuch, Puppet über SSH laufen zu lassen. Also so richtig. Nicht bloß Katalog auschecken & puppet apply. Nein, als ernsthaften Ersatz, zentralisiert, samt Reporting und allem was ein Master so leisten kann. Das mag auf den einen befremdlich wirken, für den anderen ist es genau das wovon er immer geträumt hat.
SSHave your Puppets! - Slide 03Im Vortrag habe ich gezeigt dass es geht, und wie man so was erreichen kann. Aber darum ging es nur vordergründig. Was ich dem Zuschauer vermitteln wollte war, dass man gerade Open Source Software nicht immer so benutzen muss wie es alle machen. Best Practices? For Sissies. Zieht euch das raus, was ihr brauchen könnt. Nur das was euch hilft, und Zeit spart. Den Rest lasst weg, ersetzt ihn durch etwas Besseres. Oder biegt ihn einfach so um, dass er wieder zu euch und eurer Umgebung passt.
Sicherlich ist es keine gute Idee, aus Prinzip und immer dorthin zu laufen, wo die anderen nicht hinwollen. Aber habt ihr nicht auch manchmal das ungute Gefühl, dass irgendwas nicht so läuft wie es soll? Ihr versucht zwar alles richtig zu machen, es will sich aber kein zufriedenstellendes Erfolgserlebnis einstellen? Ihr fragt euch, wozu ihr euch den Quatsch überhaupt antut? Dann muss das nicht unbedingt an euch liegen!
Die Best Practices der Marktschreier aus der Cloud passen vielleicht einfach nicht zu eurer Umgebung. Doch wendet euch dann nicht gleich vollständig ab, irgendwas Wahres findet sich bei jeder Religion. Zieht euch aus den ganzen coolen Tools nur das raus, was euch hilft. Und der Rest? Darf weiterleben. Aber halt nicht bei euch in eurem Rechenzentrum!
SSHave your Puppets! - Slide 04SSHave your Puppets! - Slide 05  SSHave your Puppets! - Slide 08  SSHave your Puppets! - Slide 10 SSHave your Puppets! - Slide 19
 
 
Und wenn ihr dann vorsichtshalber doch noch eine zweite Meinung hören wollt, könnt ihr ja immer noch die coolen Jungs und Mädels von Netways zu Rate ziehen.
Also dann. Franken, Helau!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

OMG!!! It's a baby!

Monate in den Wehen, im Geburtskanal noch fünfmal gedreht. Dreimal davon nur um zu prüfen ob’s auch wirklich richtig liegt. Und jetzt, endlich, der erlösende Moment: Icinga Web 2.0.0 ist da!

Icinga Web 2 Login

Icinga Web 2 - Problems

Einfach muss es sein.

Wir sind angetreten mit dem Ziel, eine intuitive und selbsterklärende Anwendung als Frontend für das beste Monitoring-Tool der Welt zu schaffen. Essentielles sollte sofort sichtbar und alles weitere nur einen Klick entfernt sein. Das ist es, was Icinga Web 2 ausmacht.
Paradebeispiel hier ist das Dashboard. Gezeigt werden zuallererst Host- und Service-Probleme. Absteigend sortiert nach deren “Dringlichkeit”: zuoberst die neuesten kritischen Probleme, dann erst Unbekannte und Warnungen. Ein kritisches Problem welches schon bestätigt oder in Downtime gesetzt wurde ist aber dennoch lange nicht so wichtig wie eine Warnung, die noch keiner kennt.
 

Schnell muss es sein.

Deutsch

Icinga Web 2 ist leichtgewichtig und schnell. Wir haben bewusst auf die hippesten Frameworks verzichtet und so einiges selbst entwickelt. Viele Konzepte sind konservativ und neu zugleich. Und darum rennt und rennt und rennt es.
Finnisch

ItalienischMir san international

Netways steckt aus Überzeugung enorm viel Energie in das Icinga-Projekt. Doch gleichzeitig versuchen wir, im Hintergrund zu bleiben. Icinga ist ein Community-Projekt und soll das auch bleiben. Mit Entwicklern, Camps und Partnern auf der ganzen Welt verfolgen wir das Ziel, mit gesundem Tempo zu wachsen und ständig besser zu werden.
 

Modularität ist alles.

Der Gedanke, dass man etwas schaffen könnte um alle glücklich zu stimmen ist Illusion. Die Welt da draußen ist unendlich facettenreich. Jeder denkt anders, setzt andere Prioritäten. Unendlich viel habe ich schon gesehen, und dennoch erlebe ich fast jede Woche bei Kunden meinen ganz persönlichen AHA-Effekt. “Stimmt, so habe ich es noch gar nicht gesehen. Irgendwie schräg. Aber doch – daraus könnte man noch mehr machen!”
PortugiesischErweiterbarkeit ist darum eines der wichtigsten Credos bei Icinga Web 2. Möglichst einfach muss das sein. Und genau so einfach soll möglichst einfach sein, Icinga in eigene Projekte einzubinden.
 

Und jetzt?

Na was wohl, herunterladen (als Archiv oder Paket) und ausprobieren!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Hitzefrei

Das Blech vibriert, die Lüfter föhnen:
Hört doch, wie die Server stöhnen!
Würds’ hier ein Thermometer geben
Könnte man jetzt live erleben
Wie Zehnt um Zehnt die Säule steigt
Während’s längst schon rot anzeigt.
Ventilatoren quietschen, schleifen, scheuern,
Man müsst’ vielleicht ein paar erneuern.
Gepiepse, nervzerreißend sticht hervor,
Übertönt den jämmerlichen Lüfterchor.
Expertenmeinung: “Gar nicht gut,
Ich glaube irgendwo ist was kaputt”.
Die Experten sind nur grad nicht hier,
Ihr Freitag-Feierabend war um vier.
Ansonsten sieht man sie im Office schwitzen
Und nicht hier unten im Gedröhne sitzen.
Schreien Server noch bevor die Platte bricht,
Nützt’s nicht viel, man hört sie nicht.
So kommt es wie es kommen muss,
Groß das G’schrei und der Verdruss
Zwar läuft die Klima immer weiter
Auch die Chiller drehen heiter.
Dumm nur dass das Wasser steht,
Weil wer am falschen Hahn gedreht.
So kommt es wie es kommen muss,
Vom Head-Crash einen schönen Gruß.
And’re Server fahr’n sich runter,
Jetzt werden erste Admins munter
Denn das Smartphone meckert an,
Dass es keine Mails hol’n kann.
Schwer ist es jetzt zu ertragen
Wenn dann die Besserwisser sagen:
Mit Icinga wär das nicht passiert,
Du wärst beizeiten informiert.
Wüsstest welcher Server piept,
Wer wann warum den Geist aufgibt.
Auch würdest dich jetzt besser fühlen
Müsstest nicht nach Backups wühlen
Weil Bareos-Jobs nicht Handarbeit
Sondern Puppet-driven stets bereit
Auf jedem deiner Server laufen:
Du müsstest nie Lizenzen kaufen.
Das hast du alles? Wissen wir,
Schließlich bist ja Kunde hier.
Mit freier Software stets entspannt,
Wird Unheil frühzeitig erkannt.
Auch hast im Rechenzentrum Ohren,
Aus dem Netways-Shop sind die Sensoren.
In diesem Sinne, fröhlich heiter
Genieße ruhig die Sonne weiter.
Das Wochenend steht vor der Tür,
Ein kühles Bierchen gönne dir.
Leg dich hin und werd bedient,
Schließlich hast es dir verdient!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Alles Docker oder was?

Docker ist ein fantastisches Stück Software. Es ist immer wieder Thema bei unseren Konferenzen, wir bieten passende Workshops an, nutzen es selbst und bloggen darüber. Docker wirbelt seit einiger Zeit den Markt für Container richtig auf, auch wenn es erst mal unter der Haube nichts großartig Neues entwickelt hat. Docker nutzt in erster Linie Mechanismen die schon da sind, aber auf kreativ-konsequente Art und Weise. Durch seine Popularität trug und trägt es natürlich intensiv dazu bei, seine Grundbausteine zu verbessern. Docker nutzt alles was der Kernel so rund um Container bereitstellt und je nach persönlicher Vorliebe echte oder virtuelle Filesysteme, für die exzessives Erstellen von Snapshots per Design eh schon vorgesehen und damit nicht teuer ist. Du wolltest immer schon wie du das von der Software-Entwicklung kennst bei Bedarf nach jedem Handgriff einen “Commit” eines ganzen Servers? Docker könnte deine neue Liebe sein!
Du gehörst zu den Snapshot-Geschädigten, denen schon mal das sündhaft teure Storage-System dank Snapshot-Voodoo fast um die Ohren geflogen wäre? Bist geprägt von der erbärmlichen Performance von LVM-Snapshots? Keine Sorge, richtig gemacht sind auch tausende von Snapshots auf einem System heute kein Problem mehr. Klar, der Haken ist wie immer dieses “richtig gemacht”, aber da hilft Docker. Man hat out-of-the-box zwar keinen Ferrari, aber einen halbwegs aktuellen Diesel-Golf der zuverlässig ohne ohne zu murren dahintuckert. Wobei Tuckern keinesfalls im Sinne eines alten Traktors zu verstehen ist. Man kriegt mit Docker ohne ölverschmiert rumwerkeln zu müssen frei Haus zumindest einen richtig sportlichen GT oder dergleichen. Und wer sich die Hände schmutzig machen will kriegt das Ferrari-Pferdchen nicht nur als Aufkleber auf die Motorhaube sondern mit all seinen schnellen Freunden auch unter selbige.
Was ich absolut jedem empfehlen kann: eine Probefahrt! Schnapp dir Docker und probier es aus. Spiel damit! Wenn dir das Spielen allein keinen Spaß macht, dann komm zu einem unserer Workshops, gerne auch zur OSDC 2015, mit Gleichgesinnten macht es definitiv mehr Freude! Auch wenn es nicht das richtige Tool für dich ist – es erweitert definitiv den eigenen Horizont. Es tickt und “denkt” anders, als du das gewohnt bist. Warum es nicht das richtige Tool sein könnte? Weil sehr viele Anwendungen sich nur schwer so kapseln lassen, als dass sie mit Docker sofort Spaß machen würden. Ich kann zwar problemlos mit Docker vollwertige Systeme mit SSH, lokalem Mailer und allem was dazugehört betreiben – aber das ist eigentlich nicht im Sinne des Erfinders. Docker möchte nämlich je eine Applikation pro Container betreiben. Die meisten Applikationen sind dafür schlicht nicht ausgelegt. Wer jetzt also mal eben schnell seine Oracle-Datenbank in einen Docker-Container packen will, der wird sich schwer tun. Was nicht heißt dass es nicht geht, aber so war’s halt erst mal nicht gedacht.
Es ist gar nicht so einfach in wenigen Worten zu beschreiben, wie so eine “eigenständige” Applikation aussehen soll. Eine interessante Lektüre rund um dieses Thema bietet die Twelve-Factor App. Wenn deine Anwendung diese zwölf Punkte umsetzen kann stehen die Chancen gut, dass sie sich in einem Default-Docker-Container pudelwohl fühlt. Was nicht heißen muss, dass man jetzt all seine Anwendungen sofort umschreiben muss. Mit dem Thema beschäftigen sollte man sich auf alle Fälle, auch hier stehen die Chancen nämlich gut, dass man hinter der Cloud plötzlich wieder ein neues Stück Horizont entdeckt.
Docker setzt eine ganz neue Arbeitsweise voraus und nimmt damit Einfluss auf alles. Quer durch die Bank wird vom Testing über das Konfigurationsmanagement, vom Logging und Mail-Routing bis zum Monitoring alles durcheinandergewirbelt. Für den einen ist das der neue heilige Gral, der andere nutzt es nur um den durch automatisierte Tests generierten Overhead zu minimieren. Was ich aber ausnahmslos jedem ans Herz legen möchte sind die dem Prinzip von Docker zugrunde liegenden Techniken.
Egal ob mit Docker “so wie es sein soll”, ob mit zu System-Containern aufgeblasenen Docker-Containern oder gleich klassisch mit LXC, du solltest diese Werkzeuge kennen, nutzen und lieben lernen! Der Linux-Kernel stellt schon eine ganze Weile mächtige Komponenten zum Verwalten von Containern bereit. Und noch viel viel länger gibt es Kernel-Patches die ähnliches bieten konnten. Ich habe schon vor über 10 Jahren Container unter Linux in sensiblen Umgebungen produktiv einsetzen können und es nie bereut. Die laufen immer noch! Auf meinem Arbeits-Notebook lebt ein ganzer Zoo an internen LANs, Bridges, Firewalls und Containern. Wenn ich ein paar neue leere Debian-Container brauche, habe ich die in wenigen Sekunden am Laufen. Auch wenn ich offline bin. Cgroups erlauben es, Prozessgruppen gezielt zu isolieren und deren Resourcen-Nutzung fein granular zu steuern. Braucht nicht jeder, aber gut zu Wissen, dass es bei Bedarf möglich ist.
Und einen ganz speziellen Charme hat natürlich das ganze Snapshotting-Thema. Aber bevor ich dazu auch noch weiter aushole, was rede ich mir eigentlich den Mund fusselig? Probiert es einfach aus. Jetzt. Gleich. Oder geht doch lieber Skifahren.
Wünsche euch allen ein schönes Wochenende!!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.