Kein Theater mit Rollen und Drehbüchern Red Hat: Warum Datacenter-Automatisierung mit Ansible taugt

Im Jahr 2015 hat Red Hat für rund 100 Millionen Dollar Ansible gekauft; da das Unternehmen hinter dem gleichnamigen Open-Source-Projekt zur Entwicklung eines Konfigurations-Management-Tool stand. Jetzt ist Red Hat weltweit auf Werbe- und Aufklärungs-Tour für Ansible. Ja, es gibt gute Gründe sich damit zu beschäftigen.

Anbieter zum Thema

Schneider Electric GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

Red Hat GmbH

Ansible ist in Python geschrieben und erlaubt, die Konfiguration von Linux-Rechnern zentral in entsprechenden Dateien zu speichern um sie auf einer Vielzahl von Servern zu reproduzieren. Damit lassen sich letztlich eine Vielzahl an Probleme der Server-Automatisierung lösen und die Administration vereinfachen..

Die Software wurde ab 2012 führend von Michael DeHaan entwickelt, der zuvor selbst bei Red Hat angestellt war und dort etwa als Teil der 'Emerging Technologies Group' den DevOps"-freundlichen Installationss-Server „Cobbler“ und das Task-Ausführungssystem „Func“ mitentwickelt hatte. Ansible wird in Konkurrenz zu „Puppet“, „Chef“ und „Saltstack“ gesehen, lässt sich aber auch in Kombination damit verwenden, zum Beispiel im Framework OpenStack, zumal DeHaan Erfahrungen von Unternehmen wie Puppet Labs, Adaptec und IBM einbringen konnte.

Bildergalerie

Bildergalerie mit 10 Bildern

Ansible hat zahlreiche Fans; derzeit listet Github das Projekt auf Platz sieben, in Bezug auf Popularität beziehungsweise Anzahl der Kontributoren. Ganz oben auf der Liste befinden sich „VC Code“, „React“ und „Tensorflow“. Neu in der Liste sind Projekte, die containerisierte Anwendungen verbinden und „Typescript“-Definitionen konsolidieren: „Kubernetes“, „Azure-Docs“ und „Definitely Typed“ (siehe: Abbildung 1).

Die Bestandteile

Im Prinzip besteht Ansible bei Red Hat aus drei Teilen, dem Management mit „Red Hat Ansible Automation“, der „Red Hat Ansible Engine“ für das Networking und „Red Hat Ansible Tower“. Dazu kommen eine Plattform, über die sich die Community austauscht: „Red Hat Galaxy“ sowie das Analyse-Tool „Red Hat Insights“ mitsamt Empfehlungen zur Risikominimierung.

Damit sollen sich alle Bestandteile einer Datacenter-IT veralten und automatisieren lassen – und zwar durchgängig (siehe Abbildung: 2 und 3) Typische Automatisierungs-Tools im Open-Source-Bereich liefern etwa „Bash“, Javascript; sie führen zur Automation einzelner Funktionen. Zugleich existieren Silos in den Organisationsstrukturen: Entwickler grenzen sich von den Netzwerkern ab, von den Security-Leuten und von den Operatoren und alle zusammen von der Geschäftsebene.

Das aber macht sie Sache kompliziert und Komplexität wiederum verhindert eine durchgängige Automatisierung. Letztlich sollte aber gelten: Sobald ein Mensch notwendig ist, um in den normalen Betrieb einzugreifen, liegt ein Bug vor. Umgekehrt verspricht Ansible eine einfache Handhabung: „Jeder kann die Grundlagen in einer Stunde erlernen und in weniger als einem Tag produktiv sein,“ so Autor und Software-Entwickler Jeff Geerling. (Welche Zuordnung Red Hat hier vornimmt, zeigt die Grafik in Abbildung 4.)

Ansible in Networks

So kennzeichnet etwa den Netzwerkbetrieb bislang Schlagworte wie Legacy und propietäre Technik, eine Aversion gegen Risiken, Paperware und Handwerk. Dagegen stehen nun Gemeinschaftskultur, Risikobewusstsein, offene Systeme, Infrastruktur als Code sowie virtuelle Prototyping in DevOps-Teams.

Der Weg zur Automatisierung ist immer gleich (siehe: Abbildung 6) Standardisieren, in diesem Fall mit der Ansible Engine, Automatisieren der generellen Aufgaben, die über diverse Netze hinweg und auf verschiedenen Devices ausführbar sein sollen, ebenfalls mit Ansible Engine, mitsamt Validierung und schließlich das Ausrollen beziehungsweise Skalieren, mithilfe des Red Hat Ansible Tower. Dieser ermöglicht eine automatisierte Bereitstellung aus einem Servicekatalog, automatisierte Compliance-Überprüfung und -Durchsetzung sowie eine API-gesteuerte Integration mit der Anwendungsentwicklung.

Bildergalerie

Bildergalerie mit 10 Bildern

Arbeiten mit Playbooks

