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

This entry is part 7 of 7 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

Autor: Lennart Betz

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.

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part 1 of 3 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.

Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.

Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.

Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.

Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.

In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Fehlerkultur – Das Fundament für Innovation

Wer ab und an mal einen DevOpsDays-Event besucht oder einigen Galionsfiguren bei Twitter folgt, ist vermutlich schon über den Begriff Fehlerkultur gestolpert. Der Begriff ist im Grunde nicht neu und bereits seit den 70ern beschäftigt man sich mit der positiven Auswirkung einer vorhanden Fehlerkultur.

Was bedeutet Fehlerkultur

Etwas hemdsärmelig betrachtet würde ich sagen, dass es die Art und Weise beschreibt wie ein Gruppe bzw. Firma mit gemachten Fehlern, deren Kommunikation und möglichen Konsequenzen umgeht. Sprich die Reaktion auf Fehler, unabhängig davon ob die Mitarbeiter hierarchisch darüber, daneben oder darunter stehen. Das der Umgang mit Fehlern darüber hinaus auch abhängig von realen “Kulturen”, also Europäern oder bspw. Asiaten ist, ist ein Sachverhalt auf den ich nicht eingehe. Bei einer globalen Zusammenarbeit (haben wir kaum), ist er jedoch von großer Bedeutung und findet bei großen Unternehmen und deren HR-Abteilungen auch Beachtung.

Keiner macht gerne Fehler!

Fehler zu machen und dann auch noch zuzugeben schadet unserem Selbstwertgefühl. Somit ist es erstmal vollkommen “natürlich”, dass man sich mit einem “Sorry, ich habe es verkackt!” nicht wirklich wohl fühlt. Menschen mit einem sowieso schon geringen Selbstwertgefühlt fällt es umso schwererer eigene Unzulänglichkeiten zuzugeben und es verlangt ihnen viel Überwindung und Energie ab.

Das “hochhalten” des eigenen Selbstwertgefühls ist auch Basis für eine ganz bekannte kognitive Befangenheit, der Selbstwertdienlichen Verzerrung. So projizieren wir Misserfolge nahezu automatisch auf DIE ANDEREN und Erfolge auf uns selber. Jeder wird sich bei eigenem Scheitern schon mal dabei erwischt haben den Fehler, Ursache, oder besser die Wurzel allen Übels beim Kollegen oder Chef zu suchen. Für den Perfektionisten ist es dabei besonders schwierig Fehler zuzugeben. Da er im Vergleich zu anderen viel mehr Energie in Überlegung und Umsetzung s(eines) Projekts investiert hat, trifft ihn ein Scheitern und die eigene Einsicht darüber besonders hart.

Wie man man Menschen zur Fehlerkommunikation ertüchtigen?

Mit Sicherheit gibt es kein einfaches Erfolgsrezept um Menschen zur Kommunikation von Fehlern zu motivieren, aber es gibt durchaus einiges was mit im Team und Unternehmen dafür tun kann:

  • Gebt selbst Fehler zu
    Das bedeutet natürlich erstmal sich selbst zu überwinden und sich eigene Schwächen zuzugestehen. Persönlich ist mir dass vor vielen Jahren unglaublich schwer gefallen und ich war eher motiviert in tagelanger Nachtarbeit die gemachten Fehler zu “verschleiern”. Heute fällt es mir wesentlich leichter vor Kollegen und Mitarbeitern die eigenen Unzulänglichkeiten zuzugeben. Die Menschen um uns rum haben darüber hinaus meist eh ein besseres Gefühl darüber, als wir Ihnen zutrauen und die klassische Schuldverschiebung schwächt einen über die Zeit mehr als sie einem guttut. Vor einigen Tagen wurde ich bei einem Vortrag in Amsterdam gefragt “Gibt es Ding die Du heute anders machen würdest?”. Meine Antwort darauf: “Kann ich Dir eine Excel-Liste schicken?”
  • Versucht Probleme in der Gruppe zu analysieren
    Einer einzelnen Person fällt es aus genannten Gründen immer schwer die eigenen Unzulänglichkeiten zuzugeben. In der Gruppe verschwindet die Angst häufig und das Empfinden die Fehlerkonsequenz auch gemeinsam zu schultern nimmt dem Einzelnen den Druck. Klar ist, dass auch in der Gruppe jemand den Anfang machen muss, aber hat sich so ein Vorgehen einmal etabliert findet sich der- oder diejenige immer leichter.
  • Entwickeln sie Empathie und zeigen sie diese auch
    Das klingt jetzt natürlich einfacher als es ist, aber einige Denkmuster kann man sich schon zurechtlegen. Es ist wichtig anderen das Gefühl zu geben, das Fehler unabdingbar sind. Ist ein Fehler Resultat eines neuen Ansatzes oder des Versuchs Dinge zu verbessern, sollte man natürlich trotzdem kritisch über den Fehler sprechen. Umso mehr dann aber auch das Bestreben nach dem nächsten Versuch unterstützen und die Angst vor Fehlern nehmen.
    Aus der eigenen Perspektive ist es darüber hinaus wichtig, die eigene Unzufriedenheit über eine Situation zu äußern. Auch wenn Fehler gemacht werden und gemacht werden sollen, haben mögliche Fehlerauswirkungen auch Konsequenzen. Diese müssen den Beteiligen Personen dann aber auch klar sein und kommuniziert werden. Der Grat zwischen “Mach nichts falsch, denn sonst kostet es viel Geld” und “Versuch doch mal was Neues” ist definitiv schwierig, aber sonst könnte es ja jeder

