Wenn Sie das volle Potenzial der F5 NGINX Management Suite ausschöpfen, kann Ihr Unternehmen die Bereitstellung, Verwaltung und Sicherheit von Apps und APIs vereinfachen. Das neue Infrastructure-as-Code-Projekt (IaC) für die NGINX Management Suite soll Ihnen einen möglichst schnellen Einstieg ermöglichen und zugleich die Best Practices für die von Ihnen gewählte Bereitstellungsumgebung fördern.
Wenn Sie für den Aufbau von Softwareinfrastruktur verantwortlich sind, kennen Sie IaC wahrscheinlich als modernen Ansatz, um konsistente Ergebnisse zu erzielen. Da es jedoch viele Möglichkeiten gibt, eine IaC-Umgebung einzurichten, kann der Einstieg schwierig oder die Erstellung von Grund auf zeitaufwendig sein.
In diesem Blogbeitrag wird das Repository „NGINX Management Suite Infrastructure as Code“ vorgestellt und erläutert, wie Sie die einzelnen Module einrichten und schnell in Betrieb nehmen.
Projektübersicht
Es gibt zwei etablierte Methoden für die Konzeption Ihrer IaC. Eine davon ist der Baked-Ansatz, bei dem Images mit der erforderlichen Software und Konfiguration erstellt werden. Die andere Methode, der Fried-Ansatz, besteht darin, Ihre Server bereitzustellen und sie mithilfe eines Konfigurationsmanagement-Tools kontinuierlich zu konfigurieren. In diesem NGINX-Vortrag<.htmla> erfahren Sie mehr über unveränderliche Infrastruktur, einschließlich der Unterschiede zwischen Baked und Fried Images.
Im IaC-Repository der NGINX Management Suite verfolgen wir den Baked-Ansatz. Dabei verwenden wir Packer, um die Images zu erstellen, und anschließend Terraform, um Instanzen dieser Images bereitzustellen. Durch die Erstellung eines vorgefertigten Images können Sie die Bereitstellung Ihrer einzelnen NGINX Management Suite-Systeme beschleunigen und zugleich die Konsistenz Ihrer Infrastruktur verbessern.
Arbeiten mit dem GitHub-Repository
Die Packer-Ausgabe ist ein Image bzw. eine Maschine, auf dem bzw. der die NGINX Management Suite und alle unterstützten Module installiert sind (zum Zeitpunkt der Erstellung sind dies Instance Manager, API Connectivity Manager, Security Monitoring und Application Delivery Manager). Welche Module Sie nutzen können, hängt von der verwendeten Lizenz ab. Ihre Lizenzinformationen finden Sie im MyF5 Customer Portal. Wenn Sie noch kein Kunde sind, können Sie alternativ eine kostenlose 30-Tage-Testversion von API Connectivity Stack oder App Delivery Stack anfordern, um loszulegen.
Vertrauliche Informationen wie Passwörter oder Zertifikate werden während der Image-Erstellung entfernt. Die Images können mit jedem von der NGINX Management Suite unterstützten Betriebssystem und durch Anpassen der Build-Parameter erstellt werden. NGINX unterstützt verschiedene Cloud- und On-Premises-Umgebungen sowohl für die Image-Erstellung als auch für die Bereitstellung und plant, aktiv weitere hinzuzufügen. Zum Zeitpunkt der Erstellung dieses Dokuments werden die in der folgenden Tabelle aufgeführten Konfigurationen unterstützt.
Cloud Provider | Packer for NGINX Management Suite | Packer for NGINX Plus | Terraform for Basic Reference Architecture | Terraform for Standalone NGINX Management Suite |
AWS | ||||
GCP | ||||
Azure | ||||
vSphere |
Die grundlegende Referenzarchitektur stellt eine Instanz der NGINX Management Suite mit der erforderlichen Anzahl an NGINX Plus-Instanzen bereit. Die bereitgestellte Netzwerktopologie entspricht den Best Practices für den jeweiligen Cloud-Anbieter.
Wenn Sie beispielsweise Amazon Web Services (AWS) verwenden, können Sie die folgende Infrastruktur bereitstellen:
Erste Schritte
Um IaC für NGINX Management Suite zu verwenden, klonen Sie dieses Repository und folgen Sie der README-Datei, um Ihre Images zu erstellen. Für die grundlegende Referenzarchitektur müssen Sie den Packer-Anleitungen folgen, um jeweils ein Image für NGINX Management Suite und NGINX Plus zu erstellen.
Nachdem Sie Ihre Images erstellt haben, können Sie sie zur Bereitstellung Ihrer Referenzarchitektur verwenden. Der Terraform-Stack verwendet sinnvolle Standardeinstellungen und bietet Konfigurationsoptionen, die Sie an Ihre Anforderungen anpassen können.
So können Sie beitragen
Dieses Repository wird aktiv weiterentwickelt und wir freuen uns über Beiträge aus der Community. Weitere Informationen finden Sie in unserem Leitfaden für Beiträge.
Weitere Ressourcen
- Webinar: So führen Sie Infrastructure as Code ein
- Blog: DevOps und unveränderliche Bereitstellung
- E-Book: Security as Code
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.