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</pre lang="bash">

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 >> {
"changed": false,
"ping": "pong"
}</pre lang="bash">

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

$ ansible all -m ping</pre lang="bash">

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 <- Führe die Tasks auf allen Hosts aus
  tasks:
    - name: say hello to everyone <- Name des Tasks
      debug:                      <- Name des Moduls
        msg: "Hello World"        <- Parameter des Moduls

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

$ ansible-playbook -s ansible_starter.yml
</pre lang="bash">
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
Thilo Wening
Senior Consultant

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.

Braintower Gateways erben iSMS Features

braintower_logo Seit vielen Jahren setzen wir im Bereich SMS Alarmierung für Icinga sehr erfolgreich auf das MultiTech iSMS.
Neben der sehr simplen Einrichtung, der Netzwerkanbindungsmöglichkeit und dem Versenden von SMS über die Weboberfläche, bietet das Gerät eine HTTP-Schnittstelle für den Versand von SMS. Dadurch wird eine Integration in Monitoring Lösungen um ein vielfaches einfacher. Als weitere Option bietet das Gerät die Möglichkeit eingehende SMS an einen Webserver weiterzuleiten, was es in unserem Fall erlaubt, Alarmmeldungen von Icinga 2 mit einer simplen Antwort SMS zu Acknowledgen.
Für die Braintower Gateways gibt es seit letzter Woche die neue Firmware Version 3.3.0, welche das Gateway um einige interessante Funktionen erweitert. Eines dieser Features ist das SMS Routing, mit welchem SMS Nachrichten per Mail, SMS oder per Web-Call weitergereicht werden können.
Darüber hinaus wurde die API-Funktion des Gateways erweitert und ist nun vollständig kompatibel zu der MultiTech iSMS API. Wer bisher also ein iSMS sein eigen nennt, kann ohne Probleme auf ein Braintower Gateway umsteigen. Eine Erweiterung der Basis-Funktion (welche die API-Kompatibilität bereits inkludiert), ist über eine Vielzahl von Zusatz-Features möglich. Sofern das Gateway identisch eingerichtet wird (Benutzer, IP, etc.), kann eine nahtlose Alarmierung erfolgen – ohne Anpassungen an Skripten oder Software durchführen zu müssen.
Darüber hinaus ist unser iSMS Notification Plugin mit dem SMS Routing Feature zu 100% kompatibel mit Braintower. Somit ist nun neben einer Alarmierung auch ein Acknowledgen von Alarmmeldungen in Icinga möglich.
Übrigens: Wer bereits ein Braintower-Gateway mit dem SMS-Weiterleitungs-Feature erworben hat, kann ein Upgrade für das SMS Routing direkt nachkaufen.
Da wir auch immer wieder einmal diverse Kunden-Anfragen zum Thema GFI FaxMaker erhalten, ob wir passende Gateways anbieten können, ist die Antwort simpel: Ja!
Offiziell supportet wird seitens des Herstellers das MultiTech iSMS. Mit dem neuen Firmware-Update werden nun auch Braintower Gateways unterstützt.
Anbei noch ein kurzer Überblick zu den Änderungen zu Version 3.3.0:
Verbesserungen
[SMSGW-546] – Es ist möglich, die Scripts sendsms.pl und smsack.cgi aus dem NETWAYS iSMS Nagios / Icinga Plugin zu verwenden.
[SMSGW-606] – Es wurde eine Dokumentation zum Ersetzen von Geräten anderer Hersteller durch das Braintower SMS Gateway hinzugefügt.
[SMSGW-618] – Das Gateway ist zusätzlich auf Port 81 erreichbar.
[SMSGW-597] – Das Nachrichten-Routing kann nun Nachrichten auch an Ziele per HTTP weiterleiten.
[SMSGW-608] – HTTP-Ziele beim Nachrichten-Routing sind nun editierbar.
[SMSGW-612] – Es ist möglich, mehr als ein HTTP-Ziel pro Regel beim Nachrichten-Routing zu konfigurieren.
[SMSGW-624] – HTTP-Ziele sind bei Nachrichten-Routing auch auf eingehende Emails anwendbar.
[SMSGW-627] – Im Nachrichten-Routing wird nun ein Hinweis angezeigt, wenn kein SMTP Server konfiguriert wurde.
[SMSGW-634] – Das Feature Nachrichten-Routing kann nun kostenpflichtig lizenziert werden.
[SMSGW-607] – Das Feature SMS Weiterleitung ist nun Bestandteil des Nachrichten-Routings, jedoch mit verringerter Funktionalität. Kunden, die das Feature SMS Weiterleitung lizenziert haben, können eine Upgrade-Lizenz zur Nutzung des Nachrichten-Routings erwerben.
[SMSGW-619] – Die Gestaltung der Weboberfläche wurde verbessert.
[SMSGW-675] – Es wurden zahlreiche Übersetzungen verbessert.
[SMSGW-623] – Die Regeln zur Überprüfung gültiger Rufnummern bei der HTTP API wurden erweitert.
[SMSGW-641] – Es wurden neuen FAQ Artikel hinzugefügt (Syslog, API per HTTPS, SIM Karten Formfaktor, Einbindung in Centreon, Icinga 2 und WhatsUp Gold, Import und Export des Adressbuchs, Technische Daten).
Fehlerbehebungen
[SMSGW-604] – Beim Nachrichten-Routing wird die konfigurierte Absenderadresse nun korrekt gesetzt.
[SMSGW-614] – Die Whitelist der E-Mail-to-SMS Funktionalität wurde korrigiert.
[SMSGW-616] – Der Suchen und Ersetzen Bereich beim Nachrichten-Routing wird nicht mehr doppelt angezeigt.
[SMSGW-617] – Die E-Mail-Gruppen-Benachrichtigung beim Nachrichten-Routing wurde korrigiert.
[SMSGW-622] – Bei E-Mail-zu-SMS wurde die fehlende Online-Hilfe ergänzt.
[SMSGW-615] – Die Produktbezeichnung in Benachrichtigungs-Emails wurde korrigiert.
[SMSGW-628] – Nachrichten wurden teilweise sowohl über Email-zu-SMS als auch über das Nachrichten-Routing versendet.
Sie haben Interesse an unseren angebotenen Produkten oder wünschen eine Beratung? Nehmen Sie einfach direkt Kontakt mit uns auf oder besuchen Sie unseren Online-Shop für weitere Informationen. Wir stehen Ihnen gerne zur Verfügung!