Was bringt das alles?

Ich denke es ist wichtig sich selbst und auch allen anderen immer wieder klar zu machen, dass es ohne Fehler keine Innovation gibt. Wenn Menschen Angst vor dem Eingeständnis haben, sich in der Gruppe unwohl fühlen und der Chef sie im Meeting zusammenfaltet werden sie in der Regel alles tun um Fehler zu vermeiden. Ergo machen sie es wie “immer” und so bleibt eben dann auch alles wie es ist. Ich bezweifle stark, dass man eine solche Kultur einfach nur ein Meeting erzeugen kann, aber daran zu arbeiten und sich mögliche Konsequenzen vor Augen zu halten ist eine wichtige Selbstreflektion.

An mir selbst merke ich immer wieder, dass ich kein Problem mit einem Fehlerzugeständnis oder der Tatsache das etwas nicht funktioniert hat, habe.  Grantig macht es mich aber, wenn ich das unter den Teppich gekehrte dann doch herausbekomme ohne das es mir gesagt wird.

Und ich gehe gleich noch mit gutem Beispiel voran, der Blogpost sollte eigentlich um 11:00 raus. Ich habs verkackt! 🙂

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Ansible, so einfach!

Konfigurationsmanagement in Rechenzentren ist aus der modernen “DevOps” IT nicht mehr wegzudenken. Puppet, Chef, Salt oder Ansible automatisieren Umgebungen von mittelständischen Unternehmen bis hin zu Weltkonzernen.

Wenn wir die verschiedenen Lösungen betrachten, bedienen sie sich alle einer eigenen Sprache, diese soll möglichst einfach unsere Infrastruktur abbilden. (“infrastructure as a code”)
Da nicht jeder Admin im Tagesgeschäft programmiert, kann so eine Sprache ein Hindernis werden und Arbeitsschritte vielleicht verkomplizieren.

Seit einiger Zeit beschäftige ich mit Ansible, ein Tool welches ohne vorinstallierte Clients arbeitet und eine Konfiurationsprache basierend auf YAML nutzt.
Um Ansible zu nutzen muss lediglich eine SSH Verbindung, ein Benutzer mit Rootrechten und ein Inventarfile bestehen.
Das Sprache im YAML Format ist für jeden leicht lesbar und sofort verständlich.

Ansible kann entweder lokal auf dem Arbeitsrechner oder auf einem sogenannten “Managementnode” über bereitgestellte Pakete installiert werden.
Unter “/etc/ansible/” legen wir nach der Installation zusätzlich ein Inventar an.

$ cat /etc/ansible/hosts
host01.localdomain ansible_ssh_host=10.10.10.11
host02.localdomain ansible_ssh_host=10.10.10.12&lt;/pre lang="bash"&gt;

Wenn Ansible installiert und ein Inventarfile erstellt wurde, kann die Verbindung zum Server mit dem Modul “ping” getestet werden. Hierbei versucht Ansible den Server per SSH zu erreichen und einzuloggen.

$ ansible host01.localdomain -m ping
host01.localdomain | success &gt;&gt; {
"changed": false,
"ping": "pong"
}&lt;/pre lang="bash"&gt;

Alternativ kann statt dem Hostalias auch “all” gesetzt werden um alle Hosts aus dem Inventar zu prüfen.

$ ansible all -m ping&lt;/pre lang="bash"&gt;

Ansible bietet zahlreiche Module mit denen Pakete installiert, Dateien kopiert oder bearbeitet werden können. Hier findet ihr eine Übersicht aller Module
Tasks verwenden diese Module um die Arbeitsschritte in Playbooks oder Rollen auszuführen.

