Systeme automatisch konfigurieren mit Ansible AWX

Verleiht Flügel

Das mittlerweile maßgeblich von RedHat weiterentwickelte Ansible hilft im Alltag vielen Administratoren bei der automatischen Wartung und Einrichtung ihrer Systeme. Die Benutzeroberfläche AWX vereinfacht nicht nur die Arbeit mit dem Konfigurationswerkzeug, sondern liefert auch noch nützliche Statistiken.
Die Datenschutz-Grundverordnung nähert sich mit großen Schritten. Und auch in Sachen Hackerangriffen dürfen sich Unternehmen 2018 wieder auf einiges gefasst ... (mehr)

Ansible konfiguriert und administriert automatisch Rechner und Router in einem Netzwerk. Welche Systeme Ansible auf welchem Weg erreicht, legen Administratoren normalerweise per Hand in Textdateien fest. Um ihnen die Arbeit zu erleichtern, bietet Entwickler Red Hat die kommerzielle Webanwendung Ansible Tower an. Sie vereinfacht die Verwaltung der Systeme und das Deployment der Konfigurationen. Darüber hinaus bietet sie eine Benutzerverwaltung und liefert zahlreiche nützliche Statistiken, wie etwa über erfolgreiche und fehlgeschlagene Jobs.

Kostenloser Ableger

Im August 2017 hat Red Hat den Quellcode von Ansible Tower unter eine Open-Souce-Lizenz gestellt und unter dem Namen AWX auf GitHub veröffentlicht [1]. Red Hat hofft darauf, dass dank der verwendeten Apache License die Community Verbesserungen einbringt. Das kommerzielle Ansible Tower bleibt weiterhin erhalten: Während von AWX in recht schneller Frequenz neue Versionen erscheinen sollen, nimmt Red Hat ausgewählte AWX-Releases und veröffentlicht diese mit Long-Term-Support unter dem Markennamen Ansible Tower.

Ursprünglich wollten die AWX-Entwickler ungefähr alle zwei Wochen eine neue Version freigeben. Zum Redaktionsschluss deutete jedoch alles auf deutlich größere Abstände hin. So war die aktuellste stabile Version 1.0.1 bereits über einen Monat alt. Die Bezeichnung "stabil" ist zudem etwas irreführend: Red Hat empfiehlt AWX ausdrücklich nicht für den produktiven Einsatz – unabhängig von der Version. Die für das eigene Unternehmen passende Variante hängt folglich von den jeweiligen Anforderungen ab: AWX eignet sich vorwiegend zur Evaluation und für kleinere Unternehmen, die penibel auf die Kosten achten müssen. Größere Unternehmen sollten hingegen weiterhin Ansible Tower ins Auge fassen, für das Red Hat umfassenden Support gewährt. Für AWX gibt es hingegen nur Support über IRC und die offizielle Mailingliste.

Genau wie Ansible Tower hilft auch AWX dem Administrator nur bei der Verwaltung der Systeme. Die sogenannten Playbooks mit den eigentlichen Konfigurationsanweisungen müssen Administratoren weiterhin per Hand erstellen. AWX verlangt zudem, dass alle Playbooks in einem Versionskontrollsystem liegen. Derzeit kann AWX die Playbooks aus Git-, Mercurial-, Subversion- und Red-Hat-Insights-Repositories abholen. Zwar existiert auch die Möglichkeit, die Playbooks lokal auf dem AWX-Rechner abzulegen. Dazu sind jedoch zum einen weitere Handgriffe nebst Docker-Kenntnissen notwendig und zum anderen unterstützen die Entwickler dieses Vorgehen nicht. Sollten Sie Ihre Playbooks noch nicht in einer Versionsverwaltung speichern, können Sie für erste Tests auf ein Git-Repository der AWX-Macher mit einem simplen Beispiel-Playbook zurückgreifen (dazu später mehr).

Installation

AWX ist derzeit darauf ausgelegt, in einem Docker-Container und somit einer abgeschotteten Umgebung zu laufen. Praktischerweise entsteht der passende Container automatisch während der Installation. Zumindest für eine Testinstallation von AWX benötigen Sie daher (wie auch im Folgenden) keine Kenntnisse über Docker. Der fertige Container mit AWX lässt sich wahlweise in einer Docker-Umgebung oder in einem OpenShift-Cluster zünden, andere Konstellationen unterstützt AWX 1.0.1 nicht offiziell. Da die Inbetriebnahme über Docker wesentlich schneller gelingt, soll sie auch im Folgenden im Vordergrund stehen.

Um AWX installieren zu können, benötigen Sie neben Ansible ab Version 2.4 folglich auch noch Docker, das dazugehörige Python-Modul "docker-py", GNU make und Git. Sofern Ihre Distribution nur eine alte Ansible-Version vorhält, wie etwa im Fall von Ubuntu, müssen Sie Ansible per Hand einspielen. Unter Ubuntu können Sie dazu auf das Repository der Ansible-Entwickler zurückgreifen:

$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible docker.io python-docker git make

Stellen Sie in jedem Fall sicher, dass der Docker-Daemon läuft, unter Ubuntu etwa mit s»udo systemctl restart docker« . Laden Sie sich jetzt den Quellcode der aktuellen AWX-Version von GitHub herunter und entpacken Sie das Archiv. Alternativ klonen Sie den aktuellen Entwicklungsstand:

$ git clone https://github.com/ansible/awx.git

In jedem Fall wechseln Sie in das Unterverzeichnis "installer" und öffnen die Datei "inventory" mit einem Texteditor. Suchen Sie dort am Anfang die Zeile "docker­hub_version=latest". Aufgrund der Angabe "latest" läuft gleich automatisch die aktuellste Version von AWX. Hinter "dockerhub_version" können Sie auch eine ganz bestimmte AWX-Version vorgeben, wie etwa "dockerhub_version=1.0.1".

Im Docker-Container läuft ein Webserver, der die AWX-Benutzeroberfläche ausliefert. Dieser Webserver lauscht standardmäßig an Port "80". Sie können einen anderen Port vorgeben, indem Sie in der Datei "inventory" die Portnummer in der Zeile "host_port=80" entsprechend ändern.

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018