Mehrere 100 Systeme mit Ansible verwalten

Ansible ist als Orchestrierungs und Configuration Management Tool derzeit sehr
populär. Dies rührt zum Einen daher, dass der Einstieg sehr einfach ist und zum
Anderen, dass Ansible eine große Bandbreite an Geräten unterstützt. Neben Linux
mit SSH, werden auch Windows und diverse Netzwerkkomponenten unterstützt.
Anexia, ein österreichischer Cloud-Provider, hat sich zum Ziel gesetzt seine
Infrastruktur u.a. mit Ansible zu verwalten. Dieser Vortrag wird die dazugehörige
Infrastruktur und die Erfahrungen bei der Entwicklung des Systems 
vorstellen.
Ein typisches Ansible Projekt besteht aus einem Playbook, einem Inventory und
einigen Rollen. Für alle diese Dokumente ist Nachvollziehbarkeit von großer
Wichtigkeit, daher werden diese Dokumente in einem Versionsverwaltungssystem
abgelegt. Bei Anexia ist dies Gitlab. Gitlab stellt zudem die Umgebung für
automatische Tests (CI) zur Verfügung. Für die Tests kommt in der Regel molecule
zum Einsatz. Mit Hilfe von molecule werden in der CI-Umgegung Container oder 
virtuelle Maschinen erstellt, die dann als Zielsysteme für die zu testenden
Rollen oder Playbooks verwendet werden können. Zudem bietet molecule Mechanismen,
um das Resultat der Ausführung zu verifizieren.
Die Ausführung der Ansible Playbooks gegen die Produktionsumgebung übernimmt AWX.
AWX stellt eine Web-basierte Benutzerschnittstelle und API für die Verwaltung und
Ausführung von Ansible Projekten zur Verfügung.
Ansible benötigt ein Inventory, dass die zu verwaltenden Systeme enthält. In kleinen
Projekten wird dies oft in einer Textdatei gepflegt. Bei sich häufig ändernden oder
größeren Umgebungen ist dies nicht praktikabel. Anexia hat sich daher entschieden,
dass Inventory aus der Anexia Engine zu beziehen. Anexia Engine ist die Cloud
Management Platform von Anexia. Neben Modulen für Compute, Storage und IPAM bietet
es auch ein CMDB Modul. Über die zugehörige API kann ein Inventory dynamisch erzeugt
werden. Zusätzlich hat es den Vorteil, dass das Inventory mit Meta-Informationen,
wie z.B. Standort oder Kundennummer, angereichert werden kann.
Damit die Playbooks auf den Systemen ausgeführt werden können, muss Ansible sich
mit den Systemen verbinden können. Im Falle von Linux wird dafür SSH verwendet.
Um den initialen Verbindungsaufbau zu ermöglichen und die Konfiguration eines
Systems zu automatisieren, hat Anexia einen "Bootstrapper" entwickelt, der auf 
dem System einen weiteren SSH Daemon einrichtet und eine Reihe von initialen SSH
Schlüsseln hinterlegt, um die Authentifizierung zu ermöglichen. Der Bootstrapper
verwendet ebenfalls Ansible und Rollen, die auch für die Provisionierung der Systeme
verwendet werden. Die Erzeugung und Aktualisierung übernimmt die CI Umgegung.
Bei der Entwicklung von Rollen verwendet Anexia eine components/profiles/pattern
Struktur. Für jede Anwendung werden generische components Rollen entwickelt (oder
von Galaxy genutzt). Mit den richtigen Parametern oder zusätzlichen Hilfsrollen
wird dann ein profile entwickelt. Also eine Rolle, die einen bestimmen Anwendungs-
zweck erfüllt. In einem pattern wird daraus ein fertiges Produkt. Ein LAMP-Setup
könnte z.B. als pattern realisiert werden und aus den Profiles/Rollen Apache,
MySQL und PHP bestehen.
Die hier beschriebene Umgebung erlaubt die Verwaltung von mehreren hundert Systemen
und ermöglicht gleichzeitig deren Weiterentwicklung und Pflege in einem Software-
ähnlichem Entwicklungsmodell.

Referenzen:
  * https://www.ansible.com/
  * https://github.com/ansible/awx
  * https://github.com/ansible-community/molecule
  * https://about.gitlab.com/
  * https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/
  * https://anexia.com/de/
  * https://www.anexia-engine.com