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.

Icinga2 API und BitBar auf MacOs

preview1Wir wollen APIs, warum? Weil sie schnell, einfach zu integrieren und zu bedienen sind. Nun hat Icinga2 eine API und es entstehen ganz viele Möglichkeiten diese zu nutzen. Wir bauen uns Dashboards mit Dashing oder zeigen den Status von Hosts in Foreman an.

Ich bin letztens über ein Tool BitBar gestolpert, dieses Tool kann mit einfachen Skripten die eigene “Mac OS X menu bar” erweitern. Hierfür braucht es nur die richtige Formatierung der Ausgabe und BitBar generiert ein weiteres Dropdown Menu.

Ich hab mir die Icinga2 API zu nutze gemacht und eine kleine Erweiterung gebaut um mir den Status von Icinga2 in meiner Menubar anzuzeigen.
Im Menu wird dann der globale Status entweder in grün oder rot, abhängig davon ob Hosts “down” und “unhandled” sind, angezeigt.
Der Aufruf dafür kann der Adresszeile im Browser entnommen werden.
/icingaweb2/monitoring/list/hosts?host_state=1&sort=host_severity&host_unhandled=1

Wenn wir am Ende dann ein “&format=json” an die URL hängen, haben wir ein gängiges Format um das Ergebnis in jeglichen Applikationen zu verwenden.
[{"host_icon_image":"","host_icon_image_alt":"","host_name":"web01","host_display_name":"web01","host_state":"1","host_acknowledged":"0","host_output":"DOWN","host_attempt":"1\/3","host_in_downtime":"0","host_is_flapping":"0","host_state_type":"1","host_handled":"0","host_last_state_change":"1474556541","host_notifications_enabled":"1","host_active_checks_enabled":"0","host_passive_checks_enabled":"1"},

Mehr dazu gibts auf Github unter icinga2_api_examples oder natürlich in der Icinga2 Dokumentation.

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.

Zeit ist einzigartig

Einige haben erst am 12. Dezember 2012 gemerkt, dass die Zeit einzigartig ist. CAs hingegen wissen das schon seit Längerem und wissen dies auch effektiv zu nutzen. Bei meinem letzten Setup bin ich wieder über diese Falle gestolpert: Die Einrichtung der externen CA und des Puppetmasters ging wie immer ohne Probleme, nur jegliche Zertifikate wollten nicht akzeptiert werden. Wer Puppet einsetzt wird diese Fehlermeldung sofort erkennen:

err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet ]

Wir können in diesem Fall zum einen prüfen, ob unsere CA die selbe ist.

Mit OpenSSL können Zertifikate lesbar dargestellt werden.

openssl x509 -text -noout -in /path/to/ssl/certs/ca.pem | grep Issuer

In dem Output sollte dann eine Zeile mit dem Issuer zu sehen sein und wenn dieser mit der Puppet CA nicht übereinstimmt, müssen deren Einstellungen überprüft werden. Dabei können diese Befehle hilfreich sein.

sudo puppet master --configprint certname

sudo puppet master --configprint ca

Sobald aber hier alles richtig konfiguriert wurde, ist es zum anderen gut ein Auge auf die Zeit zu werfen.

Wenn die Zeit nicht stimmt kann es dazu kommen, dass Zertifikate in der Zukunft ausgestellt werden und diese für die CA keine Gültigkeit besitzen.

Ein einheitlicher Zeitserver kommt diesem Problem entgegen, denn mit ihm vermeiden wir Zertifikate in der Zukunft auszustellen. Wenn dieser nicht vorhanden ist, reicht ein einfaches:

sudo apt-get install ntp

und eventuell ein kurzer Neustart. Danach muss der Puppet Agent neu signiert werden. Dazu müssen alle Zertifikate gelöscht werden.

Auf dem Puppetmaster:

sudo puppet cert clean yourserver.localdomain

Auf dem Client:
sudo rm -rf /path/to/puppet/ssl/*  #Default ist /var/lib/puppet/ssl/

Anschließend kann ein neuer Testlauf auf dem Agent ausgeführt werden, der dann ein neues Zertifikat generiert

sudo puppet agent --test

und durch den Puppetmaster validieren lässt.

sudo puppet cert sign yourserver.localdomain

P.S.: Achtet bei eurer Icinga2 HA Installation auch auf die Zeit, hier werden ebenfalls SSL Zertifikate benutzt und unterschiedliche Zeitserver können zu Zeitverschiebungen (im Projekt) führen. 😉

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.

How is the weather going to be tomorrow?

disk_memeWie wird das Wetter morgen? Zieh ich mich warm an oder kann ich mich ohne Sorgen locker kleiden? Diese Entscheidung wollen wir nicht selbst treffen, wir können nur eine Vermutung aufstellen und uns dementsprechend kleiden.

Bei einer Fehlentscheidung werden wir unangenehm überrascht, der Tag wird hektisch die Laune sucht sich einen trockenen Platz im Keller und dann haben wir den Salat.

Deswegen haben wir Wetterstationen, Satellitenbilder und weitere Messstationen. Diese errechnen dann unser Wetter für den bzw. die kommenden Tag/e.

Aus diesem Grund haben wir Monitorsysteme die uns vor der bösen Überraschung, normalerweise in “Realtime” warnen. D.h. wenn das System kritisch ist, bekommen wir eine Benachrichtigung. Für eine nahezu volle Festplatte stehen wir zu unchristlichen Zeiten auf, nur um festzustellen dass 10% bei Kunde “Zefix” noch 100GB bedeuten. Das kann von Fall zu Fall gut oder schlecht sein!

99% Belegung sind definitiv negativ!

Damit komme ich zu meinem ersten Punkt: feste Schwellwerte!

Beispiel:
Eine Maschine mit 10TB Festplatte. Unser check_disk hat den Schwellwert 95%, dann bekommen wir eine kritische Meldung.
Ich denke jeder Angestellter mit gesundem Verstand, kann sagen, dass die Festplatte noch 500GB frei hat.

Nun die Frage, haben wir jetzt genug Zeit zu reagieren um unseren Kunden vor dem Ausfall zu bewahren?

Erster Fall:
JA Klar! Die Maschine steigt seit Ewigkeiten langsam an, da kann ich noch morgen früh dem Kunden eine Email schreiben, Acknowledge”

Zweiter Fall:
Oh Nein! Die Festplattenbelegung ist in den letzten Stunden rasant angestiegen, lass uns mal schnell ein paar Logfiles löschen! Wird schon wieder! Morgen schau ich mir das genauer an”

In jedem Fall läuft es auf das Gleich hinaus: wir reagieren hektisch und unüberlegt, schieben es hinaus oder im schlechtesten Fall können wir nicht mehr agieren.

Das ist der Grund weswegen wir uns auf den Wetterbericht verlassen: Wir wollen Vorbereitungen treffen, um aus den Umständen das Beste zu machen.

Glaskugeln sind gar nicht schlecht!

Wann wird Kunde “XYZ” keinen Speicher mehr haben?

Müssen wir eventuell neue Festplatten bestellen?

Ist unser Bereitschaftsdienst betroffen?

Wir wollen wissen was auf uns zukommt, um für unseren Kunden richtig agieren zu können. Checks mit “Forecast” werden gebraucht!

disk_usage_example

An diesem Graphen können wir erkennen, dass die Steigung über zwei Zeiteinheiten anhielt. Mit dieser Steigung können wir vorhersagen, wann unser Speicherplatz eng wird. Bei gleichbleibenden Anstieg wohlgemerkt!

Welche Fragen sollten geklärt werden, bevor wir eine passende Prognose erstellen? 

1. Welches Zeitintervall werden wir prüfen? 

2. Wie decken wir kleine Peaks ab?

3. Brauchen wir eine zweite Steigung für einen kleineren Zeitabschnitt?

4. Wann soll der Check meinen Kunden oder mich benachrichtigen?

5. Wie weit im Voraus muss mein Bereitschaftsdienst benachrichtigt werden, um noch angemessen zu reagieren?

6. Bekomm ich dann nicht sogar mehr Meldungen?

7. Brauchen wir zusätzlich feste Schwellwerte? 

8. Nehmen wir immer noch 100% als Obergrenze oder doch lieber die Festplattenkapazität?

Niemand kann diese Fragen so genau beantworten, dass sie allen Anforderungen gerecht werden! Das Einzige was bleibt sind Individuelle Lösungen, für jeden Kunden, für jede Situation.

Somit muss jeder, der Prognosen haben möchte, sich intensiv mit der Thematik beschäftigen.

Aber eines ist klar: Wir wollen wissen ob morgen die Sonne scheint!

 

 

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.

Drei Wege um virtuelle Maschinen zu migrieren

OpenNebulaConf Grafiken 09Neue Storage-Lösungen sprießen wie Tulpen im Frühling aus dem Boden. Jede einzelne ist flexibler, schlanker und hochverfügbarer.
Da kommt meine Cloud ins Spiel, die eigentlich gut läuft aber so ein schnelleres Storage ist eine willkommene Abwechslung.

So ein neues Storage ist schnell aufgesetzt, was uns dann aber vor eine neue Aufgabe stellt,
denn unsere VMs laufen… nur nicht auf unserem hippen Storage.

Nun gibt es diverse Methoden um eine virtuelle Maschine in ein neues Image bzw. neues Storage zu transferieren.

Da haben wir zum einen die altbewährte Methode, mit dem Urgestein aller blockorientierten Kopiervorgänge dd.
Dazu muss die virtuelle Maschine komplett ausgeschaltet sein. Da sich der Zustand der VMs nicht mehr ändert, kann man beruhigt die VM kopieren.

dd if=/path/to/input/file of=/path/to/output/file bs=4096

Zum anderen die Methode ein qcow2 Image in ein Blockdevice zu schreiben.
In Worten gesagt: das Image wird mit “qemu-img convert” in Raw umgewandelt und danach mit dd auf das neue Blockdevice kopiert. (Auch hier sollte die VM nicht mehr laufen!)

qemu-img convert -p -f qcow2 -O raw /path/to/input/file /path/to/outputfile.raw && dd if=/path/to/outputfile.raw of=/path/of/device bs=4M

Da die beiden genannten Arten eine lange Downtime benötigen, sind sie nur für VMs geeignet die nicht zeitkritisch sind.

Ein UNIX System kann mit guten Kenntnissen, mit relativ kurzer Ausfallszeit migriert werden. Ein hilfreiches Werkzeug dabei ist Rsync.

Leider kann ich hierzu kein fixes Beispiel vorzeigen, da die einzelnen Schritte von System zu System unterschiedlich ausfallen.

Die essentiellen Schritte sind:

1. Neues Device in der VM mounten und das gewünschte Filesystem erstellen.
2. Systemverzeichnisse auf dem neuen Device erstellen.
3. Das komplette System mit Rsync auf das neue Device kopieren. Hier muss man natürlich etwas aufpassen und Verzeichnisse wie /proc oder ggf. /mnt exkludieren. Auch auf bind Mounts sollte man achten, damit man Daten nicht ausversehen doppelt kopiert.
4. Die grub.cfg natürlich im neuen /boot Pfad aktualisieren. (grub-install und update-grub sind hierfür hilfreich)
5. Das “alte Device” als read-only einbinden und die neue fstab anpassen.
6. Und last but not least, einen weiteren Rsync in dem die restlichen Files auf das neue Image übertragen werden. (auch hier bitte das Exkludieren von wichtigen Pfaden nicht vergessen. z.B.: /etc/fstab oder auch /boot !!)

Der Vorteil hierbei ist: die Downtime erstreckt sich dabei nur über den zweiten Rsync, bei dem die Festplatte im “read-only” Modus ist.

Habt Ihr weitere coole Möglichkeiten einen VM zu migrieren?
Dann dürft ihr euch in den Kommentaren dazu äußern.

Oder seid Ihr interessiert an dem Thema Cloud und alles was damit zu tun hat? Dann besucht uns einfach auf der OpenNebula Conf 2014

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.