In Gesprächen mit unseren Kunden im vergangenen Jahr sind uns einige wiederkehrende Themen aufgefallen, die sie dazu veranlassen, Orchestrierungsprodukte wie den NGINX Controller zu evaluieren:
- Komplexität – Die Verwaltung, Pflege, Validierung und Anwendung großer Mengen einzelner Konfigurationsobjekte aus unterschiedlichen Quellen ist nicht einfach.
- Fragilität – Eine Skalierung kann schnell erfolgen, häufig als Reaktion auf ein Ereignis. Manchmal ist sie strategisch geplant, doch wie so oft in operativen Abteilungen erfolgt sie ungeplant und organisch.
- Sicherheit – Fehler zu vermeiden und Probleme vor der Bereitstellung in der Produktionsumgebung zu erkennen, sind Grundpfeiler der agilen Methodik. Sie tragen außerdem dazu bei, Komplexität und Fragilität zu reduzieren.
Mit diesen Problemen sind Kunden bei der erstmaligen Bereitstellung einer Anwendung in der Regel nicht konfrontiert. Vielmehr treten sie im Laufe der Zeit auf, wenn die Anwendung erfolgreich wird und skaliert werden muss. Unserer Erfahrung nach ist die Skalierung – genauer gesagt die ungeplante Skalierung – die gemeinsame Hauptursache der oben aufgeführten Probleme.
Glücklicherweise berücksichtigt das Konfigurationsobjektmodell von NGINX Controller alle drei Aspekte:
- Sie reduziert die Komplexität der Bereitstellung, indem sie alle Konfigurationskomponenten, die sich auf eine bestimmte Gruppe von NGINX Plus-Instanzen auswirken könnten, an einem zentralen Ort zusammenführt.
- Sie reduziert die Fehleranfälligkeit, indem Teams Konfigurationen validieren und testen können, bevor sie in die Produktionsumgebung übernommen werden. Dadurch lassen sich Fehler frühzeitig erkennen und der Datenverkehr der Benutzer in der Produktionsumgebung kann ungehindert weiterfließen.
- Es fördert die Sicherheit, da es äußerst flexibel ist. Anstatt Sie dazu zu zwingen, Ihre Prozesse an das Modell anzupassen, ist das Konfigurationsobjektmodell darauf ausgelegt, sich an Ihren Geschäftsabläufen und Ihrer Aufgabenverteilung zu orientieren. So können Sie verschiedenen Geschäftsbereichen je nach Bedarf die entsprechende Verantwortung für Konfigurationselemente übertragen.
Controller-Konfigurationsobjekte
Sehen wir uns einige wichtige Konfigurationsobjekte etwas genauer an, damit Sie besser verstehen, wie das Controller-Modell funktioniert.
Umgebungen
In den meisten Unternehmen durchläuft Software vor der Veröffentlichung mehrere Phasen: Entwicklung, Benutzerakzeptanztests, Vorproduktion, Produktion und weitere Phasen der Qualitätsprüfung. Diese Phasen entsprechen dem NGINX-Controller-Objekt, das als „Environment“ bezeichnet wird.
Eine Umgebung ist ein isolierter Bereich für Konfigurationselemente innerhalb von Controller. Üblicherweise wird auf dieser Ebene die rollenbasierte Zugriffskontrolle (RBAC) definiert. In Umgebungen können identische Konfigurationsartefakte die verschiedenen Phasen durchlaufen, wobei nur minimale Änderungen vorgenommen werden, etwa an Zielservern, Rechenzentren und anderen Infrastrukturobjekten, die sich üblicherweise je nach Umgebung unterscheiden.
Gateways
Ein Gateway ist ein Konfigurationsobjekt innerhalb einer Umgebung und wird häufig als oberste Ebene verwendet, um festzulegen, wie Anwendungen für Kunden bereitgestellt werden – etwa durch Einstellungen für Hostnamen, Protokoll und TLS/SSL-Verhalten. Solche Einstellungen können jedoch auch auf einer niedrigeren Ebene vorgenommen werden. In der Praxis sind Gateway-Objekte meist den Netzwerkbetriebsteams (NetOps) zugeordnet, also den Mitarbeitern, die Netzwerkgeräte am Netzwerkrand oder in der DMZ verwalten. Gateways verwenden außerdem das Konzept der „Platzierung“. Damit werden der Controller und die NGINX Plus-Instanzen verknüpft, die die Konfigurationen empfangen und die eigentliche Arbeit ausführen.
Apps
Auf der nächsttieferen Ebene befindet sich das App-Konfigurationsobjekt, in dem Sie mit der Modellierung von Anwendungen und der Gruppierung von Verhaltensweisen zur Datenverkehrssteuerung beginnen. Sie können so viele oder so wenige Apps verwenden, wie für die Anforderungen Ihrer Organisation erforderlich sind. Die einzige Voraussetzung ist, dass eine App innerhalb einer Umgebung eindeutig sein muss.
Komponenten
Innerhalb einer App beschreiben Komponenten das gewünschte Verhalten der Datenverkehrssteuerung für die App. Im einfachsten Fall wird der gesamte Datenverkehr für einen bestimmten Pfadnamen an dieselbe Servergruppe gesendet. Komponenten steuern jedoch auch erweiterte Funktionen wie die Bearbeitung von Headern, das Umschreiben von URLs, das Load-Balancing-Verhalten im Backend, die Cookie-Verarbeitung und weitere Einstellungen. Auch das Verhalten von Hostnamen und TLS/SSL kann auf dieser Ebene definiert werden.
Alles zusammenführen
Hier ist eine visuelle Darstellung der Beziehung zwischen den Konfigurationsobjekten:
Beachten Sie, dass nur zwei Gruppen mit Controller interagieren – in diesem Fall zwei Entwicklungsteams: Referral und Transfers. Tatsächlich ist die Zahl der an der Anwendungsbereitstellung und -sicherheit beteiligten Personen wahrscheinlich wesentlich größer und umfasst unter anderem die Bereiche Netzwerk und Sicherheit (Platform Ops), DevOps und Anwendungsentwicklung. Die Teams mit dem größten Fachwissen können Richtlinien festlegen und Self-Service-Workflows erstellen, die Best Practices entsprechen und Leitplanken für jene Teams bieten, die mit Apps, Komponenten und Gateways innerhalb der „Dev“-Umgebung arbeiten, die sich über die Rechenzentrumsstandorte der Organisation im Osten und Westen erstreckt.
Betrachten wir dies einmal aus einem etwas anderen Blickwinkel, nämlich stärker aus der Perspektive eines Geschäftsbereichs (Line of Business, LOB). Die Verantwortlichen der Geschäftsbereiche treffen zunehmend Anwendungsentscheidungen für moderne Apps.
Das folgende Diagramm veranschaulicht ein realistischeres Szenario mit einem wesentlich größeren Benutzerkreis, zu dem verschiedene Geschäftsbereichsteams sowie Shawn gehören, der für die Verlängerung sämtlicher Zertifikate zuständig ist.
Nun wirken sich mehr einzelne Akteure und Pipelines auf den daraus resultierenden Datenfluss aus.
Während jede einzelne Pipeline die verschiedenen Objektänderungen von der Versionsverwaltung (z. B. GitHub) bis zum Controller durchläuft, werden die Konfigurationsobjekte auf der Controller-Seite validiert und anschließend mit allen zugehörigen Objekten zusammengeführt, bevor die Änderungen an die NGINX Plus-Instanzen übertragen werden.
Auf diese Weise kann Controller dazu beitragen, das Konfigurationsmanagement sicherer zu machen: Es wird sichergestellt, dass die neuesten Änderungen mit früheren Einstellungen sowie mit den Einstellungen anderer Anwendungs- und Geschäftsbereichsverantwortlicher kompatibel sind.
Uns ist bewusst, dass in der Praxis alle Konfigurationen, die auf eine einzelne NGINX Plus-Instanz angewendet werden, möglich sein müssen – die Einstellungen dürfen jedoch weder miteinander in Konflikt stehen noch sich überschneiden oder gegenseitig beeinträchtigen. Außerdem ist es wichtig, Konflikte frühzeitig zu erkennen und die Personen zu informieren, die die Konfiguration der einzelnen Komponenten bereitstellen.
Im obigen Beispiel wird sofort ein Pfadkonflikt erkannt, wenn die Referral-Komponente versucht, dasselbe Regex-Muster zu verwenden, das bereits von der Transfers-Komponente implementiert wurde. So kann das Referral-Team lange vor dem Versuch, diese Konfiguration in der Produktionsumgebung bereitzustellen, benachrichtigt werden – und die zahlreichen Probleme, die mit einer Fehlkonfiguration einhergehen, lassen sich vermeiden.
Was Zertifikate betrifft, ist Shawn dank der RBAC-Funktionalität von Controller in der Lage, Zertifikatsänderungen sofort umzusetzen. Die Verantwortlichen für das Gateway und die Komponenten müssen lediglich auf die richtigen Zertifikate verweisen, während Shawn deren Lebenszyklus zuverlässig verwalten kann. Wenn Shawn ein Zertifikat in Controller aktualisiert, wird es an die richtigen Instanzen verteilt – ohne die Panik, die mit dem Ablauf eines Zertifikats einhergeht.
Da NGINX Controller nun über alle Ihre Konfigurationsobjekte und eine Placement-Zuordnung zu einer oder mehreren NGINX Plus-Instanzen verfügt, kann es die letzten Schritte ausführen: die Konfiguration anwenden.
Sicherheit in der Praxis
Letztendlich besteht das Ziel des Konfigurationsmanagements mit Controller darin, die richtige Konfiguration auf die richtigen NGINX Plus-Instanzen am richtigen Standort anzuwenden. Wenn sichergestellt ist, dass Apps, Komponenten, Gateways sowie alle zugehörigen Zertifikate und Instanzen korrekt konfiguriert sind, werden Bereitstellungen sicherer und besser skalierbar.
Diese abschließende Überprüfung ist der letzte Teil des Konfigurationsverwaltungsprozesses, den Controller einfacher und sicherer gestaltet. Die gesamte Konfiguration wird bei der Anwendung auf eine NGINX Plus-Instanz überprüft, bei der ein zugehöriges Objekt geändert wurde – beispielsweise die Sitzungspersistenz in einer Web-Workload-Gruppe für NGINX Plus, das als Proxy bereitgestellt wurde. Dadurch wird sichergestellt, dass die Instanz mit der gewünschten Konfiguration kompatibel ist. Ist diese Bedingung erfüllt, wird die Konfiguration angewendet. Als letzte Sicherheitsmaßnahme setzt Controller die Instanz auf eine vorherige Konfiguration zurück, falls beim Anwenden der Konfiguration ein Fehler auftritt.
Controller stellt nicht nur sicher, dass Konfigurationen die Prüfung bestehen, sondern kann beim Anwenden einer neuen Konfiguration auch erweiterte NGINX-Funktionen wie das kontrollierte Beenden von Sitzungen nutzen. So bleiben Verfügbarkeit und Leistung der Websites auch während Änderungen gewährleistet.
Für Betriebsteams tragen die oben beschriebenen Konzepte und Workflow-Designs zur Sicherheit bei, die NGINX Controller bei der Konfigurationsverwaltung bietet. Diese Schutzmechanismen helfen dabei, die Workflows und die verschiedenen Teams, die mit modernen Anwendungen arbeiten, aufeinander abzustimmen und zugleich die geschäftlichen Anforderungen zu erfüllen.
Wenn Sie NGINX Controller ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Ü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.