Ansible
Ursprüngliche(r) Autor(en) | Michael DeHaan |
---|---|
Entwickler(n) | Ansible-Gemeinschaft / Ansible Inc. / Red Hat Inc. |
Erste Veröffentlichung | 20. Februar 2012; vor 11 Jahren |
Geschrieben in. | Python, PowerShell, Shell, Ruby |
Betriebssysteme. | Linux, Unix-ähnlich, MacOS, Windows |
Verfügbar in | Englisch |
Typ | Konfigurationsmanagement, Infrastruktur als Code (IaC), Orchestrierungs-Engine |
Lizenz | Proprietär / GNU General Public License |
Ansible ist eine Reihe von Software-Tools, die Infrastruktur als Code ermöglichen. Es ist Open-Source und die Suite umfasst Funktionen für die Softwarebereitstellung, das Konfigurationsmanagement und die Anwendungsbereitstellung. ⓘ
Ansible wurde ursprünglich von Michael DeHaan geschrieben und 2015 von Red Hat übernommen. Es wurde entwickelt, um sowohl Unix-ähnliche Systeme als auch Microsoft Windows zu konfigurieren. Ansible ist agentenlos und stützt sich auf temporäre Remote-Verbindungen über SSH oder Windows Remote Management, die die Ausführung der PowerShell ermöglichen. Der Ansible-Kontrollknoten läuft auf den meisten Unix-ähnlichen Systemen, auf denen Python ausgeführt werden kann, einschließlich Windows mit installierter WSL. Die Systemkonfiguration wird zum Teil mit Hilfe einer eigenen deklarativen Sprache definiert. ⓘ
Ansible ist ein Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern. Es kombiniert Softwareverteilung, Ad-hoc-Kommando-Ausführung und Software-Configuration-Management. Die Verwaltung von Netzwerkcomputern erfolgt unter anderem über SSH und erfordert keinerlei zusätzliche Software auf dem verwalteten System. Module nutzen zur Ausgabe JSON und können in jeder beliebigen Programmiersprache geschrieben sein. Das System nutzt YAML zur Formulierung wiederverwendbarer Beschreibungen von Systemen. ⓘ
Geschichte
Der Begriff "Ansible" wurde von Ursula K. Le Guin in ihrem 1966 erschienenen Roman Rocannon's World geprägt und bezieht sich auf fiktive, sofortige Kommunikationssysteme. ⓘ
Das Ansible-Tool wurde von Michael DeHaan entwickelt, dem Autor der Provisioning-Server-Anwendung Cobbler und Mitautor des Fedora Unified Network Controller (Func)-Frameworks für die Fernverwaltung. ⓘ
Ansible, Inc. (ursprünglich AnsibleWorks, Inc.) war das 2013 von Michael DeHaan, Timothy Gerla und Saïd Ziouani gegründete Unternehmen, das Ansible kommerziell unterstützen und fördern sollte. Red Hat hat Ansible im Oktober 2015 übernommen. ⓘ
Ansible ist Teil der Fedora-Distribution von Linux, die Red Hat gehört, und ist auch für Red Hat Enterprise Linux, CentOS, openSUSE, SUSE Linux Enterprise, Debian, Ubuntu, Scientific Linux und Oracle Linux über Extra Packages for Enterprise Linux (EPEL) sowie für andere Betriebssysteme verfügbar. ⓘ
$wgTimelinePerlCommand
korrekt festgelegt ist.Architektur
Überblick
Ansible hilft bei der Verwaltung mehrerer Maschinen durch Auswahl von Teilen des Ansible-Inventars, das in einfachen ASCII-Textdateien gespeichert ist. Das Inventar ist konfigurierbar, und das Zielmaschineninventar kann dynamisch oder aus Cloud-basierten Quellen in verschiedenen Formaten (YAML, INI) bezogen werden. ⓘ
Sensible Daten können seit 2014 mit Ansible Vault in verschlüsselten Dateien gespeichert werden. Im Gegensatz zu anderen populären Konfigurationsmanagement-Software - wie Chef, Puppet, Salt und CFEngine - verwendet Ansible eine agentenlose Architektur, wobei die Die Ansible-Software wird normalerweise nicht auf dem kontrollierten Knoten ausgeführt oder gar installiert. Stattdessen orchestriert Ansible einen Knoten, indem es über SSH vorübergehend Module auf dem Knoten installiert und ausführt. Für die Dauer einer Orchestrierungsaufgabe kommuniziert ein Prozess, der das Modul ausführt, mit dem kontrollierenden Rechner über ein JSON-basiertes Protokoll über seine Standardein- und -ausgabe. Wenn Ansible einen Knoten nicht verwaltet, verbraucht es keine Ressourcen auf dem Knoten, da keine Daemons ausgeführt oder Software installiert wird. ⓘ
Abhängigkeiten
Ansible erfordert die Installation von Python auf allen verwaltenden Rechnern, einschließlich des Paketmanagers pip sowie der Konfigurationsverwaltungssoftware und ihrer abhängigen Pakete. Verwaltete Netzwerkgeräte erfordern keine zusätzlichen Abhängigkeiten und sind agentenlos. ⓘ
Kontrollknoten
Der Kontrollknoten (Master-Host) ist für die Verwaltung (Orchestrierung) von Zielmaschinen (Knoten, die als "Inventar" bezeichnet werden, siehe unten) vorgesehen. Kontrollknoten sind nur für Linux und dergleichen verfügbar; Windows-Betriebssysteme werden nicht unterstützt. Mehrere Kontrollknoten sind zulässig. Ansible erfordert keinen einzigen Kontrollrechner für die Orchestrierung, wodurch eine einfache Wiederherstellung im Notfall gewährleistet ist. Die Knoten werden vom Kontrollknoten über SSH verwaltet. ⓘ
Entwurfsziele
Zu den Designzielen von Ansible gehören:
- Minimale Anforderungen. Verwaltungssysteme sollten der Umgebung keine zusätzlichen Abhängigkeiten auferlegen.
- Konsistent. Mit Ansible soll man konsistente Umgebungen schaffen können.
- Sicher. Ansible setzt keine Agenten auf den Knoten ein. Auf den verwalteten Knoten werden nur OpenSSH und Python benötigt.
- Zuverlässig. Wenn ein Ansible-Playbook sorgfältig geschrieben ist, kann es idempotent sein, um unerwartete Nebeneffekte auf den verwalteten Systemen zu verhindern. Es ist möglich, Playbooks zu schreiben, die nicht idempotent sind.
- Minimale Einarbeitung erforderlich. Playbooks verwenden eine einfache und beschreibende Sprache, die auf YAML und Jinja-Vorlagen basiert. ⓘ
Module
Module sind meist eigenständig und können in einer Standard-Skriptsprache (wie Python, Perl, Ruby, Bash, etc.) geschrieben werden. Eines der Hauptziele von Modulen ist die Idempotenz, d. h., selbst wenn ein Vorgang mehrfach wiederholt wird (z. B. bei der Wiederherstellung nach einem Ausfall), wird das System immer in denselben Zustand versetzt. ⓘ
Konfiguration des Inventars
Der Standort der Zielknoten wird über Inventar-Konfigurationslisten (INI- oder YAML-formatiert) angegeben, die sich unter /etc/ansible/hosts
(unter Linux). Die Konfigurationsdatei listet entweder die IP-Adresse oder den Hostnamen jedes Knotens auf, auf den Ansible zugreifen kann. Außerdem können die Knoten Gruppen zugewiesen werden. ⓘ
Ein Beispiel-Inventar (INI-Format):
192.168.6.1 <span title="Aus: Englische Wikipedia, Abschnitt "Inventory configuration"" class="plainlinks">[https://en.wikipedia.org/wiki/Ansible_(software)#Inventory_configuration <span style="color:#dddddd">ⓘ</span>]</span>
[Webserver]
foo.beispiel.com
bar.beispiel.com
In dieser Konfigurationsdatei werden drei Knoten angegeben: Der erste Knoten wird durch eine IP-Adresse und die beiden letzten Knoten durch Hostnamen angegeben. Außerdem sind die beiden letztgenannten Knoten in der Gruppe "Webserver" zusammengefasst. ⓘ
Ansible kann auch ein benutzerdefiniertes dynamisches Inventarisierungsskript verwenden, das Daten dynamisch von einem anderen System abrufen kann und Gruppen von Gruppen unterstützt. ⓘ
Abspielbücher
Playbooks sind YAML-Dateien, die Listen von Aufgaben zur wiederholten Ausführung auf verwalteten Knoten speichern. Jedes Playbook ordnet (assoziiert) eine Gruppe von Hosts einer Reihe von Rollen zu. Jede Rolle wird durch Aufrufe von Ansible-Aufgaben dargestellt. ⓘ
Ansible-Automatisierungsplattform
Bei der Ansible Automation Platform handelt es sich um eine REST-API, einen Webservice und eine webbasierte Schnittstelle (Anwendung), die den Zugang zu Ansible für Personen mit den unterschiedlichsten IT-Kenntnissen erleichtern soll. Es handelt sich um eine Plattform, die sich aus mehreren Komponenten zusammensetzt, darunter Entwickler-Tools, eine Betriebsschnittstelle sowie ein Automation Mesh, das Automatisierungsaufgaben in großem Umfang über Rechenzentren hinweg ermöglicht. AAP ist ein kommerzielles Produkt, das von Red Hat, Inc. unterstützt wird, aber aus 17+ Upstream-Open-Source-Projekten hervorgegangen ist, darunter das AWX-Upstream-Projekt (von dem früher Ansible Tower abgeleitet wurde), das seit September 2017 Open Source ist. ⓘ
Es gab auch eine andere Open-Source-Alternative zu Tower, Semaphore, geschrieben in Go. ⓘ
AWX
AWX ist eine REST-API, ein Web-Service und eine Web-basierte Konsole. Damit kann die mit Ansible verwaltete IT-Infrastruktur zentralisiert werden mit einem visuellen Dashboard einschließlich Verwaltung aller Inventare, einer rollenbasierten Zutrittskontrolle, Job-Scheduling und Nachrichten. ⓘ
Plattformunterstützung
Kontrollmaschinen müssen ein Linux/Unix-Host sein (zum Beispiel BSD, CentOS, Debian, macOS, Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu), und Python 2.7 oder 3.5 ist erforderlich. ⓘ
Verwaltete Knoten, wenn sie Unix-ähnlich sind, müssen Python 2.4 oder höher haben. Für verwaltete Knoten mit Python 2.5 oder früher ist außerdem das Paket python-simplejson
erforderlich. Seit Version 1.7 kann Ansible auch Windows-Knoten verwalten. In diesem Fall wird anstelle von SSH das native PowerShell-Remoting verwendet, das vom WS-Management-Protokoll unterstützt wird. ⓘ
Ansible kann auf Bare-Metal-Hosts, virtuellen Maschinen und Cloud-Umgebungen eingesetzt werden. ⓘ
AnsibleFest
AnsibleFest ist eine jährlich stattfindende Konferenz der Ansible-Gemeinschaft von Benutzern, Mitwirkenden usw. ⓘ
Jahr | Ort ⓘ |
---|---|
2014 | San Francisco, Kalifornien |
2015 | London, Großbritannien |
2016 | London, Großbritannien |
2016 | San Francisco, Kalifornien |
2016 | Brooklyn, New York |
2017 | London, Großbritannien |
2017 | San Francisco |
2018 | Austin, Texas |
2019 | Atlanta, Georgia |
2020 | Nur virtuell wegen der COVID-19-Pandemie |
2021 | Nur virtuell wegen der COVID-19-Pandemie |
2022 | Chicago, Illinois |