Eine neue, Open Source-Referenzarchitektur für moderne Apps

Bei NGINX sprechen wir seit mehreren Jahren über die Notwendigkeit, Anwendungen wirklich modern und anpassungsfähig zu machen – portabel, Cloud-nativ, belastbar, skalierbar und einfach zu aktualisieren. In jüngerer Zeit sind zwei Konzepte in den Vordergrund gerückt, die die Erstellung und Bereitstellung moderner Apps erleichtern. Das erste ist Platform Ops , bei dem ein Plattformteam auf Unternehmensebene alle Tools kuratiert, wartet, verbindet und sichert, die Entwicklungs- und DevOps-Teams für ihre Arbeit benötigen. Die zweite Möglichkeit ist die „Verschiebung nach links“ , d. h. die Integration von produktionstauglicher Sicherheit, Vernetzung und Überwachung in Anwendungen bereits in früheren Phasen des Entwicklungszyklus. Entwickler tragen mehr Verantwortung für Funktionen, die früher zu ITOps gehörten, haben aber gleichzeitig mehr Auswahlmöglichkeiten und mehr Unabhängigkeit bei der genauen Implementierung dieser Funktionen.

Das klingt zwar gut, in der Realität ist es jedoch eine Herausforderung, Platform Ops zu implementieren und die Infrastruktur- und Betriebstools nach links zu verschieben. Zum einen werden immer mehr Apps hochgradig verteilt, in Containerumgebungen und unter Verwendung einer der immer zahlreicher werdenden Kubernetes-Orchestrierungs-Engines bereitgestellt. Unternehmen möchten ihre Apps außerdem in mehreren Umgebungen bereitstellen, ohne sich durch die Unterschiede zwischen Clouds oder zwischen Clouds und lokalen Umgebungen aufhalten zu müssen.

Ein „Golden Image“ für moderne Apps

Wie vorgesehen bitten unsere Kunden und die Community weiterhin um Hilfe bei den Herausforderungen, vor denen sie stehen. Sie möchten alle Vorteile nutzen, aber alle Teile – Sicherheit, Vernetzung, Beobachtung und Leistungsüberwachung, Skalierung – zusammenzufügen, erfordert echte Arbeit. Um die resultierende Plattform robust genug für Produktionsumgebungen zu machen, ist noch mehr Arbeit erforderlich. Sie fragen sich: „Warum gibt es kein ‚Golden Image‘ für moderne Apps, das wir aus einem einzigen Repo starten können?“

Das ist eine gute Frage und wir haben es als unsere Herausforderung angesehen, eine gute Antwort darauf zu finden. Zunächst haben wir die Frage konkreter formuliert. Wir glauben, dass unsere Kunden und die Community Folgendes fragen: „Können Sie uns helfen, verschiedene Softwareprodukte zu einem stimmigeren Ganzen zu integrieren, den Stack so zu optimieren, dass die richtigen Konfigurationen und Einstellungen festgelegt werden, und uns Arbeit und Ärger ersparen? Und können Sie es einfacher machen, die Anwendung in verschiedenen Clouds auszuführen, ohne aufgrund von Unterschieden bei den zugrunde liegenden Diensten und Funktionen größere Konfigurationsänderungen vornehmen zu müssen?“

Wir sind der Ansicht, dass eine Lösung, die diese Fragen wirklich beantwortet, der gesamten Community zugutekommt – nicht nur unseren Partnern in Hunderten von Unternehmen und allen großen Cloud-Anbietern – und somit ein echter Gewinn ist , bei dem es kein Nullsummenspiel gibt . Im Idealfall ist die Lösung kein „Spielzeug“, sondern solider, getesteter Code, der für die Bereitstellung in Live-Produktionsanwendungen in Kubernetes-Umgebungen bereit ist. Und ehrlich gesagt möchten wir, dass jeder unsere Arbeit direkt von GitHub stehlen kann.

Um es kurz zu machen: Heute geben wir bei NGINX Sprint 2.0 die Einführung unserer Lösung bekannt: die erste Iteration der Modern Apps Reference Architecture (MARA), einem Open-Source-Architektur- und Bereitstellungsmodell für moderne Apps. Wir hoffen, dass es Ihnen gefällt, dass Sie es verwenden, stehlen und – noch besser – es modifizieren oder verzweigen, um es zu verbessern oder anzupassen. In diesem Beitrag erfahren Sie, was wir gebaut haben und wie es funktioniert.

Definition moderner adaptiver Anwendungen

Definieren wir zunächst die ideale moderne, adaptive Anwendung. Es kann aus Mikroservices bestehen, in Containern gespeichert sein und den Cloud-nativen Designprinzipien entsprechen (lose gekoppelt, leicht skalierbar, nicht an Infrastruktur gebunden) – das muss aber nicht so sein. Zum Ethos moderner Anwendungen gehört es, bei der Architektur gezielt die Vorteile der Infrastrukturabstraktion auszunutzen. Diese Definition ist unkompliziert, aber wichtig, da sie die grundlegende Vorlage für alle Referenzarchitekturen darstellt.

Zu den wichtigsten Säulen einer modernen Anwendungsarchitektur zählen Portabilität, Skalierbarkeit, Belastbarkeit und Agilität.

• Portabilität – Die Anwendung lässt sich problemlos auf unterschiedlichen Gerätetypen und Infrastrukturen, in öffentlichen Clouds und vor Ort bereitstellen.
• Skalierbarkeit – Die App kann schnell und nahtlos nach oben oder unten skaliert werden, um Nachfragespitzen oder -rückgänge überall auf der Welt auszugleichen.
• Ausfallsicherheit : Die App kann problemlos auf neu gestartete Cluster oder virtuelle Umgebungen in anderen Verfügbarkeitsregionen, Clouds oder Rechenzentren umsteigen.
• Agilität – Die App kann durch automatisierte CI/CD-Pipelines schnell aktualisiert werden. In der Welt moderner Apps bedeutet dies auch eine höhere Code-Geschwindigkeit und häufigere Code-Pushes.

Entwurf unserer Referenzarchitektur

Wir wollten eine Plattform erstellen, die die grundlegenden Anforderungen unserer modernen App-Definition und unseres Bereitstellungsmusters erfüllt. Abgesehen von den technischen Zielen wollten wir moderne Prinzipien des App-Designs veranschaulichen und unsere Community dazu ermutigen, auf Kubernetes bereitzustellen. Und ja, wir wollten „stehlbaren“ Code anbieten, mit dem Entwickler, DevOps- und Platform-Ops-Teams spielen, den sie ändern und verbessern können. Kurz gesagt, wir wollten Folgendes anbieten:

• Eine leicht einsetzbare, produktionsreife Kubernetes-Architektur, die kein Spielzeug ist
• Eine Plattform, die zeigt, wie Partnerprodukte auf Kubernetes funktionieren
• Ein Druckknopf zum einfachen Erstellen und Bereitstellen eines Kubernetes Ingress-Controllers
• Eine Testumgebung für zukünftige Produkt- und Allianzintegrationen
• Ein steckbares Bereitstellungsframework
• Ein einziges Repository mit Open-Source-Code zur einfacheren Entdeckung und Einführung

Hier sind 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 überzeugt, dass die Einbeziehung aller Partner in unsere Referenz-App der Schlüssel zur Förderung des Engagements sowohl der Partner als auch der Community ist.

• Open-Source-Entwicklung – https://github.com/nginxinc/kic-reference-architectures/ ; wir haben das Repo 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 fast allen gängigen Programmiersprachen akzeptiert
• Ingress Controller-Image – NGINX Plus vorgefertigt für Abonnenten, NGINX Open Source vorgefertigt auf DockerHub und beide Versionen aus dem Quellcode erstellt
• Protokollverwaltung (Speicherung und Analyse) – Elastic , weil es bei unseren Benutzern sehr beliebt ist
• Leistungsüberwachung und Dashboards – Prometheus und Grafana
• Kontinuierliche Entwicklung (CD) – Spinnaker
• TLS – Zertifikatsmanager
• Demo-Anwendung – Google Bank of Anthos

So wird der Code bereitgestellt