Beispiel eines Playbooks:

$ cat ansible_starter.yml
---
- hosts: all &lt;- Führe die Tasks auf allen Hosts aus
  tasks:
    - name: say hello to everyone &lt;- Name des Tasks
      debug:                      &lt;- Name des Moduls
        msg: "Hello World"        &lt;- Parameter des Moduls

– name: install ntp
yum:
name: ntp
state: installed
</pre lang=”yaml”>

$ ansible-playbook -s ansible_starter.yml
&lt;/pre lang="bash"&gt;
Diese Task werden der Reihenfolge nach auf dem Zielhost ausgeführt und damit haben wir schon eine kleine Automation geschaffen. Probiert's aus!

Da Ansible im Sturm mein Automationsherz erobern konnte war ich mit meinem Kollegen dieses Jahr auf dem Ansible Fest in London, einen Erfahrungsbericht der Veranstaltung findet ihr hier.

Thilo Wening

Autor: Thilo Wening

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Redis vs MongoDB as message queue and config proxy

Benchmarks and comparisons for these two NoSQL databases exist a plenty. But in all the blogs and whitepapers I found the use-case was quite different from ours, we were trying to find a tool to queue Icinga 2 events and speed up config updates. The queue would use Redis Pub/Sub or MongoDBs capped collections + tailable cursors. From an implementation standpoint MongoDB looks better, it offers good libraries for most programming languages and the document-based approach allows for filtering based on individual attributes while values in Redis are just opaque blobs. Redis Pub/Sub model also has the problem that it loses its queued items when restarted.

From these naive benchmarks (PHP scripts run with time), it looks like MongoDB likes to take their time with creating objects.

Inserting 250.000 objects:

  • Redis: 11.1s
  • MongoDB: InsertOne: 53.3s
  • MongoDB: InsertMany: 25.4s

Inserting 250.000 objects into list capped to 50.000

  • Redis: 12s
  • MongoDB: InsertOne: 57.6s

Redis speed advantage comes from keeping created objects in memory, while MongoDB writes them to the hard drive right away. This is a huge advantage for Redis, as we rotate our events from the queue, writing them to disk would be a waste of io time. But sadly MongoDB does not offer the possibility of keeping the data volatile in memory.

Another concern of ours is security, Redis does not offer any security features and for many application this is not a problem, but in our case, this means we have to finds ways to make it secure. There have been many attempts to do so, e.g using tools like stunnel, but it’s still an additional topic that would need to be tackled. MongoDB on the other hand offers ACLs on document level and native SSL, which is great! Yet is has been rightfully criticized for its insecure default configurations, which resulted in a flood of hacked MongoDB instances earlier this year.

Conclusion: We will have to investigate further. Especially integration and security will need a closer look. MongoDBs performance seems lackluster, but may just be enough as our tests may have been much bigger than what we will be met with in a real setup.

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

AnsibleFest London

Thilo, mein alter Azubi Kollege, und ich haben dieses Jahr das erste mal am AnsibleFest in London teilgenommen. Ziel davon war es, den Blickwinkel zu erweitern und zu sehen, welche Möglichkeiten es mit Ansible gibt und wie sie von anderen Unternehmen ausgeschöpft werden.
Die Unternehmen, die Vorträge gehalte oder an Interviews teilgenommen haben, erstrecken sich von Siemens, über Ansible selbst bis hin zur britischen Armee. Mich hat sehr erstaunt, dass sogar die britische Armee Ansible im produktiven Einsatz hat und dann auch einen Talk darüber abhält!

Das Ambiente war sehr vornehm. Die Veranstaltung fand im “InterContinental London” statt. Wie wir es von NETWAYS Veranstaltungen schon gewohnt sind, gab es reichlich zu Essen und zu Trinken, was uns nach der etwas längeren Anreise, doch zu Gute kam.

Als OpenSource Firma kommen wir bei NETWAYS immer mehr in Kontakt mit dem Configuration Management Tool Ansible. Bereits die ersten Kunden sind auf uns, eben wegen Ansible zugekommen und haben in Zusammenarbeit mit uns ihr Setup aufgebaut. Die Verwaltung der Produktivsysteme läuft demnach mit Ansible und diese Konfigurationen sind sowohl für uns als Administratoren als auch für den Kunden selbst mittels Git zugänglich. Falls auch ihr euch überlegt, eure Systeme mit Ansible zu verwalten, dann kommt gerne auf uns zu! Wir helfen gerne.

Zum Abschluss sind hier noch Bilder vom Hotel sowie von der Anreise hinterlegt.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz