Ansible – simpel und flexibel von der Konfig bis zum Rollout
Ansible – simpel und flexibel von der Konfig bis zum Rollout
Die IT-Landschaft der heutigen Zeit wird zunehmend komplexer. Nicht zuletzt durch die stetig steigenden Anforderungen an die notwendigen Sicherheitsmaßnahmen und damit zum Einsatz kommenden Appliances der etwaigen Hersteller.
Simple Hub/Spoke-Firewall-Konstrukte nehmen selbst in ihrer Grundkonfiguration schnell an Komplexität zu, da im Zeitalter des mobilen Arbeitens VPN/Authentication, redundantes SD-WAN mit applikationsbasiertem QoS und flexible NextGen Policies für hybride SaaS-Nutzung mittlerweile zu den Mindestanforderungen unserer Kunden gehören.
Ansible ermöglicht es, diese Konfigurationen dynamisch zu erzeugen und zu verteilen. Die Flexibilität des Tools erlaubt außerdem, die eigene Infrastruktur nach und nach in Code abzubilden, um so agiler auf spezifische Changes zu reagieren und diese skaliert und zuverlässig zu integrieren.
Ansible – a brief history
Der Projektgründer Michale DeHaan entwickelte Ansible anfangs 2012, wie in seinem Blogeintrag the origins of ansible näher beschrieben. Mittlerweile erfreut sich das Open-Source-Projekt über 5000 Contributors und bekommt zusätzlich den Rücken durch Red Hat gestärkt, die ebenfalls eine kommerzielle GUI (Tower) zur Bedienung des CLI-Tools vertreiben. Auch die gängigen Security- und Netzwerk-Hersteller entwickeln mittlerweile kontinuierlich gepflegte, signierte Plugins, die es ermöglichen, die API-Schnittstellen ihrer Komponenten gezielt anzusprechen.
Ansible – simple & flexible
Mit Ansible lassen sich Aufgaben (Tasks) in eine logische Ablaufsequenz (Playbook) zusammenfassen, die sich wiederum gruppieren (Rollen) und gegen definierte Zielsysteme (Inventory) ausführen lassen. Wie in unserem Blogbeitrag Automating Splunk, lassen sich so komplexe System-Setups mit extremer Zeitersparnis nach Best Practices reproduzieren.
Ein solches Ziel bedarf im Grunde genommen nur die Erstellung einer namentlich vorgegebenen Ordnerstruktur mit entsprechenden YAML-Dateien, die ein Playbook repräsentieren. Vorausgesetzt natürlich auf dem Kontroll-Host befindet sich ein Python Interpreter und die installierte Ansible Library, was sich aber mittlerweile für sämtliche gängige Betriebssysteme in einem Einzeiler realisieren lässt.
Über die offiziellen Ansible Galaxy Repositories lassen sich Hersteller spezifische Konnektoren in Form von Collections nachinstallieren. Diese sind meist gut dokumentiert und mit Beispielen versehen. Ursprünglich verbindet sich Ansible via SSH-Protokoll auf sein Zielsystem, doch die Plugins ermöglichen die direkte Kommunikation meist via REST-API oder JSON-RPC-Schnittstelle wie beispielsweise bei Fortigates und dem Fortimanager.
Ansible – dynamic configs
Neben der kurz erwähnten YAML Struktur der Playbooks bringt Ansible von Haus aus eine mächtige Templating Engine mit: Jinja2.
Durch dieses Templating kann man Konfigurationen mit dynamischen Inhalten in sämtlichen Formaten erzeugen. Man kann durch Daten iterieren und konditionale Entscheidungen treffen bspw. passende Konfigurationsabschnitte für statische oder DHCP-Interfaces erstellen, VLAN-Netze auf Basis eines Supernetzes erzeugen, SD-WAN-Regeln auf standortspezifische Bedingungen münzen etc.
Man stelle sich vor Sie stehen mit Ihrem IT-Team vor einem Firewall Rollout an 300 Standorten: Alle dynamischen Konfigurationen wie z.B. Standortnetze, externe IP-Adressen, VPN-Einstellungen uvm. können mit Ansible automatisiert und mit einem Knopfdruck erstellt und gesetzt werden. Die Zeit- und Frustersparnis ist immens!
Als Datenbasis bedient man sich einfach der bereits integrierten Datenbankschnittstellen von Ansible, um Daten aus einer CMDB zu beziehen. Liest klassische CSV- oder xlsx-Dateien ein oder nutzt das von uns präferierte Zusammenspiel einer SSoT- (Single Source of Truth) IPAM/DCIM-Lösung wie etwa NetBox.
Hat man eine entsprechende Konfiguration erzeugt, hält man diese im Anschluss bestenfalls in einer Versionskontrolle vor, zum Beispiel in einer lokalen Gitlab-Instanz. Dieser Schritt lässt sich selbstverständlich ebenfalls als weiterer Task in einem Playbook abbilden. Natürlich möchte man seine Konfigurationen auch auf die entsprechenden Geräte bringen, was auch nur ein weiterer Task ist.
Für die Erzeugung einer Fortigate-Konfiguration sieht der Ablauf am Ende etwa wie folgt aus:
In diesem Beispiel ist AWX die Open-Source-Community-Variante der Red Hat Tower-Instanz. Mit dieser erhält man zusätzliche Features und Möglichkeiten wie etwa User/Access-Kontrolle, Webhooks von und zu Systemen, Notifications, Scheduling und vieles mehr.
Fazit
Ansible allein lässt sich schon ad hoc vielfältig einsetzen und eignet sich besonders bei kleineren, wiederkehrenden Tasks, wie beispielsweise das Ausrollen spezifischer Systempatches oder Firewall-Adressobjekten sowie Verteilen von Policies.
Durch das Zusammenspiel der oben dargestellten Komponenten lassen sich allerdings komplette Infrastrukturen step by step in Code abbilden. Diese wachsen so mit der Zeit zu teils autodokumentierten IT-Landschaften heran und wirken so den allseits bekannten „historisch gewachsenen“ Strukturen entgegen.
