Konfigurationmanagement mit Ansible
Eine der bekanntesten Lösungen ist sicherlich Puppet. Etwas jünger und bisher weniger prominent ist Ansible, das seit 2015 zum Red Hat Konzern gehört. Ansible ist ein Open Source Automatisierungstool, geschrieben in Python. In Ansible werden verschiedenste Automatisierungsmöglichkeiten als sogenannte Module bereits mitgeliefert, können aber auch vom User selbst in einer beliebigen Programmiersprache geschrieben werden. Vorraussetzung ist, dass sie Input und Output im JSON-Format verarbeiten, bzw. ausliefern können.
Anweisungen werden vom User als ad-hoc Tasks, oder kombiniert und wiederverwendbar als Playbooks im YAML-Style verfasst.
[root@ansible playbook]# ansible-playbook example_playbook.yml -i inventory/inventory.ini PLAY [example_webhost] ********************************************************** TASK [Gathering facts] ************************************************************ ok: [192.168.121.31] TASK [Installiere httpd Paket] ************************************ changed: [192.168.121.31] => (item=[u'epel-release', u'httpd']) TASK [Kopiere httpd config- Datei auf den Zielrechner] ********************************* changed: [192.168.121.31] TASK [Starten des httpd Service] **************************** changed: [192.168.121.31] PLAY RECAP ************************************* [192.168.121.31] : ok=4 changed=3 unreachable=0 failed=0
Variablen, Templates und Programmier-Logiken können über Jiinja-Syntax definiert und benutzt werden. Soll nun ein Playbook auf einem Client ausgeführt werden, so baut Ansible eine SSH Verbindung auf und schiebt die benötigten Module, normalerweise Pythonskripte, dorthin. Diese werden dann lokal ausgeführt, die Kommunikation zwischen Modul auf Clientseite und Masternode passiert über JSON-Statements. Nach erfolgreichem Abarbeiten des Playbooks werden die lokalen Dateien auf Clientseite wieder gelöscht. Aus diesem Funktionsprinzip wird klar, dass Ansible das Push-Prinzip benutzt, d.h. Anweisungen werden von einem Masternode an beliebig viele Clients gesendet. Im Gegensatz dazu benutzt Puppet das Pullprinzip, bei dem Clients sich Anweisungen von einem dedizierten Master ziehen.
Die Vor- und Nachteile liegen auf der Hand: Für Ansible braucht man keine zusätzliche Software und keine komplizierte Konfiguration. Einzige Vorraussetzung auf der Masterseite ist, neben Ansible, Python in Version 2.6 oder 2.7, sowie das Playbook, das ausgeführt werden soll. Die einzige Einschränkung ist aktuell Windows, das, wie bei Puppet, nicht als MasterOS dienen kann. Auf Clientseite werden SSH-Zugriff vom Master, sowie Python in Version 2.6 oder höher benötigt. Der Nachteil liegt in der Automatisierung von Playbook Executions: Aktuell bietet Ansible nur über das kostenpfichtige Tool Tower die Möglichkeit Tasks und Playbooks automatisiert auszuführen, wenn man von Crontabs absehen möchte. Darüber hinaus kann Tower auch einzelne Ansibleuser und -usergroups, sowie SSH-Keys und Passwörter verwalten.
Mittlerweile hat Red Hat auch den Ansible Tower kostenlos zur Verfügung gestellt. Bis zu diesem Zeitpunkt konnte man sich mit einer der Open-Source-Alternativen, zb. Semaphore behelfen. Darüber hinaus können natürlich auch orcharhino oder Foreman benutzt werden, um Clients über Ansible zu orchestrieren. Die Ansible-Community ist sehr aktiv und beständig am wachsen, sodass neue Features und ein schnell wachsender Funktionsumfang garantiert sind.
Alles in allem bietet Ansible schon jetzt mit relativ einfachen Mitteln eine großartige Möglichkeit zur Automatisierung von IT-Infrastrukturen, die, Stand jetzt, bereits voll konkurrenzfähig zu Puppet ist. Den absoluten Königsweg bietet vermutlich aktuell die Kombination aus Ansible und Puppet . Spannend bleibt es definitv, nicht zuletzt Red Hats Ankündigung geschuldet, Ansible tief in seine neuen Produkte zu integrieren. Was das für Foreman, Satellite und andere Produkte bedeutet, wird sich zeigen.
Das könnte Sie auch interessieren:
ATIX-Crew
Neueste Artikel von ATIX-Crew (alle ansehen)
- Foreman Birthday Party 2024 - 1. August 2024
- CrewDay 2024 - 6. Juni 2024
- Die XZ-Sicherheitsschwachstelle: Eine Übersicht - 9. April 2024
