DevOps-Enabler Ansible, Teil 2 Bereitstellung von Ansible

Zwar haben wir uns schon mit der Funktionsweise und dem Einsatzzweck von Ansible beschäftigt. Bevor man die IT-Automation in Angriff nimmt und die ersten Kommandos absetzt, sollte man aber noch ein paar Grundlagen kennen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Red Hat GmbH

Ansible verwaltet Maschinen wie gesehen standardmäßig über das SSH-Protokoll. Ansible wird keine Datenbank oder ähnliches anlegen und auch keine Daemons starten. Zur zentralen Orchestrierung von Rechnerflotten per Ansible benötigt man schlicht einen Rechner – dazu genügt auch ein Notebook –, auf dem Ansible läuft bzw. installiert ist. Auch für die Verwaltung von Remote-Hosts durch Ansible wird keinerlei Software installiert oder ausgeführt.

Gegenwärtig lässt sich Ansible von jedem Rechner aus nutzen, auf dem Python 2 (Versionen 2.6 oder 2.7) oder Python 3 (Versionen 3.5 und höher) installiert ist. Windows wird für die Steuerungsmaschine allerdings nicht unterstützt. Da Ansible im Zweifel direkt von der Quelle läuft und keine Installation von Software auf Remote-Maschinen erfordert, verwenden viele Nutzer sogar die aktuelle Entwicklungsversion. In diesem Fall ist das Installieren von Ansible komplett obsolet.

Da Release-Zyklen von Ansible normalerweise vier Monate währen, sind kleinere Bugs bei der Entwicklerversion im Allgemeinen in der nächsten Version behoben; im Gegensatz zu Backports auf dem stabilen Zweig.

Ansible auf der Kontroll-Maschine installieren

Wer mit Ansible startet, sollte trotzdem der Einfachheit halber zunächst eine für Red Hat Enterprise Linux (RHEL), CentOS, Fedora, Debian oder Ubuntu paketierte Version verwenden. Die Installation erfolgt mit Hilfe des Paketmanagers der Distribution, unter Red Hat und CentOS ist das z. B. mit …

… schnell erledigt. Ansible RPMs für RHEL7 sind im Extra-Channel verfügbar, Ansible RPMs für RHEL6 dagegen über das EPEL6-Repository.

Da Ansible reiner Python-Code ist, ist optional immer auch das direkte Installieren über den Python-Paket-Manager via „pip“ möglich. Eine weitere Option für RHEL und Fedora besteht darin, sich selbst RRM-Pakete zu schnüren. Diese und weitere Optionen auch für andere Distributionen sind in der ausführlichen Ansible-Dokumentation beschrieben.

Auf den verwalteten Knoten benötigt man eine Möglichkeit zur Kommunikation, also normalerweise SSH. Standardmäßig wird dazu sftp verwendet. Ist sftp nicht verfügbar, kann der Admin durch Abändern der ansible.cfg zu scp wechseln. Auf dem zu verwaltenden Hosts ist mindestens Python 2.6 oder höher erforderlich.

Ansible konfigurieren

Viele Einstellungen in Ansible lassen sich über eine Konfigurationsdatei (ansible.cfg) vornehmen. Die mitgelieferte Standardkonfiguration sollte für die meisten Szenarien und Nutzer aber ausreichen.

Nur im Einzelfall sollte es Gründe geben, hier Änderungen vorzunehmen. Wurde Ansible von einem Paket-Manager installiert, ist die jeweils neueste ansible.cfg-Datei unter /etc/ansible verfügbar, jeweils an der Endung ".rpmnew" (oder ähnlich) zu erkennen. Wurde Ansible über pip oder direkt von der Quelle installiert, kann man diese Datei auch erstellen, um die Standardeinstellungen in Ansible zu überschreiben. Eine beispielhafte ansible.cfg-Datei findet sich bei GitHub.

Ansible ermöglicht auch die Konfiguration von Einstellungen mit Umgebungsvariablen. Wenn diese Umgebungsvariablen festgelegt sind, überschreiben sie alle Einstellungen, die aus der Konfigurationsdatei geladen werden. Eine vollständige Liste der verfügbaren Umgebungsvariablen ist ebenfalls in der Dokumentation zu finden.

