Marc Eberle Mit zunehmender Digitalisierung werden Automatisierungswerkzeuge unverzichtbar. Eines davon ist Ansible, eine beliebte Lösung, die dank agentenloser und plattformunabhängiger Architektur die Möglichkeit bietet, die Automatisierung auf verschiedenen Plattformen nicht nur aus-, sondern auch zusammenzuführen. Dabei werden Hypervisoren wie VMware, Cloud-Produkte wie Microsoft Azure oder auf Linux und Microsoft basierende Systeme unterstützt. Automatisieren lässt sich hierbei vieles: von der einfachen Software-Installation über das Patchen von Systemen und Komponenten und die Provisionierung von einzelnen Subkomponenten bis hin zur Konfiguration von Komponenten zur Erreichung von Compliance-Richtlinien und Sicherheitsstandards.
Schlagen wir nun den Bogen zum Netscaler: Da Netscaler ein Netzwerkprodukt ist, das sich durch viele Funktionen und eine nicht ganz triviale Konfiguration auszeichnet, ist es durchaus sinnvoll, Ansible für die Automatisierung redundanter Aufgaben in verschiedenen Konfigurationen einzusetzen. In diesem Blogbeitrag werde ich die Möglichkeiten einer Integration näher beschreiben und einen ersten Einblick liefern, wie diese am Ende aussehen kann.
Sollte Ihnen der Begriff Netscaler bisher neu sein, verweise ich sehr gerne auf den Podcast meiner Kollegen: Citrix Netscaler: Vier Namen, ein Produkt (sva.de).
Inhaltsverzeichnis
- Warum sollte ein Netscaler automatisiert werden?
- Ansible kann verschiedene Produkte zusammenführen
2.1. Anwendungsfälle
2.1.1. Fallbeispiel 1: Aktivieren von Modulen über die Netscaler Ansible Collection
2.1.2. Fallbeispiel 2: Betriebsbereites Deployment eines Netscaler VPX auf Hyper-V - Technischer Deep Dive
3.1. Die Umgebung
3.2. Installation von Ansible und der Netscaler-Collection
3.2.1. Installation der Netscaler-Collection
3.2.2. Das Inventory File und Group Vars
3.3. Fallbeispiel 1: Aktivieren von Modulen über die Netscaler Ansible Collection
3.4. Fallbeispiel 2: Betriebsbereites Deployment eines Netscaler VPX auf Hyper-V
3.4.1. Playbook 2.1 – Hyper-V Deployment
3.4.2. Playbook 2.2 – Ändern des Standard-Passworts - Fazit
1. Warum sollte ein Netscaler automatisiert werden?
Wer viele Netscaler gleichzeitig betreut, kennt die verschiedenen Herausforderungen: Muss ich mich bei Änderungen auf jeden einzelnen Netscaler draufschalten? Konfiguriere ich jedes Gateway manuell per Hand? Und muss ich bei jedem Update manuell die Firmware hochladen und installieren?
Jeder, der diese Aufgaben schon erledigt und sich genau diese Fragen gestellt hat, weiß, wie sehr Automatisierung in diesem Bereich helfen kann. Ja, es gibt bereits viele Tools wie z. B. Netscaler ADM, welcher große Vorteile im Netscaler Management bietet und auch sehr gut im Bereich TLS Zertifikatsmanagement oder Updatemanagement helfen kann. Auch besteht die Möglichkeit, Netscaler über Terraform auf verschiedene Plattformen (Cloud, on-premises) zu deployen. (Mehr Informationen dazu im Blogbeitrag Citrix ADC – Automation via Terraform – SVA). Wie also kann uns Ansible zusätzlich bei der Automatisierung unterstützen?
2. Ansible führt verschiedene Produkte zusammen
Nehmen wir einen Netscaler, der mittels einer virtuellen Plattform wie Hyper-V oder VMware bereitgestellt wurde. Eine Integration von Ansible und Netscaler ist bereits heute mit der vom Hersteller bereitgestellten Ansible Collection möglich: netscaler/ansible-collec onnetscaleradc: Custom Ansible modules for NetScaler ADC and NetScaler ADM (github.com).
Dabei kann z.B. der Hypervisor mit SSH (dem Secure Shell Protocol) und Powershell sowie der Netscaler über die Nitro-Schnittstelle oder alternativ ebenso über SSH und die Kommandozeile angesprochen werden. Ansible arbeitet hierbei verschiedene Schritte nacheinander auf verschiedenen Plattformen ab, um das gewünschte Ziel zu erreichen. Wenn auf Ebene des Hypervisors ein Snapshot einer VM vorgenommen wird, lässt sich vorab das entsprechende System per Ansible konfigurieren und danach die gewünschten Änderungen direkt auf dem Gastsystem vornehmen, sodass die Änderungen im Fehlerfall schnell zurückgespielt werden können. Auch ist es möglich, dass der gewünschte Snapshot nach einer gewissen Zeit automatisch gelöscht wird.
Bei einem Netscaler gilt es jedoch zu beachten, dass nicht, wie in großen Teilen bei Ansible üblich, der Ansible Host direkt auf den Client zugreift, um den oder die Netscaler zu konfigurieren, sondern dies über die Nitro-Schnittstelle tut. Hierfür gibt es – Stand heute – hunderte Module, mit denen man mehr oder weniger direkt arbeiten kann. So lässt sich beispielsweise auch die Konfiguration mit Modulen, den sogenannten Ansible Playbooks, abbilden.
Alternativ ist es möglich, direkt mit den Netscalern zu arbeiten und sich über SSH oder SCP (Secure Copy Protokoll) zu verbinden, um die gewohnten administrativen Befehle zu nutzen. Allerdings bleibt dabei viel Potenzial auf der Strecke: Die Idempotenz.
Diese sorgt dafür, dass ein Modul oder eine Funktion auch bei mehrmaliger Anwendung das Ergebnis nicht verändert. Soll heißen: Wenn der Hostname einer Maschine geändert wurde, erkennen dies gut geschriebene Module und werden den zugrundeliegenden Befehl nicht erneut ausführen, wenn dieser bereits angewendet wurde.
Im Endeffekt bedeutet das: Entweder findet man selbst Mittel und Wege, um dieser Herausforderung mit Geschick zu begegnen (Schreibe ich zum Beispiel ein Skript, um vorab den zu setzenden Wert zu überprüfen?). Oder man schaut, welche Module auf dem Markt vorhanden sind und bedient sich daraus.
2.1 Anwendungsfälle
2.1.1 Fallbeispiel 1: Aktivieren von Modulen über die Netscaler Ansible Collection
Beschrieben wird die rudimentäre Einrichtung eines Ansible Hosts und das erfolgreiche Starten eines einzelnen Ansible Playbooks. Dabei soll grundlegend erklärt werden, wie die Netscaler Ansible Collection von Citrix funktioniert.
2.1.2 Fallbeispiel 2: Betriebsbereites Deployment eines Netscaler VPX auf Hyper-V
Ein weiteres Playbook, um auf einer Hyper-V-Plattform einen Netscaler autonom zu deployen, sodass die Netzwerk- und Benutzerkonfiguration automatisch und wiederholbar vorgenommen wird. Dabei wird unter anderem die Netscaler Ansible Collection verwendet, um das Standard-Passwort und den Benutzer zu ändern sowie SSH, um über Powershell auf einen Hyper-V-Host zuzugreifen. Weiterhin kommen für die ISO-Erstellung bestehende Linux-Tools zum Einsatz, sodass die Netzwerkkonfiguration der VPX automatisiert werden kann.
Das Zusammenspiel zwischen Hypervisor und einem Netscaler als virtuelle Maschine soll zeigen, dass man sehr viele Anwendungsfälle auch plattformübergreifend realisieren kann. Dabei zeigen sich auch die Vorteile von Jinja-Templates, bei denen Dateien oder Skripte auf den jeweiligen Anwendungsfall per Variablen modifiziert werden können. Ein Beispiel ist in den kommenden Abschnitten enthalten.
Bitte beachten Sie: Hier beginnt die technische Ausarbeitung dieses Blog-Artikels. Grundlegende Ansible- und Netscaler-Kenntnisse werden vorausgesetzt. Bei Fragen stehe ich gerne zur Verfügung.
3. Technischer Deep Dive
3.1 Die Umgebung
Folgende Maschinen werden im Szenario verwendet:
| VM | Beschreibung |
|---|---|
| ADC01 | Citrix Netscaler VPX |
| ANSIBLE01 | Ubuntu 22.04 als Ansible-Host |
| HYP | Windows Server 2022, Nested Virtualization Hyper-V Host |
| ADC02 | Nested Citrix Netscaler VPX |
3.2 Installation von Ansible und der Netscaler-Collection
3.2.1. Installation der Netscaler-Collection
Alternativ kann direkt über Git installiert werden:
Das Überprüfen der Version ist mit folgendem Befehl möglich:
Damit hätten wir alle notwendigen Module installiert, die wir für den Start benötigen.
3.2.2 Das Inventory File und Group Vars
Das Inventory File definiert und gruppiert die verwalteten Systeme. Die Variablen, die für alle Gruppen gelten, werden unter [all:vars] gelistet.
3.3 Fallbeispiel 1: Aktivieren von Modulen über die Netscaler Ansible Collection
Das Ziel unseres ersten Playbooks soll sein, unsere Konfiguration zu überprüfen und uns langsam in die Ansible Collection einzuarbeiten. Wichtig ist auch hier wieder: Das Playbook wird auf dem lokalen Ansible Host ausgeführt, der über die Nitro-Schnittstelle auf den Netscaler zugreift und diesen konfiguriert. Dank dieses eher rudimentären Playbooks können wir hier schnell erste Ergebnisse sehen.
Vor der Ausführung des Playbooks
Die Ausführung des Playbooks
Nach der Ausführung des Playbooks
3.4 Fallbeispiel 2: Betriebsbereites Deployments eines Netscaler VPX auf Hyper-V
In diesem Playbook wird die virtuelle Appliance auf einem Hyper-V-Host heruntergeladen sowie eine ISO-Datei mit einer XML erstellt, welche die notwendigen Netzwerkeinstellungen beinhaltet. Nach dem Import der virtuellen Maschine wird der Name geändert und diese automatisch gestartet. Dabei wird die Netzwerkkonfiguration des virtuellen Netscalers von der XML-Datei auf der ISO ausgelesen und angewendet. Nach etwa zwei Minuten ist die Maschine erstellt und fährt automatisiert hoch. Mit einem weiteren Playbook kann das initiale Passwort geändert und im Anschluss mit dem frisch gesetzten Passwort über die GUI verbunden werden.
Die ISO wird mittels eines Jinja-Templates erstellt, sodass das Playbook für jeweils verschiedene Netscaler verwendet werden kann, da die Netzwerkeinstellungen jeweils per Variable gesetzt werden. In diesem Beispiel werden in der userdata.j2 alle Variablen in der Form {{variable}} durch richtige Werte ausgetauscht, sodass in der entstehenden userdata.xml eine funktionierende Konfiguration mit dem vorher definierten Wert erreicht wird.
Die ISO wird mittels eines Jinja-Templates erstellt, sodass das Playbook für jeweils verschiedene Netscaler verwendet werden kann, da die Netzwerkeinstellungen jeweils per Variable gesetzt werden. In diesem Beispiel werden in der userdata.j2 alle Variablen in der Form {{variable}} durch richtige Werte ausgetauscht, sodass in der entstehenden userdata.xml eine funktionierende Konfiguration mit dem vorher definierten Wert erreicht wird.
{{nsip}}, {{nsnetmask}} und {{nsgw}} werden zu “172.16.10.165”, “255.255.255.0” und “172.16.10.254” umgewandelt.
Mehr Infos: Install a NetScaler VPX instance on Microso Hyper-V server
3.4.1 Playbook 2.1 – Hyper-V Deployment
Dieses Playbook beschreibt, welche Schritte auf den Systemen ausgeführt werden, um die beteiligten Komponenten auf den gewünschten Konfigurationsstand zu bringen. In diesem Fall werden direkte Befehle und auch ein Ansible Modul auf dem Ansible Host und auf dem Hyper-V-Host ausgeführt.
3.4.2 Playbook 2.2. – Ändern des Standard-Passworts
In diesem Playbook wird nach dem ersten Booten des Netscalers das Standard-Passwort mittels Nitro-API gesetzt.
Nun können wir uns erfolgreich auf der GUI anmelden oder auch mit weiteren Playbooks unsere Konfiguration auf diesem Netscaler ausrollen.
4. Fazit
Der große Vorteil an Ansible ist aus meiner Sicht die Flexibilität sowie die Möglichkeit, einzelne immer wiederkehrende Schritte zu automatisieren. Dabei zeigt Ansible, dass es eine universelle Lösung für gewisse Automatisierungsanforderungen geben kann, welche unabhängig von den einzelnen Eigenschaften und Beschränkungen von Systemen agiert. Je nach Anwendungsfall kann relativ schnell ein erster Proof-of-Concept erstellt werden. Dabei kann sowohl auf bestehende Collections zurückgegriffen werden als auch eine direkte Systemansprache erfolgen.