Open Source im professionellen Einsatz
Linux-Magazin 04/2016
© 36clicks, 123RF

© 36clicks, 123RF

Konfigurationsmanager in Version 2.0

Zweite Runde

Mit einer überarbeiteten und schnelleren Engine geht die neue Version 2.0 der in Python geschriebenen Orchestrierungssoftware Ansible an den Start. Reicht das für eine Pole Position?

507

Der Name Ansible stammt laut [1] aus Ursula Le Guins Roman "Rocannon's World" von 1966. Ihr Apparat kommuniziert in Überlichtgeschwindigkeit und ohne Verzögerung überallhin. Der Admin von heute kennt Ansible eher als Orchestrierungstool und Mitbewerber von Puppet, Chef und Salt.

Seit Ansible [2] zu Red Hat gehört (seit 2015), gibt es zwar keine großen Schlagzeilen mehr, wohl aber neue Releases. Die Neuerungen der aktuellen listet [3] auf. Eine davon bemerkt der Admin allenfalls an der Ausführungsgeschwindigkeit: Das Team hat Teile der Engine überarbeitet, die nun Playbooks und andere Yaml-Dateien schneller parst. Daneben bringt Ansible 2.0 nützliche Erweiterungen und mehr als 200 neue Module (vor allen für Open Stack und Cloud Stack sowie für Windows) mit.

Ansible gibt es in einer freien und einer kommerziellen Version. Anders als viele Konkurrenten setzt es auf den verwalteten Systemen keine Agenten, sondern lediglich einen Python-Interpreter voraus. Das vereinfacht den Start, allerdings muss der Admin Konfigurationswechsel aktiv anstoßen.

Ausführungsblöcke

Task Blocks (Abbildung 1) ermöglichen es dem Admin, zusammenhängende Aufgaben zu bündeln. Abhängig davon, ob Ansible einen solchen Block erfolgreich ausführt, stößt es im Anschluss andere Aktionen an. Dieses Vorgehen folgt dabei dem Try-Except-Finally-Mechanismus von Python (oder dem Try-Catch-Finally-Konstrukt von Java), Listing 1 zeigt ein Beispiel.

Listing 1

Ausführungsblöcke

01 - hosts: test-hosts
02   tasks:
03   - block:
04     - name: Test Block
05       command: /bin/false
06       tags: gehtnicht
07     - name: Test Block 2
08       command: /bin/true
09       tags: geht
10     rescue:
11       - debug: msg="Fehler Fehler Fehler"
12     always:
13       - debug: msg="Immer Immer Immer"
Abbildung 1: Task Blocks orientieren sich am Try-Except-Finally-Mechanismus von Python.

Tritt ein Fehler auf, was im Beispiel dank des Ausdrucks »/bin/false« stets der Fall ist, greifen die Anweisungen im »rescue« -Block. Den »always« -Block führt Ansible hingegen immer aus. Das kann beispielsweise erforderlich sein, wenn es sich um Aufräumarbeiten handelt, die immer wieder nötig sind.

Neue Ausführungsstrategien

Ab Version 2.0 beeinflusst der Admin auf Wunsch, in welcher Reihenfolge Ansible Aufgaben abarbeitet. Diese Entscheidung fällte die Software bislang allein. Um etwa Konfigurationen auf eine Reihe von Hosts zu verteilen, fasste der Admin diese in Ansibles Hosts-Datei (meist »/etc/ansible/hosts« ) unter einem Namen zusammen, den das Playbook dann als Ziel seiner Aktionen auserkor. Um mehrere Schritte abzuarbeiten, wartete Ansible stets, bis für alle Hosts der Gruppe ein Ergebnis vorlag, und schritt erst dann zur nächsten Tat.

Über das eingeführte Keyword »strategy« erhält der Admin nun mehr Einfluss auf den Ablauf. Setzt er den Wert »free« ein, erledigt Ansible alle Tasks schnellstmöglich, unabhängig davon, wie weit die anderen Hosts der Gruppe sind. Verzichten sollte er darauf, wenn bei Abhängigkeiten inkonsistente Zuständen drohen.

An dieser Stelle lässt sich auch der Parameter »serial« erwähnen, der aber bereits länger existiert. Mit ihm steuert der Verwalter, wie viele Hosts Ansible zeitgleich aufs Korn nimmt. So lassen sich innerhalb von Clustern Updates anbringen, ohne dass der ganze Cluster ausfällt.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Ansible 2.0 verfügbar

    Nach dem Kauf von Ansible durch Red Hat ist nun die Version 2.0 der agentenlosen Automatisierungssoftware verfügbar.

  • Perl-Snapshot

    Das überlichtgeschwinde Provisionierungstool Ansible eignet sich nicht nur für Konfigurations- und Releasemanagement mittelgroßer Serverfarmen, sondern auch für den Hausgebrauch, zum Restaurieren von Anpassungen auf dem Linux-Desktop daheim.

  • Confluence & Co.

    Agile, Confluence und Gitlab sind im Devops-Kontext sehr beliebt und bilden oft das Fundament für agile Arbeit. Mit den richtigen Ansible-Playbooks lässt sich Ubuntu schnell zur agilen Arbeitszentrale machen.

  • Puppet vs. Ansible

    Automatisierung gehört im Rechenzentrum zum guten Ton. Puppet gilt als Platzhirsch und darf von sich behaupten, bei Unternehmen wie Google im Einsatz zu sein. Ansible ist eine schlanke Alternative.

  • Debops

    Automatisierung ist nicht nur in großen Setups hilfreich. Sie nützt überall dort, wo Admins identische Aufgaben immer und immer wieder erledigen müssen. Das Werkzeug Debops bringt viele oft gebrauchte Serverdienste schnell und leicht auf ladenneue Debian-Systeme.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.