Ab Ansible Version 2.4 können Nutzer auch das CLI-Tool ansible-config verwenden, um verfügbaren Optionen auflisten und die aktuellen Werte zu überprüfen.

Starten mit Ansible

Vor dem Start sollte man sich etwas mehr im Detail damit beschäftigen, wie Ansible per SSH mit den Remote-Maschinen kommuniziert. Per Default versucht Ansible wenn möglich, natives OpenSSH für die Remote-Kommunikation zu verwenden. Dies erschließt ggf. Leistungsmerkmale wie ControlPersist, Kerberos-Support und diverse Optionen in ~/.ssh/config wie z. B. ein Jump-Host-Setup.

Allerdings kann es z. B. bei einem älteren Betriebssystem auf dem Steuerungscomputer (wie RHEL 6 oder CentOS 6.2) vorkommen, dass die verwendete OpenSSH-Version ControlPersist noch nicht unterstützt. In diesem Fall greift Ansible auf eine qualitativ hochwertigere Python-Implementierung von OpenSSH namens „paramiko“ zurück.

Möchte man Funktionen wie Kerberos nutzen, benötigt man aber zwingend OpenSSH und muss auf dem Steuerungscomputer auf ein anderes Betriebssystem setzen – zumindest so lange keine neuere Version von OpenSSH für die Wunsch-Plattform verfügbar ist.

Wie oben bereits erwähnt, kann es in seltenen Fällen vorkommen, dass das ein Gerät SFTP nicht unterstützt. In diesem Fall kann man per Konfiguration in der ansible.cfg in den SCP-Modus wechseln. Ferner geht Ansible bei der Kommunikation mit Remote-Hosts normalerweise davon aus, dass der Nutzer SSH-Schlüssel verwendet. Auf Wunsch ist es aber auch möglich, mit der Option --ask-pass auf gewöhnliche Kennwortauthentifizierung umzustellen.

Sollen sudo-Funktionen verwendet werden und sudo erfordert ein Kennwort, kann man die Option --ask-town-pass verwenden. Jedes Managementsystem profitiert davon, wenn es in der Nähe der verwalteten Maschinen ausgeführt wird. Wird Ansible beispielsweise in einer Cloud genutzt, sollte man auch den Steuerungs-Computer in dieser Cloud betreiben, etwa auf Basis einer EC2-Instanz. Die wird in der Regel weitaus effizienter sein, als über das Internet.

Erste Kommandos

Ist Ansible erfolgreich installiert und konfiguriert, kann man sich an erste essenzielle Kommandos wagen. Wie bereits im einführenden Teil erwähnt, trägt man dazu zunächst den oder die zu verwaltenden Ziel-Hosts in die Inventardatei „/etc/ansible/hosts“ ein. Je nach Installationsart muss man die Datei ggf. neu erstellen:

Außerdem muss sich der öffentliche SSH-Key des Nutzers in der „authorized_keys“-Datei auf diesen Systemen befinden. Dazu kann man SSH-Agent so einrichten, dass das erneute Eingeben von Kennwörtern vermieden wird:

Je nach Konfiguration kann man mit der Option --private-key von Ansible stattdessen auch eine PEM-Datei angeben. Ein erster Test von Ansible könnte jetzt darin bestehen, alle im Ansible-Inventar vorhandenen Host zu pingen:

Jetzt sind wir an dem Punkt angelangt, dass wir einen der zum Ende von Teil 1 vorgeschlagenen Live-Kommandos absetzten könnten. Das geht selbstverständlich wieder auf allen im Inventar eingetragenen Hosts gleichzeitig, z. B.:

Im nächsten Teil unserer Ansible-Reihe wäre es an der Zeit, sich etwas komplexeren Ad-hoc-Kommandos zuzuwenden und sich eingehender mit der Erstellung von Playbooks zu befassen. Wir werden dies allerdings zu einem späteren Zeitpunkt in Verbindung mit einer grafischen Oberfläche tun und uns in Teil 3 zunächst die Installation und Inbetriebnahme von Ansible Tower ansehen.

(ID:45363795)