HCS erstellt mit NGINX eine flexible Front-End- Application

Eine nationale Regierungsbehörde in den Niederlanden mit einem vielfältigen Spektrum an Interessengruppen und Benutzern wollte ihre Arbeitsabläufe von papierbasierten Prozessen auf eine moderne digitale Infrastruktur umstellen. Dadurch könnte die Agentur schneller agieren und das Leben ihrer Benutzer und Mitarbeiter vereinfachen.

Die Herausforderung? Die Agentur gestattete jeder teilnehmenden Gemeinde, relativ eigene Prozesse und Anforderungen zu entwickeln. Zunächst hatte die Agentur große Anstrengungen unternommen, um eine allumfassende monolithische Application mit zahlreichen Anpassungen zu erstellen. Der erste Versuch scheiterte unter der Last der Hyper-Customization – „Tod durch tausend Anforderungen“. HCS Company , ein auf Open Source- und Red Hat®-Technologien spezialisiertes niederländisches IT-Beratungsunternehmen, wurde beauftragt, mit einem anderen Ansatz neue Wege zur Digitalisierung der Prozesse der Agentur zu erproben.

Einfacher Wiederaufbau: Zusammensetzbare Micro-Frontends, Container und Microservices

Das DevOps-Team der Agentur arbeitete an dem Projekt mit Benoit Schipper, Lead Site Reliability Engineer (SRE) bei HCS. Gemeinsam betrachteten sie zunächst das Problem, das sie lösen wollten, genauer. Benutzer – von Regierungsbeamten bis hin zu Anwälten, Buchhaltern und normalen Bürgern – müssen sich bei der Agentur-App anmelden, den Status eines Projekts oder Prozesses überprüfen und eine PDF-Datei hochladen. Benoit und das Team beschlossen, als Ausgangspunkt für die Lösung ein einfaches Fundament zu bauen. Benoit erklärt: „Wir haben uns das angesehen und gesagt: ‚Lasst uns etwas ganz Allgemeines machen, und für alle Sonderwünsche können wir auf dieser allgemeinen Grundlage aufbauen.‘“ Das DevOps-Team wollte die Grundlage außerdem zukunftssicher machen und Skalierbarkeit sowohl innerhalb der vorhandenen Infrastruktur als auch für zusätzliche Standorte und Applications sicherstellen, die in Zukunft möglicherweise benötigt werden.

Benoit und das Team entwarfen diese Zukunft auf einem Whiteboard und entwickelten eine neuartige Architektur mit sehr kleinen (Mikro-)Frontends, die zu unterschiedlichen Applications zusammengesetzt werden können, die wiederum kleinen, unterschiedlichen Diensten (Mikroservices) im Backend zugeordnet sind. „Wir haben uns für Microservices entschieden, weil man mit dieser Architektur für den Wechsel in die Cloud und die Skalierung bei großen Umsätzen bereit ist“, sagt Benoit. „Wir haben das Puzzle in kleinere Teile zerlegt, die wir zusammenkleben konnten.“

Die erste Entscheidung im Zusammenhang mit der Implementierung bestand darin, von Microsoft Windows-Servern in einer dedizierten Umgebung zu einer containerbasierten Umgebung in der Cloud zu wechseln, die sich besser für zusammensetzbare und flexible Mikroservices eignet. Das Team entschied sich für Red Hat OpenShift® als Containerplattform.

Zwei starke Faktoren sprachen für OpenShift. Erstens war es aufgrund der langjährigen Erfahrung von RedHat in der Zusammenarbeit mit Regierungen einfach, die behördliche Genehmigung für das Design zu erhalten. Zweitens umfasst OpenShift viele Tools und Applications , die für die einfache Erstellung und Wartung von Microservices und Microservices-Architekturen entwickelt wurden, darunter:

• Red Hat Ceph® Storage – Ein Blob-Speicherdienst, auf den über eine S3-kompatible API zugegriffen werden kann
• Red Hat AMQ Broker – Ein Nachrichtenbusdienst zum Verwalten der Arbeitslast und des Application sowie zum Einreihen von Workern in die Warteschlange
• Integrierter, zertifizierter Support für Kubernetes – wichtig für die weitere Zukunftssicherheit, wenn HCS und die Agentur entscheiden, dass Kubernetes das richtige Tool für die Container-Orchestrierung ist

Von Windows zu Linux, .Net Core und NGINX Open Source

