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.
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.
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.
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:
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.
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
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:
Integrieren Sie mit NGINX Controller>, um NGINX Plus Ingress Controller zu verwalten und zu überwachen
[ Herausgeber – NGINX Controller ist jetzt F5 NGINX Management Suite .]
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.
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.
Dieser Beitrag ist Teil einer Serie. Wenn wir MARA im Laufe der Zeit um neue Funktionen erweitern, veröffentlichen wir die Einzelheiten im Blog:
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."