Seite wählen

NETWAYS Blog

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
Manager Consulting

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.

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

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.

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

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
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
David Okon
Senior Systems Engineer

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.