Softwareentwicklung und Managed Hosting
ANEXIA
NOV
17
2020

Automatisierung bei Anexia mit Ansible

Geschrieben am 17. November 2020 von Stefan Jakobs

Automatisierung im IT-Umfeld ist seit Jahren ein wichtiges Thema und die Voraussetzung, um komplexe Probleme in der IT zu lösen. Anexia hat mit seinen weltweit verteilten Standorten und dem breiten Kundenspektrum besondere Anforderungen an die Automatisierung der IT-Landschaft. Ein einzelnes Tool kann nicht alle Anforderungen erfüllen. Es ist immer ein Zusammenspiel mehrerer Systeme. Eines der grundlegenden Tools für Anexia ist Ansible. Zusammen mit der Anexia Engine, unserem Kundenportal und zentrale Datenschnittstelle, lässt sich damit ein Großteil der Anforderungen abdecken.


 

Warum Ansible als Automatisierungsframework?

Ansible ist neben Puppet, Chef und SaltStack eines der bekanntesten Automatisierungsframeworks für die derzeit üblichen IT-Systeme. Während Puppet und SaltStack deklarativ arbeiten, funktionieren Ansible und Chef imperativ.

Ein deklarativ arbeitendes System beschreibt den Soll-Zustand explizit. Imperative Systeme beschreiben den Soll-Zustand dagegen implizit. Dies ergibt sich aus den einzelnen Schritten, die vorgenommen werden, um vom Ist- in den Soll-Zustand zu wechseln.

Deklarative vs. Imperative Systeme

 
Imperative Systeme haben Vorteile, wenn es um die zeitliche Abfolge von systemübergreifenden Aufgaben geht. In solchen Fällen kann ein neuer Zustand auf dem einen System erst eingenommen werden, wenn ein anderes System einen bestimmten Zustand erreicht hat. Da Zwischenzustände explizit angegeben werden müssen, lassen sie sich einfach für die Synchronisation von verschiedenen Systemen benutzen.

Neben dem Vorteil des imperativen Zustandes, gibt es weitere Faktoren, die für Anexia ausschlaggebend bei der Wahl von Ansible waren:

  • Agentless. Auf dem Zielsystem muss kein Agent laufen, um mit dem Controller zu kommunizieren.
  • zahlreiche Zielplattformen, u.a. Linux, Windows, Junos, FortiOS, VMware
  • Übersichtlichkeit. Playbooks und Rollen sind mittels YAML strukturiert und dadurch übersichtlich und einfach zu erlernen.
  •  

    Herausforderungen mit Ansible

    Der oft erwähnte leichte Einstieg in Ansible und die Übersichtlichkeit der Playbooks haben allerdings auch einen Haken: Es gibt viele Wege, um ein Problem zu lösen. Während Puppet mit seiner DSL (Domain Specific Language) ein festes Korsett für das zu entwickelnde Manifest vorgibt, hat der Anwender bei Ansible unterschiedliche Möglichkeiten ein Playbook zu entwickeln. Jeder der schon einmal mittels Galaxy nach einer Rolle gesucht hat, kann der folgenden Aussage vermutlich zustimmen:

    “Es macht das was es soll, aber so richtig passt es doch nicht.”

    Um eine gleichbleibende Qualität und die Wiederverwendbarkeit von Playbooks und Rollen sicherzustellen muss vorab viel zusätzlicher Aufwand betrieben werden. Dies sind u.a.:

  • Definition von Style und Naming Guides
  • Entwicklung von Vorlagen für Playbooks/Rollen und deren Dokumentation
  • Entwicklung von CI-Testverfahren
  •  
    Gerade die automatischen Testverfahren sind für die fortlaufende Qualitätssicherung von unschätzbaren Wert. Denn sie unterstützen nicht nur bei der Pflege der Rollen und Playbooks über ihren gesamten Lebenszyklus (Lifecycle), sondern können auch im Bereich des Problemmanagements zum Nachstellen von Störfällen (Incidents) genutzt werden.

    Anexia nutzt molecule zusammen mit Docker und Vagrant um automatisierte Tests über Gitlab CI-Pipelines zu ermöglichen. Wir werden auf dieses Thema in einem eigenen Blogeintrag gesondert eingehen.

     

    Anbindung der Engine an Ansible

    Ein zentrales Problem bei Ansible ist die Erstellung des Inventories, die Liste der Hosts, die es zu verwalten gilt. Agent-basierte Systeme lösen dies oft unter Verwendung des Agents. Das ist mit Ansible nicht möglich.

    Anexia nutzt dafür die Engine, bzw. deren CMDB-Modul. Das CMDB (Configuration Management DataBase) Modul katalogisiert alle Betriebsmittel und verwaltet die Beziehungen der Betriebsmittel untereinander. Durch die CMDB lässt sich z.B. ermitteln, dass eine VM auf dem HyperVisor X läuft und sich dieser am Standort Y befindet. Daraus ergibt sich wiederum, dass die VM ebenfalls am Standort Y läuft.

    Sobald ein System, VM, HyperVisor oder Switch, bei Anexia in Betrieb geht wird es in der Engine erfasst. Mit einem Inventory-Script lassen sich diese Daten vor jedem Run abrufen und somit steht jederzeit eine aktuelle Liste der Systeme zur Verfügung.

    Ansible und Anexia Engine

    In einem ersten Schritt hat Anexia seine internen Systeme, mit Hilfe der Engine, über ein eigenes Inventory erreichbar gemacht und die Basiskonfiguration (Benutzer, Pakete, etc.) dort ausgerollt. Für die HyperVisor-Infrastruktur ist ein ähnliches Projekt im Gange. Dies hat neben der Basiskonfiguration zusätzlich das Ziel, die Bereitstellungszeit zu verringern.

     

    Pläne mit Ansible bei Anexia

    Zukünftig soll die Integration zwischen der Engine und Ansible deutlich ausgebaut werden. Dies wird es Anexia ermöglichen weitere Produkte in die Engine zu integrieren und dem Kunden mehr Self-Service zu ermöglichen.

    Wir informieren euch regelmäßig über die laufenden Entwicklungen der Automatisierung bei Anexia in unserem Blog. Informiert euch in der Zwischenzeit über unsere Anexia Engine.