Christian Stein
Christian Stein
Lead Senior Account Manager

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

Reminder für das Puppet Webinar – Windows Configuration Management

puppet Heute will ich noch mal auf das Webinar zum Thema Puppet: Windows Configuration Management am Freitag, den 12.12.2014 um 10:30 Uhr hinweisen. Gemeinsam mit Dirk werde ich demonstrieren, wie man Windows-Systeme mit Puppet deployen und konfigurieren kann.
Wer hieran teilnemhen möchte, kann sich natürlich gerne registrieren.
Um die Zeit zu überbrücken, kann man sich auch gerne die Webinar-Videos in unserem Webinar-Archiv anschauen.
Bis Freitag!

Christian Stein
Christian Stein
Lead Senior Account Manager

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

Reminder für das Icinga Web 2 Webinar

icinga_logo_200x69 Heute einmal früher als sonst möchte ich auf das Icinga Web 2 Webinar aufmerksam machen, welches bereits nächste Woche Dientag, den 25. November 2014 um 10:30 Uhr stattfindet. Wer daran teilnehmen möchte, kann sich natürlich gerne noch registrieren.
Inhalte werden vor allem die Neuerungen seit dem letzten Webinar sein sowie der Installer und verschiedene Module.
Diejenigen die diese Woche an der OSMC und sogar am Workshop ‘Extending Icinga Web 2’ teilnehmen, haben natürlich während unseres Webinars noch einmal die Gelegenheit sich alles in Ruhe zeigen zu lassen. Wie immer freuen wir uns natürlich auf eine rege Teilnahme und viel konstruktives Feedback.
Wem die Wartezeit zu lange ist, der kann sich natürlich in unserem Webinar-Archiv das ein oder andere vergangene Webinar-Video noch anschauen.
Vielleicht sieht man sich diese Woche auf der Konferenz – ansonsten hört man sich spätestens nächste Woche Dienstag!

Christian Stein
Christian Stein
Lead Senior Account Manager

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

Parametrisierte Klassen mit Foreman

Wenn in den Einstellungen Parametrized_Classes_in_ENC für Puppet auf true gesetzt ist, unterstützt Foreman parametrisierte Klassen. Weitere Grundvoraussetzung ist außerdem das Foreman einen Puppetmaster als Smart Proxy angebunden hat und auf dessen Puppetmodule zugreifen kann.
Somit können die Puppet Klassen vom Puppetmaster importiert werden:
Bildschirmfoto vom 2014-04-28 07:23:03
Innerhalb einer Klasse kann Foreman sich bei den Parametern dann über die Klassenvorgabe hinwegsetzen (= “Override”). Wie im folgenden Beispiel anhand der Klasse ntp mit dem Parameter servers gezeigt, empfiehlt es sich entsprechende Standardvorgaben zu setzen:
Bildschirmfoto vom 2014-04-28 07:38:03
Ergänzend dazu können für einzelne Hosts über FQDN, Hostgruppe oder anderen Kriterien abweichende Werte festgelegt werden. Foreman bietet dazu an verschiedenen Stellen des Webinterfaces Möglichkeiten dies zu tun.
Bildschirmfoto vom 2014-04-28 07:45:41
Nebenan ein exemplarisches Beispiel für geänderte NTP-Server innerhalb der Puppet Klasse.
Hier werden für die Hostgruppen CentOS und Debian abweichende Werte hinterlegt. Bei Systemen die keine Zuordnung zu den beiden Hostgruppen haben, greift die zuvor gesetzte Standardvorgabe.
Wichtig ist zudem das die jeweilige Puppet Klasse den entsprechenden Hosts auch zugewiesen wird. Auch dies kann bei Foreman an verschiedenen Stellen, z.B. direkt im Host oder der Hostgruppe, erfolgen.
Mit parametrisierten Klassen über Foreman ist es somit möglich individuelle Konfigurationen unabhängig von site.pp & Co. zu definieren und diese an zentraler Stelle übersichtlich zu verwalten.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Icinga 2 Entwicklungsstand 2014 – Webinar Reminder

logo_icinga3Morgen früh um 10:30 Uhr beginnt das letzte Webinar vor der CeBIT. Diesmal wollen wir auf das neue Icinga 2 eingehen und alle bisher vorgenommenen Änderungen der Milestones ansprechen.
Im Webinar werden wir einige Grundkonfigurationen kennenlernen, bis hin zur Einrichtung eines Clusters von zwei Nodes. Natürlich wollen wir im selben Schritt auf einige Unterschiede zu Nagios / Icinga eingehen und die Roadmap für Version 0.0.8 präsentieren.
Wer noch daran teilnehmen möchte, kann sich über unsere Webinarseite registrieren.
Eine Aufzeichnung des Webinars und die gezeigte Präsentation wird anschließend in unserem Webinar-Archiv online gestellt.
Cebit BlogWer Icinga 2 näher betrachten möchte, kann sich entweder über unser Kontaktformular bei uns melden oder uns auf der CeBIT im Open Source Park, Halle 6, an Stand E16 (310) besuchen. Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.
Bis morgen im Webinar!

Christian Stein
Christian Stein
Lead Senior Account Manager

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