Jede manuelle Änderung an einer F5 BIG-IP über die Web-UI ist ein doppeltes Risiko: jemand vertippt sich, und niemand weiß genau, was sich geändert hat. Für einen Load Balancer mit Produktivverkehr ist das inakzeptabel. Die Lösung? F5 als Code.
Warum F5
F5 ist führend bei Application Delivery und Security. BIG-IP für Load Balancing, NGINX für modernen App-Verkehr, Distributed Cloud für Schutz über Multi-Cloud. Gemeinsam ist: sie sind kritisch.
Wie wir es machen
Statt in der GUI zu klicken, beschreiben wir den Zielzustand (VIPs, Pools, WAF-Policies) als Code, Ansible (Red Hat AAP) gleicht ab. Secrets kommen aus Vault, der Zielzustand aus NetBox.
- Audit-Spur — jede Änderung hat Commit, Autor und Grund.
- Idempotenz — hundertmal ausführbar, gleiches Ergebnis.
- Tempo — was Tage dauerte, ist in Minuten erledigt.
---
# VIP + Pool auf BIG-IP aus Git erstellen — kein GUI-Klicken
- name: Produktions-VIP konfigurieren
hosts: bigip
connection: httpapi
tasks:
- name: Pool mit Health-Monitor
f5networks.f5_modules.bigip_pool:
name: "pool_billing_443"
lb_method: least-connections-member
monitors: ["/Common/https"]
state: present
- name: Pool-Member hinzufügen (aus NetBox)
f5networks.f5_modules.bigip_pool_member:
pool: "pool_billing_443"
host: "{{ item.ip }}"
port: 443
state: present
loop: "{{ billing_backends }}"
- name: Virtual Server + TLS-Profil
f5networks.f5_modules.bigip_virtual_server:
name: "vs_billing_443"
destination: "10.20.0.15"
port: 443
pool: "pool_billing_443"
profiles: ["clientssl", "http"]
state: presentWichtiger Punkt: state: present macht das Playbook idempotent — hundertmal ausführbar, identisches Ergebnis. Zustand aus NetBox, Secrets aus Vault. Module: F5 Ansible Docs.
Bei einer Umgebung mit 87 VIPs haben wir das F5-Change-Fenster von 4 Stunden (manuelle Änderungen + Change-Tickets) auf einen 12-minütigen auditierten Pipeline-Run reduziert. Illustrative Werte — vor Veröffentlichung verifizieren.
Wo es hakt
- iRules und Legacy-Config. Jahre manueller Edits werden schrittweise überführt.
- Team-Disziplin. Sobald ein Admin „schnell etwas klickt", driften Code und Realität auseinander. Drift Detection ist Pflicht.
Häufige Fragen
Funktioniert das mit unseren iRules und Legacy-Config?
Ja, aber schrittweise. Jahre manueller Edits werden in Wellen in Code überführt, nicht auf einmal. Wir starten mit dem Export des Ist-Zustands, kodifizieren neue Änderungen und migrieren Legacy-Config kontrolliert. iRules lassen sich als Dateien versionieren und über dieselbe Pipeline ausrollen.
Was, wenn jemand „schnell" in der GUI klickt, außerhalb der Pipeline?
Deshalb setzen wir Drift Detection ein — ein geplanter Lauf, der den realen F5-Zustand mit dem Code in Git vergleicht und Abweichungen meldet. Eine manuelle Änderung wird im nächsten Zyklus sichtbar. Team-Disziplin ist nötig, aber das Tool erzwingt sie.
Nur BIG-IP oder auch NGINX und F5 Distributed Cloud?
BIG-IP und NGINX über die offiziellen Ansible-Collections. F5 Distributed Cloud hat eine eigene API, die ebenfalls aus der Pipeline gesteuert werden kann. In der Praxis bauen wir meist eine BIG-IP + NGINX-Kombination.
Brauchen wir Red Hat AAP oder reicht reines Ansible?
Für einen PoC reicht Community-Ansible. Für die Produktion empfehlen wir AAP wegen RBAC, Audit-Spur, Freigabe-Workflows und Credential-Management — genau das, was ein Enterprise-Audit verlangt.
Kämpfen Sie mit manuellen F5-Änderungen?
Buchen Sie ein 20-Minuten-Audit Ihres F5-Estates — wir prüfen VIP-Anzahl, Config-Zustand und einen realistischen Weg zu F5-as-Code. Kein Sales-Pitch, mit einem Senior-Netzwerker.
20-Min-F5-Audit buchen →