Um die Beispielanwendung zu installieren und bereitzustellen, geben Sie einen einzelnen Befehl ein, um das Startskript aufzurufen. Anschließend werden die folgenden Pulumi-Projekte in der angegebenen Reihenfolge ausgeführt. Jeder Projektname wird einem Verzeichnisnamen relativ zum Stammverzeichnis des Repository zugeordnet. Weitere Einzelheiten finden Sie in der README-Datei .

vpc – Definiert und installiert VPC und Subnetze zur Verwendung mit EKS └─eks – Stellt EKS bereit
└─ecr – Konfiguriert ECR zur Verwendung im EKS-Cluster
└─kic-image-build – Erstellt neues NGINX Ingress Controller-Image
└─kic-image-push – Pusht im vorherigen Schritt erstelltes Image zu ECR
└─kic-helm-chart – Stellt NGINX Ingress Controller im EKS-Cluster bereit
└─logstore – Stellt Elastic Log Store im EKS-Cluster bereit
└─logagent – Stellt Elastic (Filebeat) Logging Agent im EKS-Cluster bereit
└─certmgr – Stellt cert-manager.io Helm Chart im EKS-Cluster bereit
└─anthos – Stellt Bank of Anthos-Anwendung im EKS-Cluster bereit

Viele weitere Integrationen und mehr Flexibilität in Version 2

Wir sind uns bewusst, dass unsere anfänglichen Bemühungen möglicherweise nicht alle Integrationen bieten, die Sie für Ihre Kubernetes-Umgebung benötigen. Bei Platform Ops geht es um intelligente – aber nicht unbegrenzte – Auswahlmöglichkeiten. Um es Platform-Ops-, DevOps- und Entwicklerteams einfacher zu machen, unsere neue Referenzplattform auszuprobieren und gegebenenfalls einzuführen, planen wir in naher Zukunft zahlreiche Verbesserungen, darunter:

• Richten Sie Digital Ocean, OpenShift, Rancher, vSphere und andere Kubernetes-Umgebungen ein

• Integrieren Sie mit NGINX Controller>, um NGINX Plus Ingress Controller zu verwalten und zu überwachen

  [ Herausgeber – NGINX Controller ist jetzt F5 NGINX Management Suite .]

• Bereitstellung einer sofort einsatzbereiten 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 Istio-basiertem Aspen Mesh
• Native Integration mit Terraform und anderen Automatisierungstools
• Unterstützt andere CI/CD-Optionen
• Bereitstellen separater oder mehrerer Cluster für Infrastruktur- und Anwendungsdienste

Wir hoffen, dass unsere Arbeit als Rahmen für andere Referenzplattformen und als „stehlbarer“ Ausgangspunkt für die Entwicklung aller Arten differenzierter moderner Anwendungen dienen kann. Da Kubernetes ein äußerst leistungsstarker Mechanismus sowohl für die Erstellung moderner Anwendungen als auch für die Stärkung von Platforms Ops und der Shift-Left-Kultur ist, ist es umso besser, je umfassender und integrierbarer unsere Referenzarchitektur ist. Wir sind gespannt, was Sie, die Community, von unserer Arbeit halten und – noch wichtiger – was Sie daraus machen.

Erste Schritte mit der Referenzarchitektur

Laden Sie unsere Referenzplattform herunter und probieren Sie sie aus. Teilen Sie uns Ihre Meinung mit und sagen Sie uns, was wir als Nächstes bauen sollen. Pull Requests sind mehr als willkommen. Wir möchten gerne mit Ihnen bei der nächsten Generation moderner, anpassbarer und „stehlbarer“ Anwendungen zusammenarbeiten, die der Community und allen Entwicklern etwas zurückgeben.

Verwandte Artikel

Dieser Beitrag ist Teil einer Serie. Wenn wir MARA im Laufe der Zeit um neue Funktionen erweitern, veröffentlichen wir die Einzelheiten im Blog:

• Eine neue, Open Source Referenzarchitektur für moderne Apps (dieser Beitrag)
• Integration von OpenTelemetry in die Modern Apps Reference Architecture – Ein Fortschrittsbericht
• MARA: Läuft jetzt auf einer Workstation in Ihrer Nähe
• Ankündigung der Version 1.0.0 der NGINX Modern Apps Reference Architecture