Die Umstellung auf Container bedeutete, dass das bisherige .Net-Backend der Agentur, das auf Windows-Servern lief, ersetzt werden musste. Glücklicherweise war der Übergang zu .Net Core , einer für Container optimierten Version von .Net, problemlos. Ein zusätzlicher Vorteil besteht darin, dass die Entwickler der Agentur weiterhin in den ihnen vertrauten Windows- Application und Frameworks programmieren können.

Das DevOps-Team hat einen Kernsatz von REST-APIs für den Zugriff auf die .Net Core-Backend-Dienste erstellt. Die APIs sind der Klebstoff, der die Funktionalität und Logik der Application sowie die Mikro-Frontends zusammenhält. Für die Front-End-Umgebung entschied sich das Team für AngularJS , da es bei Regierungsorganisationen als robustes, zuverlässiges JavaScript-Framework mit einer starken Community weithin akzeptiert ist.

Um eine zusammenhängende Routing-Schicht für den Datenverkehr und die API-Aufrufe zwischen Front- und Back-End zu erstellen, untersuchte das Team verschiedene Optionen, bevor es sich aufgrund seiner Vielseitigkeit für NGINX Open Source entschied. Die Seiten auf der Website der Agentur werden spontan als Mikro-Frontends erstellt, indem Inhaltselemente eingebunden werden und die gleiche CSS-Logik zum „Skins“ mehrerer Back-End-Dienste verwendet wird. Für den Benutzer sieht es so aus, als ob alles innerhalb derselben Application passiert, „aber in Wirklichkeit verwenden wir intelligentes Proxying und Rewrites mit NGINX. Um den Bildschirm mit den entsprechenden Informationen für das Frontend zu füllen, führen wir Backend-API-Aufrufe über NGINX durch“, erklärt Benoit.

Um die Application dem öffentlichen Internet zugänglich zu machen, stellte Benoit eine F5 NGINX Plus- Instanz als Webserver und Reverse-Proxy auf einer virtuelle Maschine bereit, die in der DMZ der Agentur ausgeführt wird. Er erklärt, warum NGINX Plus die richtige Wahl ist: „Wir brauchten TLS 1.3 und wollten schnell umsteigen. Es war im Vergleich zu dedizierten Geräten erschwinglich und wir konnten problemlos Lizenzen hinzufügen.“

Benoit betont, dass für die Agentur „NGINX als Webserver, Proxy und grundlegendes API-Gateway für unsere Application fungiert. Es ist wirklich ein Schweizer Taschenmesser, das fast alles kann. Deshalb verwenden wir es.“ Um beispielsweise eine hochgeladene PDF-Datei abzurufen, wählen Benutzer die gewünschte PDF-Datei aus den hochgeladenen Dokumenten in ihrem Konto aus und die PDF- Application sendet eine Anforderung an den Back-End-PDF-Abrufdienst, der an den Ceph-Objektspeicher angeschlossen ist. Ceph gibt die eindeutige URL des PDF-Speicherorts im Objektspeicher zurück, auf die der Benutzer zum Anzeigen oder Herunterladen klickt.

Da die Application unternehmenskritisch ist, entwickelte das Team eine Aktiv-Aktiv-Architektur mit hoher Verfügbarkeit, bei der alle Applications in mindestens zwei Clustern ausgeführt werden. Dies sorgt für Redundanz für alle Dienste, Mikro-Frontends und APIs und stellt sicher, dass sie im Falle eines Ausfalls in einem der Cluster weiterhin funktionieren.

Um die Leistung zu verbessern und eine Steuerebene für die zusammengesetzten Applications zu ermöglichen, die mehrere Dienste umfassen, verwendet das Team den AMQ Broker-Nachrichtenbus, um Themen und Warteschlangen für Dienste zu konfigurieren. „Wenn also etwas im Hintergrund ausgeführt werden kann, tun wir es im Hintergrund“, sagt Benoit. „Wenn eine Nachricht eingeht und einige Methodendaten angepasst werden müssen, haben wir Listener, die etwas verarbeiten oder die Worker finden können, um den Prozess auszuführen.“ Um einen konsistenten Status für Benutzer über alle Cluster hinweg zu gewährleisten, behielt das Team seine vorhandene hochverfügbare Microsoft SQL Server- Datenbankinfrastruktur bei, um den Pod-Status aufrechtzuerhalten und die Sitzungspersistenz zu ermöglichen.

