Eine neue Open-Source-Referenzarchitektur für moderne Anwendungen

NGINX | 24. August 2021

Bei NGINX sprechen wir bereits seit mehreren Jahren darüber, dass Anwendungen wirklich modern und anpassungsfähig sein müssen – portabel, cloudnativ, resilient, skalierbar und einfach zu aktualisieren. In jüngerer Zeit sind zwei Konzepte in den Vordergrund gerückt, die die Entwicklung und Bereitstellung moderner Anwendungen erleichtern. Das erste ist Platform Ops. Dabei stellt ein unternehmensweites Plattformteam alle Tools zusammen, die Entwicklungs- und DevOps-Teams für ihre Arbeit benötigen, und pflegt, vernetzt und schützt sie. Das zweite ist Shifting Left. Das bedeutet, Sicherheit, Netzwerke und Monitoring auf Produktionsniveau bereits in früheren Phasen des Entwicklungslebenszyklus in Anwendungen zu integrieren. Entwickler übernehmen dadurch mehr Verantwortung für Aufgaben, die früher dem IT-Betrieb oblagen, haben zugleich aber auch mehr Auswahlmöglichkeiten und mehr Unabhängigkeit bei der konkreten Umsetzung dieser Aufgaben.

Das klingt zwar gut, doch in der Praxis ist es schwierig, Platform Ops umzusetzen und Infrastruktur- und Betriebswerkzeuge nach dem „Shift-left“-Prinzip in frühere Phasen zu verlagern. Zum einen werden immer mehr Anwendungen stark verteilt, in containerisierten Umgebungen und mithilfe einer der immer zahlreicheren Kubernetes-Orchestrierungsplattformen bereitgestellt. Unternehmen möchten ihre Anwendungen außerdem in mehreren Umgebungen bereitstellen, ohne sich in den Unterschieden zwischen verschiedenen Clouds sowie zwischen Cloud- und lokalen Umgebungen zu verlieren.

Ein „Golden Image“ für moderne Anwendungen

Unsere Kunden und unsere Community bitten uns zu Recht weiterhin um Unterstützung bei den Herausforderungen, vor denen sie stehen. Sie möchten alle Vorteile nutzen, doch all die Komponenten – Sicherheit, Netzwerke, Observability und Performance-Monitoring sowie Skalierung – miteinander zu verbinden, ist mit erheblichem Aufwand verbunden. Die daraus entstehende Plattform robust genug für den Produktivbetrieb zu machen, erfordert noch mehr Arbeit. Sie fragen sich: „Warum gibt es kein ‚Golden Image‘ für moderne Apps, das wir aus einem einzigen Repository heraus bereitstellen können?“

Das ist eine gute Frage, und wir haben es uns zur Aufgabe gemacht, eine überzeugende Antwort darauf zu finden. Zunächst haben wir die Frage konkreter formuliert. Wir glauben, dass unsere Kunden und unsere Community Folgendes wissen möchten: „Könnt ihr uns dabei helfen, verschiedene Softwareprodukte zu einem stimmigeren Ganzen zu integrieren, den Stack so abzustimmen, dass die richtigen Konfigurationen und Einstellungen festgelegt sind, und uns dadurch Arbeit und Aufwand ersparen? Und könnt ihr es uns erleichtern, die Anwendung in verschiedenen Clouds auszuführen, ohne aufgrund von Unterschieden bei den zugrunde liegenden Diensten und Funktionen umfangreiche Konfigurationsänderungen vornehmen zu müssen?“

Wir betrachten eine Lösung, die diese Fragen wirklich beantwortet, als Gewinn für die gesamte Community – nicht nur für unsere Partner in Hunderten von Unternehmen und bei allen großen Cloud-Anbietern. Es ist ein echter Gewinn, bei dem niemand verliert. Im Idealfall ist die Lösung kein „Spielzeug“, sondern robuster, getesteter Code, der für den Einsatz in produktiven Anwendungen in Kubernetes-Umgebungen bereit ist. Und ganz offen gesagt: Wir möchten, dass sich jeder unsere Arbeit direkt von GitHub holen kann.

Um gleich auf den Punkt zu kommen: Heute kündigen wir auf der NGINX Sprint 2.0 die Einführung unserer Lösung an: die erste Version der Referenzarchitektur für moderne Anwendungen (MARA), einer Open-Source-Architektur und eines Bereitstellungsmodells für moderne Anwendungen. Wir hoffen, dass sie Ihnen gefällt, dass Sie sie nutzen und übernehmen und – noch besser – verändern oder forken, um sie zu verbessern oder an Ihre Anforderungen anzupassen. In diesem Beitrag erläutern wir, was wir entwickelt haben und wie es funktioniert.

Die NGINX-Referenzarchitektur für moderne Anwendungen

Definition moderner adaptiver Anwendungen

Definieren wir zunächst die ideale moderne, adaptive Anwendung. Sie kann aus Microservices bestehen, containerisiert sein und Cloud‑native-Designprinzipien folgen (lose gekoppelt, einfach skalierbar, nicht an eine bestimmte Infrastruktur gebunden) – muss es aber nicht. Zum Grundgedanken moderner Anwendungen gehört eine Architektur, die gezielt die Vorteile der Infrastrukturabstraktion nutzt. Diese Definition ist einfach, aber wichtig, da sie die grundlegende Vorlage für alle Referenzarchitekturen bildet.

Zu den wichtigsten Säulen einer modernen Anwendungsarchitektur gehören Portabilität, Skalierbarkeit, Ausfallsicherheit und Agilität.

Portabilität – Die Anwendung lässt sich problemlos auf verschiedenen Gerätetypen und Infrastrukturen, in öffentlichen Clouds sowie in lokalen Umgebungen bereitstellen.
Skalierbarkeit – Die Anwendung lässt sich überall auf der Welt schnell und nahtlos hoch- oder herunterskalieren, um Nachfragespitzen oder -rückgänge zu bewältigen.
Ausfallsicherheit – Die App kann bei einem Ausfall nahtlos auf neu eingerichtete Cluster oder virtuelle Umgebungen in anderen Verfügbarkeitsregionen, Clouds oder Rechenzentren umschalten.
Agilität – Die App kann über automatisierte CI/CD-Pipelines schnell aktualisiert werden. In der Welt moderner Apps bedeutet dies auch eine höhere Entwicklungsgeschwindigkeit und häufigere Code-Bereitstellungen.

Entwurf unserer Referenzarchitektur

Wir wollten eine Plattform schaffen, die die grundlegenden Anforderungen unserer Definition moderner Anwendungen und unseres Bereitstellungsmusters erfüllt. Neben den technischen Zielen wollten wir moderne Prinzipien des Anwendungsdesigns veranschaulichen und unsere Community dazu ermutigen, Anwendungen auf Kubernetes bereitzustellen. Und ja, wir wollten Code zum „Klauen“ anbieten, mit dem Entwickler sowie DevOps- und Platform-Ops-Teams experimentieren, den sie anpassen und weiterentwickeln können. Kurz gesagt, wir wollten Folgendes bieten:

Eine einfach bereitzustellende, produktionsreife Kubernetes-Architektur, die kein Spielzeug ist
Eine Plattform, die veranschaulicht, wie Partnerprodukte auf Kubernetes funktionieren
Eine Schaltfläche zum einfachen Erstellen und Bereitstellen eines Kubernetes-Ingress-Controllers
Eine Testumgebung für zukünftige Produkt- und Partnerintegrationen
Ein modulares Bereitstellungsframework
Ein zentrales Repository mit Open-Source-Code, das die Auffindbarkeit und Einführung vereinfacht

Im Folgenden finden Sie die Design- und Partnerschaftsentscheidungen, die wir für die erste Version der Plattform getroffen haben (unsere Pläne für die nächste Version finden Sie unter „Viele weitere Integrationen und mehr Flexibilität in Version 2“). Wir sind fest davon überzeugt, dass die Einbindung unserer Partner in unsere Referenz-App entscheidend ist, um sowohl das Engagement der Partner als auch das der Community zu fördern.

