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
&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.

Mein Praktikum bei Netways – Thorben

//Im Namen von Thorben

Erstmal vorweg, ich bin Thorben, 16 Jahre alt und besuche zur zeit das Europa Gymnasium in Gommern (Sachsen-Anhalt, nähe Magdeburg) in der 10. Klasse. Wir hatten die Ankündigung zum Praktikum bekommen und ich wollte irgendwas in Richtung IT machen. Da war es natürlich super, dass ich Ronny Biering kenne, der hier bei Netways arbeitet, über welchem ich dann auch den Kontakt und das Praktikum mit und bei Netways bekam. Nun sollte meine Praktikumsstelle 2 Wochen lang bei Netways sein, was mich echt freute.

Es fing klassisch mit dem Vorstellen jedes Mitarbeiters dieser Firma an und auch mit der Einweisung bei der Kaffeemaschine (wichtigster Mitarbeiter) :). Ich lernte Tim kennen, welcher fortlaufend, neben Sebastian, mein Betreuer des Praktikums sein sollte. Er erklärte mir grob Dinge über die 2 Wochen hier bei Netways und zeigte mir auch diverse Bereiche, wie auch das Rechenzentrum. Meine erste Aufgabe war testweise einen Raspberry PI zum laufen zu bringen und ihm im Anschluss mit dem Netways Dashboard zu versehen. Das ganze wiederholte ich 3 mal, bis ich dann auch schneller als es Tim lieb war, fertig wurde.
Markus Frosch hatte noch einen Vortrag über Passwörter im allgemeinen und über die Benutzung mit Enpass gehalten. Es war recht informativ, sodass ich dieses Programm auch zuhause verwenden werde. Danke dafür.
Danach sollte ich WordPress mit einer Mysql-Datenbank einrichten, womit ich jetzt auch erfolgreich einen eigenen Blog habe. Als auch dies fertig war, „durfte“ ich dann auch die Netzwerk Anschlüsse protokollieren und dann im Anschluss auch die Notebooks der neu ankommenden Praktikanten mit CentOS aufsetzen. Zwischendrin war ich auch im Lager und habe den Bereich mit den Lan Kabeln aufgeräumt und fein säuberlich nach Farbe sortiert. Zur zeit beschäftige ich mich neben dem Blog hier mit dem erledigen einiger Aufgaben, wie einen eigenen Passwort Generator oder auch die Buchstabenhäufigkeit per Bash zu ermitteln. Zum Abschluss bekam ich die Aufgabe, eine html-Seite mit eingebundenen Bildern zu erstellen.

Damit sind meine 2 Wochen Praktikum hier bei Netways auch fast um und ich kann getrost sagen, es war kein Fehler dieses hier zu absolvieren. Ich bekam einen für mich recht großen Einblick in die Shell Oberfläche, da ich nur 2 Jahre mit Delphi zu tun hatte. Im Gegensatz zu Delphi versteh ich jetzt wenigstens mal ein paar Dinge im Bereich der Befehle, womit es im Endeffekt auch Spaß macht die Shell zu benutzen. Auch die Firma an sich ist für mich eine positive Erfahrung in Hinsicht der Hilfe und auch dem Zusammenhalt unter den Mitarbeitern. Und auch Tim, welcher immer ein Ohr für meine Fragen offen hat.

Clustershell und Foreman-API

i-love-apisForeman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells “csshX” im Einsatz, welches ich auch direkt mit eingebunden habe.

Das get_hosts Script gibt es als GIST.

In diesem Script wird zunächst eine “config.yml” geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter “-s / –server” gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.

Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)

Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: “Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?”
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.

user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully

Wie bereits erwähnt, ist hierfür noch eine “config.yml” Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem “bundle install” können diese installiert werden)

Die config.yml und das Gemfile gibt es ebenfalls als GIST.

Eingebaute “rescue Execptions” im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

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

“Multiline” mit Filebeat

simplimages