Design für Beobachtbarkeit, Skalierbarkeit und Flexibilität

Aus Gründen der Beobachtbarkeit empfahl Benoit Grafana als Cloud-natives Dashboard. Um NGINX-Metriken zu erhalten, nutzt das DevOps-Team den NGINX Prometheus Exporter in einem Sidecar, der mit jedem Pod gekoppelt ist. Der Exporter liest Layer-4-Metriken aus dem NGINX Open Source Stub Status-Modul und der NGINX Plus API ein, ordnet jede einer Zeichenfolge zu, erstellt ein Schlüssel-Wert-Paar und überträgt das Paar in Prometheus . Von dort wird das Paar in einer separaten Grafana-Instanz veröffentlicht, die nur Entwicklern und DevOps-Teams zugänglich ist. „Es ist unglaublich. Ich kann Dashboards erstellen und Metriken an einem einzigen Ort für alle meine NGINX Open Source- und NGINX Plus-Instanzen sammeln. Das DevOps-Team hat die Kontrolle. Sie können sehen, was läuft und erhalten bei Problemen Benachrichtigungen“, sagt Benoit.

Das Team nutzt die Metriken auch für das Leistungsmanagement der Application. Prometheus generiert Warnungen für Ausnahmen und nicht behandelte Verbindungen in den Applications, die signalisieren, dass nicht genügend Worker ausgeführt werden. Benoit hat die Metriken mit der Autoscaling-Funktion in OpenShift verknüpft. Er erklärt: „Ich habe das NGINX-Setup für eine bestimmte Anzahl von Arbeitern konfiguriert und den erforderlichen RAM und die erforderliche CPU berechnet. Wenn es im Vergleich zu dieser Basislinie zu hektisch wird, skaliert OpenShift automatisch hoch und sendet mir eine Warnung.“

Als ein Penetrationstest ergab, dass die Applications keine strenge Content Security Policy (CSP) verwendeten, konnte das Team NGINX Open Source und NGINX Plus mit Richtlinien zur Inline-Durchsetzung der CSP konfigurieren. Sie haben außerdem eine benutzerdefinierte Konfiguration eingerichtet, um JSON-Protokollierungsinformationen von der Containerplattform abzurufen und sie zur Verlaufsanalyse und Aufzeichnung an die Splunk -Protokollierungsplattform zu senden.

Verbesserung der Entwicklererfahrung

Für Front-End-Entwickler, die Google Analytics und Lighthouse verwenden, ermöglichte HCS die Einbindung von Lighthouse-Prüfungen in die Pipeline der Agentur, codiert in NGINX-Konfigurationen. „Wir haben schnell erkannt, dass wir durch die Umstellung auf die GZIP-Komprimierungsbibliothek erhebliche Leistungssteigerungen erzielen konnten“, sagt Benoit, und das Ergebnis ist eine Verbesserung der Application um 60 %.

Darüber hinaus stehen Entwickler mit der neuen Architektur jetzt in direktem Kontakt mit Endbenutzern, da sie über einen solch detaillierten Einblick in das Echtzeitverhalten verfügen. „Die Feedbackschleife ist viel schneller und wenn etwas passiert und geändert werden muss, können wir es innerhalb eines Tages in die Produktion bringen. Das ist für Regierungen sehr schnell, während Veränderungen früher Monate oder sogar Jahre dauerten“, sagt Benoit. „Für unsere Entwickler ist das wie Tag und Nacht.“

Der Tech Stack

• Backend – .Net Core
• Frontend – AngularJS
• Netzwerk (Webserver, Reverse-Proxy, API-Gateway, Ingress-Controller, globaler Load Balancer) – NGINX Open Source , NGINX Plus , F5 BIG-IP , HAProxy (auf OpenShift)
• Datenbank – Microsoft SQL Server , Red Hat Ceph Storage , InfluxDB für Lighthouse -Daten
• CI/CD – Azure DevOps
• Infrastruktur – Red Hat OpenShift , Linux-Container
• Messaging – Red Hat AMQ Broker (Active MQ Open Source)
• Beobachtbarkeit und Metriken – Grafana , Prometheus
• Protokollierung – Splunk

Erste Schritte

Möchten Sie die großartigen Ergebnisse dieses Projekts duplizieren, indem Sie Ihren Tech-Stack auf NGINX Plus aufbauen? Starten Sie noch heute Ihre 30-tägige kostenlose Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .