Die Verwendung von CasC mit F5 würde eine versionierte und optional dynamische Netzwerkendpunktkonfiguration ermöglichen, was Zeit spart und Risiken reduziert.
Unterstützt dieses Tool dies? Sind einzelne Konfigurationsdateien (SCF, F5-Begriff) das Fahrzeug, um dies zu tun?
Antworten:
Ja, F5 unterstützen die Konfiguration als Code. In der Vergangenheit hat F5 eine Appliance zum Verwalten der Konfiguration als Code namens "Enterprise Manager" erstellt, die pragmatisch Client-Endpunkt-F5s (LTMs usw.) mithilfe der iControl-XML-API verwaltet.
Sie stellten ziemlich schnell fest, dass diese Management-Appliance schrecklich war, und fügten den Client-Appliances eine robustere REST-API zum Verwalten von Geräten (LTMs usw .; auch als iControl bezeichnet) hinzu, die viel einfacher zu verwenden und flexibler ist, und begannen dann mit dem Erstellen eines Ersatzes für der Enterprise Manager mit der Marke BIG-IQ.
Der Punkt ist, dass Sie dieselbe API über diese REST-Schnittstelle verwalten können. Siehe das Tutorial zu DevCentral . Normalerweise finden Sie die genaue REST-Syntax und Aufrufe auf der DevCentral-Site pro Version wie diese für TMOS 12.1.0 .
Im Allgemeinen wird aus mehreren Gründen NICHT empfohlen, eine SCF (Single Configuration File) zu verwenden. Erstens fehlen unterstützende Dateien wie Zertifikate und Schlüssel für Ihre SSL-Profile oder Skripts (sogenannte "externe" Integritätsmonitore) usw. Zweitens wird die Partitionierung schlecht ausgeführt, da Partitionen über mehrere Dateien in verteilt sind eine Ordnerstruktur. Diese lassen sich nicht gut in einer SCF-Datei konsolidieren. Sie wären eigentlich besser dran, TMOS-Skripte zu schreiben. Einer der Gründe, warum F5 vom Befehl bigpipe zur TMOS-Shell gewechselt ist, besteht darin, dass Skripte erstellt werden können, bei denen Bigpipe nicht einfach zu skripten ist. Aber auch hier wird die REST-API bevorzugt. SCFs sind wirklich ein Erbe von Version 9 von TMOS und sind nicht gut gealtert und funktionieren in Version 12 schlecht. Ein wesentlicher Grund dafür sind die Änderungen im HA-Peering zwischen V10 und V11, als sie zu einer Cluster-Architektur geändert wurden. Es hat die Benutzerfreundlichkeit der SCFs wirklich in Mitleidenschaft gezogen.
Puppet verfügt tatsächlich über ein Modul zum Verwalten von F5s, wenn Sie dieses Konfigurationsverwaltungstool verwenden, und Salt verfügt über einen Runner dafür - beide verwenden die REST-API, wenn Sie eines dieser Konfigurationsverwaltungstools verwenden.
James, Sie haben Recht damit, dass BIG-IQ Enterprise Manager ersetzt hat. Wie Enterprise Manager ist BIG-IQ jedoch für die Verwaltung von Geräten / Funktionen vorgesehen. Für die direkte Integration über REST-APIs oder in Automatisierungstools / Toolketten von Drittanbietern sollten Sie sich F5 iWorkflow (programmierbares / erweiterbares API-Gateway) ansehen.
Das Team hinter iWorkflow konzentriert sich auf "Servicevorlagen" und "Servicekataloge". Dies sind großartige Möglichkeiten, um schnell "deklarative Schnittstellen" zu erstellen, die Sie mit einzelnen REST-Aufrufen erreichen können, anstatt Hunderte von "imperativen Schnittstellen" (einzelne REST-Endpunkte) aufzurufen, um dieselbe Aufgabe auszuführen.
Die Umstellung auf ein deklaratives Modell erspart Ihnen in Zukunft VIELE Kopfschmerzen und unterstützt die Automatisierung und Integration in CI / CD-Pipelines besser. Das LETZTE, was Sie wollen, ist, alle Nuancen Ihrer Infrastruktur in die Automatisierungsleitung selbst zu verschieben !! Abstraktion durch deklarative Schnittstelle schützt Sie vor dieser Grube der Verzweiflung.
Mit deklarativen REST + -Schnittstellen haben Sie eine viel einfachere Infrastruktur als Codemodell, da Sie nur JSON-Blobs für die Servicevorlagen und keine monolithischen Konfigurationsdateien verwalten. Doppelsieg!
Sehen Sie sich an, wie Sie iApps (F5-Servicevorlagen) über die REST-API aufrufen. Hier ist ein kostenloser Online-Schulungskurs:
http://f5-automation-labs.readthedocs.io/en/latest/
Chase = Richtig! Ruhe den ganzen Weg!