Das analysieren von Logs mit dem ELK-Stack ist an sich relativ simpel. Ein Problem auf das man hierbei stoßen kann, sind jedoch Logeinträge aus mehreren Zeilen bestehen (“Multiline”).  Das Problem hierbei ist, das Logstash jede dieser Zeilen als einzelne Events versteht und verarbeitet, wodurch das Kibana sehr schnell unübersichtlich werden kann.
Wenn man hierzu etwas recherchiert, kommt man sehr schnell auf eine “Lösung” die wie folgt aussieht:

filter {
multiline {
type => "type"
pattern => "regexpattern"
negate => boolean
what => "previous" or "next"
}
}

Mit dieser Methode, wird am Logstash ein Filter angelegt, der “multiline” erkennt und diese anhand von Regexpattern zusammenfügt. Erfahrungsgemäß funktioniert dies jedoch nicht immer wie gewünscht. Eine wesentlich bessere Methode ist meiner Meinung nach, direkt am Client anzusetzen, der die Logs verschickt. Hierzu kann ich den Einsatz von Filebeat empfehlen.

Die Installation ist sehr simpel:
curl -L -O https://download.elastic.co/beats/filebeat/filebeat_1.3.1_amd64.deb
sudo dpkg -i filebeat_1.3.1_amd64.deb

Alternativ, kann man natürlich auch die Apt-Source mit dem entsprechenden Key lokal hinzufügen und mit dem Paketmanager arbeiten. Nach der Installation steht die Konfiguration aus. Die dafür zuständige Datei ist “/etc/filebeat/filebeat.yml”. Die ist zwar dank vielen Kommentaren sehr lang, doch das wesentliche sieht in einem Beispiel wie folgt aus:

filebeat:
prospectors:
-
paths:
- /var/log/my_multiline_1/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
-
paths:
- /var/log/my_multiline_2/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
registry_file: /var/lib/filebeat/registry
######
output:
logstash:
hosts: ["$IP_OF_LOGSTASH:$INPUT_PORT"]
######
logging:
files:
rotateeverybytes: 10485760 # = 10MB

Hierbei werden für verschiedene Logs verschiedene “Prospectors” konfiguriert. Hierzu sind lediglich Informationen über den “input_type”, den Regexpattern nötig und eine Art und Weise wie Logs zusammengefügt werden sollen nötig. In diesem Beispiel würden alle Zeilen, auf die der Regexpattern nicht zutrifft, an die Zeile angefügt, auf die der Regexpattern zutrifft. Mit jeder Änderung am Filebeat, muss der dienst neu gestartet werden.

Damit Logstash aber auch zusätzlich Daten von der neuen Quelle “Filebeat” annimmt und verarbeitet, muss ein neuer “Input” und “Output” definiert werden.

input {
beats {
port => $INPUT_PORT
}
}
output {
redis {
data_type => "list"
key => "logstash"
}
}

Auch hier muss der Logstash natürlich neu gestartet werden. Anschließend können die zusammengefügten Logeinträge im Kibana unter die Lupe genommen werden und im Logstash weiter zerlegt werden.

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

Icinga2 & LSW

Ich musste feststellen das man mit dem Linux Subsystem for Windows auch Icinga2 + Icingaweb2 auch zum laufen bringen kann auf einem Windows.

Also hier mein kleiner Erfahrungsbericht:

Es galt erstmal heraus zufinden welches Ubuntu in dem Subsystem verwendet wird.

Dazu verwenden wir folgendes Kommando:

# lsb_release -a

selection_019

Nun installieren wir erstmal Updates:

# sudo -i && apt-get update
gefolgt von eurem PW und dann dem Update:

selection_020

Als nächstes installieren wir das Icinga2 Repo fuer die anstehende installation von Icinga2.

# add-apt-repository ppa:formorer/icinga && apt-get update

selection_022

Nun legen wir mit der Datenbank los:

# apt-get install mariadb-server mariadb-client -y

Es muss hiernach das Passwort für den MySQL Root Benutzer angelegt werden.

# /etc/init.d/mysql start
# mysql_secure_installation

Login zu Mariadb:

# mysql -p
Anlegen der Icinga-IDO Datenbank:

selection_027

# create database icinga;
Festlegen des IDO Benutzers:

# grant all on icinga.* to 'icinga'@'localhost' identified by 'icinga';
# apt-get install nagios-plugins-all -y

Damit haben wir die Plugin-Checks installiert aber es fehlt uns noch der Webserver :

Dem widmen wir uns nun :

# apt-get install apache2
gefolgt von der simplen installation von icinga2;

# apt-get install icinga2

selection_031

Wir starten nun erstmal den Icinga2 Service:

# /etc/init.d/icinga2 start
Nun brauchen wir natuerlich auch den Rest 🙂

# apt-get install icingaweb2 icingacli icinga2-ido-mysql
Nach dem die Installation durchgelaufen ist editieren wir erstmal die IDO Konfig Datei:

selection_034

# vi /etc/icinga2/features-enabled/ido-mysql.conf
und kommentieren alle wichtigen eintraege ein und ändern Sie ggf. ab.

Wir müssen auch noch die die php.ini editieren:

# vi /etc/php5/apache2/php.ini
Wir suchen darin nach date.timzezone und tragen hier eine Sinnvolle Zeitzone ein.

apt-get install php5-gd php5-imagick

gefolgt von :

# /etc/init.d/httpd restart
Auch ein enablen der Commandpipe ist notwendig:

# icinga2 feature enable command
Fuer das Webfrontend benoetigen wir einen setup token

# icingacli setup token create
Der Webserver läuft schon , wir oeffen im Edge die folgende adresse https://127.0.0.1/icingaweb2/setup

und benutzen den angeforderten Token.

Wir fuellen das Setup Sinnvoll aus 🙂

Ausserdem muss ggf. die iptables firewall eingetragen werden:

# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

selection_054

Und erhalten zum Schluß ein laufendes Icinga2 welches im LSW installiert ist.

Ich hoffe ihr hattet bischen Spaß beim dem nachvollziehen oder nachbauen.

Ich freue mich über Feedback jeglicher Art.

Gruß

David

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte.

Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Wissenstransfer bei NETWAYS

Social education communication concept

Oft hat man das Problem, dass Kollegen aus unterschiedlichen Abteilungen bei Gesprächen, nicht nachvollziehen können, über was der jeweils andere redet. Verdutzte Gesichter und Ratlosigkeit gerade aus Abteilungen die wenig mit Technik zu tun haben – kamen vor.  Eine Möglichkeit eben jenem Problem vorzubeugen und das Verständnis der Mitarbeiter zu erweitern, sind Wissenstransfers innerhalb einer Firma. Es wird Wissen über Technik, kaufmännische Themen oder organisatorische Themen ausgetauscht und so der Horizont der Teilnehmer erweitert.

Um eben dies zu erreichen, haben wir bei uns diverse interne Schulungen eingeführt. Diese Schulungen dienen zum einem eben dem Wissenstransfer, aber auch dem Crashkurs neuer Kollegen oder Azubis.
Allein in dieser Woche hatten wir hierzu 2 Schulungen. Eine zweitägige Veranstaltung wurde mit dem Thema “Linux” versehen, in der alle Teilnehmer in den Grundkenntnissen im Umgang  mit einem Linuxsystem geschult wurden, sowie eine eintägige Schulung für die Neuankömmlinge. Thema hier waren sämtliche Tools, interne Workflows und alles Wissenswerte über unser Produkt-Portfolio.

Das Konzept dieser Transfers erfreut sich intern großer Beliebtheit. Kollegen aus “Events&Marketing” aber auch aus Sales, sind beispielsweise nun in der Lage, in vereinfachter Weise mit Linux umzugehen oder gar bei Gesprächen der Kollegen mitzuwirken. Andersherum verstehen die Kollegen aus “Managed Services” Probleme der anderen Abteilungen besser.

Diese Schulungen tragen somit auch wesentlich dazu bei, die Kommunikation intern zu verbessern und auf Probleme andere besser eingehen zu können.

crvcq9hwyaaodyf crqspfaxyaa94zo

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