Ansible Tower 3.1

Ansible wurde 2012 von Michael DeHaan gestartet und als Open-Source-Projekt ins Netz gestellt. Ansible ist allerdings nur als Kommandozeilen-Tool implementiert. Das kommerzielle Angebot von Red Hat, das Ansible 2015 übernommen hat, erweitert die Open-Source-Lösung um eine grafische Benutzerschnittstelle. Im Gegensatz zu Puppet und Chef, die auf den Clients eine Agenten-Komponente voraussetzen, braucht Ansible auf den zu verwaltenden Netzwerkcomputern lediglich SSH und Python. Ist eine SSH-Verbindung zum Zielsystem möglich, überträgt Ansible jeweils alle erforderlichen Komponenten zur Laufzeit, führt sie auf den Zielsystem aus und entfernt sie anschließend wieder.

Das Verfahren klingt hinsichtlich der zu erwartenden Geschwindigkeit nach Showstopper, macht sich aber in der Praxis nicht negativ bemerkbar, zumal bei Ansible der Aufwand zur Pflege der Agenten wegfällt und die Updates für Ansible selbst nur bei der lokalen Installation ins Gewicht fallen. Da Ansible mit mehreren Systemen der verwaltenden Infrastruktur arbeitet, muss das Tool wissen, wie die jeweiligen Systeme zu erreichen sind. Dazu sind sämtliche Zielsysteme im Ansible-Inventory verzeichnet. Dieses Inventar basiert auf einer einfachen Textdatei, die per Default als "/etc/ansible/hosts" gespeichert ist. Mehr Komfort in dieser Hinsicht bietet eben Ansible Tower, das neben grafischem Inventory-Management auch ein grafisches Dashboard, rollenbasierte Zugriffskontrolle, Benachrichtigung und einen Job-Scheduler bietet.

Während das Ansible-Open-Source-Projekt im Juni dieses Jahres den Releasestand 2.3.1 erreicht hat, hat Red Hat im Frühjahr mit Ansible Tower 3.1 das zweite große Upgrade veröffentlicht.

Solo-Installation ratsam

Red Hat empfiehlt, Tower als einzige Applikation exklusiv auf einer VM, Cloud-Instanz oder physischen Maschine zu installieren. Die erforderliche Arbeitsspeicherausstattung hängt

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.