Ansible Administratoren arbeiten mit so genannten Playbooks (siehe: Abbildung 8f) . Das sind die im YAML-Format geschrieben Dateien, die Ansible sagen, was ausgeführt werden soll. YAML steht für Yet Another Markup Language, ist also eine Beschreibungssprache. Playbooks sind eines der Kernfeatures von Ansible; mit den Bausteinen erstellen Admins gleichermaßen eine Aufgabenliste.

Die Playbooks enthalten somit die Schritte, die der Benutzer auf einem bestimmten Rechner ausführen möchte. Sie werden nacheinander ausgeführt. Sie können aber auch zugleich eine Zusammenfassung von einem oder mehreren Playbooks enthalten. Es kann somit mehr als einen Vorgang in einem Drehbuch geben.

Ansible-Rollen

In Ansible wird zudem mit Rollen gearbeitet. Sie bieten wiederum einen Rahmen für völlig unabhängige oder voneinander abhängige Sammlungen von Variablen, Aufgaben, Dateien, Vorlagen und Modulen.

Damit ist die Rolle ein Mechanismus, um ein Playbook in mehrere Dateien aufzuteilen. Dies vereinfacht das Schreiben komplexer Playbooks und erleichtert deren Wiederverwendung.

Jede Rolle ist grundsätzlich auf eine bestimmte Funktion oder gewünschte Ausgabe beschränkt, aber: mit allen notwendigen Schritten, um dieses Ergebnis entweder innerhalb dieser Rolle selbst oder in anderen als Abhängigkeiten aufgeführten Rollen bereitzustellen. Dennoch besitzen sie keine explizite Einstellung, für welchen Host die Rolle gelten soll.

Diese Funktionen sind vergleichsweise klein und lassen sich unabhängig voneinander verwenden, allerdings in Playbooks. Es gibt keine Möglichkeit, eine Rolle direkt auszuführen.

Bildergalerie

Bildergalerie mit 10 Bildern

Liste mit Best Practices

Andreas Neeb hält noch ein paar Ratschläge aus der Red-Hat-Praxis bereit:

• Komplexität killt Produktivität - „Das ist nicht nur ein Marketing-Slogan. Wir meinen es wirklich ernst und glauben daran. Wir sind bestrebt, die Komplexität bei der Entwicklung von Ansible Tools zu reduzieren und ermutigen Sie, dasselbe zu tun. Streben Sie nach Vereinfachung bei dem, was Sie automatisieren.“

• Optimieren der Lesbarkeit -

• Wenn es richtig gemacht wird, kann Ansible zugleich die Dokumentation der Workflow-Automatisierung sein....

• Deklaratives Denken - Ansible ist per Design ein gewünschter Zustandsmotor. Wenn Admins versuchen, in Ihren Stücken und Rollen „Code zu schreiben“, wird das scheitern. Unsere YAML-basierten Playbooks waren nie für die Programmierung gedacht oder geeignet.

• Sorgfalt - Das schließt aber nicht aus, dass Behandeln Sie die Ansible-Inhalte wie Code behandelt werden sollten. Das heißt: Es braucht eine Versionskontrolle der Ansible-Inhalte.

• Einfach beginnen, groß denken - Zudem ist ratsam, so einfach wie möglich zu starten und iterativ vorzugehen. Man beginnt also mit einem einfachen Playbook und statischem Inventar. Das Refactoring und Modularisierung erfolgen später.

• In Modulen portionieren - Außerdem lässt sich gut mit einem Git-Repository beginnen. Wenn dieses aber wächst, sollten stattdessen mehrere verwendet werden.

• Styleguide für Entwickler - Da Operatoren und Entwickler zusammenarbeiten müssen, sollten sie auch eine Sprache sprechen beziehungsweise sich auf eine verständigen. Dafür gibt es auch gute Beispiele. Auf diese Weise lässt sich Konsistenz im Tagging, bei Leerzeichen, bei der Benennung von Aufgaben, Spielen, Variablen und Rollen sowie in Verzeichnis-Layouts erreichen.

• Tests für Playbooks - Notwendig ist unbedingt ein Test-Framework für Playbooks. Dabei geht es etwa um das Überprüfen der Syntax (ansible-playbook --syntax-check playbook.yml) und dem Überprüfung von Best Practices (ansible-lint playbook.yml) sowie um das Automatisieren des Testing (CI/CD)

• Smoke Tests - Ein Frühwarnsyystem ist sinnvoll; also: Nicht einfach ausrollen, sondern nach Warnhinweisen Ausschau halten:

Trick 17 - Um ihre Rolle zu beginnen, können Admins „ansible-galaxy init“ nutzen. Das, was an Verzeichnissen und Sub-Dateien nicht gebraucht wird, lässt sich dann einfach entfernen.
Um die Rollen zu installieren, auch private, lässt sich Ansible-Galaxy verwenden. Und um alle externen Rollen zu manifestieren, zum Beispiel „requirements.yml“ sollte eine Rollen-Datei genutzt werden.

(ID:46013059)