Open-Source-Entwicklung – https://github.com/nginxinc/kic-reference-architectures/; wir haben das Repository in Zusammenarbeit mit der NGINX/F5-Community erstellt
Bereitstellungsziel – Amazon Elastic Kubernetes Service (EKS)
Infrastructure-as-Code-Automatisierung – Python und Pulumi, das Terraform-Rezepte und Automatisierungsskripte aus nahezu allen gängigen Programmiersprachen unterstützt
Ingress-Controller-Image – vorgefertigtes NGINX Plus-Image für Abonnenten, vorgefertigtes NGINX Open Source-Image auf DockerHub sowie beide Versionen aus dem Quellcode erstellt
Protokollverwaltung (Speicherung und Analyse) – Elastic, da diese Lösung bei unseren Nutzern sehr beliebt ist
Leistungsüberwachung und Dashboards – Prometheus und Grafana
Kontinuierliche Entwicklung (CD) – Spinnaker
TLS – cert-manager
Demoanwendung – Google Bank of Anthos

So wird der Code bereitgestellt

Um die Beispielanwendung zu installieren und bereitzustellen, führen Sie einen einzigen Befehl aus, der das Startskript aufruft. Daraufhin werden die folgenden Pulumi-Projekte in der angegebenen Reihenfolge ausgeführt. Jeder Projektname entspricht einem Verzeichnisnamen relativ zum Stammverzeichnis des Repositorys. Weitere Informationen finden Sie in der README-Datei.

vpc - Defines and installs VPC and subnets to use with EKS  └─eks - Deploys EKS
    └─ecr - Configures ECR for use in EKS cluster
      └─kic-image-build - Builds new NGINX Ingress Controller image
        └─kic-image-push - Pushes image built in previous step to ECR
          └─kic-helm-chart - Deploys NGINX Ingress Controller to EKS 
                             cluster
            └─logstore - Deploys Elastic log store to EKS cluster
              └─logagent - Deploys Elastic (filebeat) logging agent to 
                           EKS cluster
               └─certmgr - Deploys cert-manager.io Helm chart to EKS 
                           cluster
                 └─anthos - Deploys Bank of Anthos application to EKS 
                            cluster

Viele weitere Integrationen und mehr Flexibilität in Version 2

Uns ist bewusst, dass unser erster Ansatz möglicherweise nicht alle Integrationen bietet, die Sie für Ihre Kubernetes-Umgebung benötigen. Bei Platform Ops geht es um eine intelligente – aber nicht unbegrenzte – Auswahl. Damit Platform-Ops-, DevOps- und Entwicklerteams unsere neue Referenzplattform leichter ausprobieren und möglicherweise übernehmen können, planen wir in naher Zukunft zahlreiche Verbesserungen, darunter:

Digital Ocean-, OpenShift-, Rancher-, vSphere- und andere Kubernetes-Umgebungen einrichten
Integration mit NGINX Controller> zur Verwaltung und Überwachung des NGINX Plus Ingress Controllers[Redaktion – NGINX Controller heißt jetzt F5 NGINX Management Suite.]
Bietet eine sofort einsatzbereite Konfiguration für NGINX App Protect
Integration mit F5-Produkten und -Diensten wie BIG‑IP, Cloud Services, und Volterra
Integration mit NGINX Service Mesh und dem Istio-basierten Aspen Mesh
Native Integration mit Terraform und anderen Automatisierungstools
Andere CI/CD-Optionen unterstützen
Separate oder mehrere Cluster für Infrastruktur- und Anwendungsdienste bereitstellen

Wir hoffen, dass unsere Arbeit als Framework für andere Referenzplattformen und als „übernehmbare“ Ausgangsbasis für die Entwicklung verschiedenster differenzierter moderner Anwendungen dienen kann. Da Kubernetes sowohl für die Entwicklung moderner Anwendungen als auch für die Stärkung von Platform Ops und einer Shift-left-Kultur ein äußerst leistungsfähiges Instrument ist, gilt: Je umfassender und erweiterbarer unsere Referenzarchitektur ist, desto besser. Wir sind gespannt darauf, was Sie als Community von unserer Arbeit halten und – noch wichtiger – was Sie damit entwickeln.

Erste Schritte mit der Referenzarchitektur

Laden Sie unsere Referenzplattform herunter und probieren Sie sie aus. Teilen Sie uns mit, was Sie davon halten und was wir als Nächstes entwickeln sollen. Pull Requests sind jederzeit willkommen. Wir freuen uns darauf, gemeinsam mit Ihnen die nächste Generation moderner, anpassungsfähiger und „übernehmbarer“ Anwendungen zu entwickeln, die der Community und allen Entwicklern zugutekommen.