Strategie zum Bereitstellen / Hosten von Javascript-basierten statischen Websites in Containern

Dies kommt von Zeit zu Zeit in mehreren unserer Entwicklerteams vor, ohne dass wir den "richtigen" Weg gefunden haben:

Wir verwenden viele reaktionsbasierte Webanwendungen, die zu statischen Websites "kompiliert" werden, bei denen es sich nur um wenige HTML-, JS- und CSS-Dateien handelt.

Das "Erstellen" dieser Apps erfordert jedoch eine Reihe von Variablen, die Feature-Flags aktivieren / deaktivieren, Backend-URLs konfigurieren usw. Dies bedeutet, dass wir keine Binärdatei im herkömmlichen Sinne "erstellen" und beim Bereitstellen nur eine Konfigurationsdatei anwenden können. Zeit - Für den "Build" selbst müssen diese umgebungsspezifischen Variablen festgelegt sein. Daher können wir nur zur Bereitstellungszeit "erstellen".

Im Moment lösen wir dies, indem wir die erforderlichen Umgebungsvariablen in den Docker-Container einfügen und einen Start-Cmd nach dem Vorbild von ausführen

npm build && nginx run

Dies hat einige Nachteile:

1. Der Erstellungsprozess benötigt im Verhältnis zu den Laufzeitanforderungen des Containers viel CPU / Speicher. Das heißt, wir müssen den Container für den Erstellungsprozess skalieren, anstatt die Laufzeitanforderungen - was sich falsch anfühlt
2. Build-Fehler sind schwer zu "verfolgen". Wir können Healthchecks in Kubernetes verwenden, aber wenn ein Build 2 Minuten dauert, müssen wir noch 3 Minuten warten (1 extra für die Sicherheit), bevor wir den Healthcheck-Endpunkt des Containers testen können, um festzustellen, ob er aktiv ist.
3. Bereitstellungen können lange dauern: Wenn wir Kubernetes für eine "serielle" Bereitstellung konfigurieren, wird jeder Pod gestartet und auf die "initialDelay" -Periode von 2-3 Minuten gewartet, bevor mit der nächsten begonnen wird. Dies bedeutet, dass wir uns leicht eine Bereitstellungszeit von 10 Minuten ansehen können, wenn die Bereitstellung auf 3-4 Pods skaliert wird.

Das alles fühlt sich für mich sehr suboptimal an. Es würde mich sehr interessieren zu hören, wie die Community das Rätsel "Build at Deployment Time" mit modernen Javascript-Webapps löst.

Mir ist klar, dass wir für Kubernetes "Init-Container" verwenden könnten, die den Build ausführen, die Artikel in einen dauerhaften Speicher stellen und die App-Container dann beim Start einfach aus dem dauerhaften Speicher ziehen lassen, aber dies fühlt sich immer noch eher so an, als würde man das Problem "umgehen" als Lösen des Grundproblems.

Aus meiner Sicht wäre der beste Ansatz:

1. Separater Erstellungsprozess mit Jenkins, der das NodeJS-Projekt in die Verteilung integriert und in das Docker-Image einschließt
2. Starten Sie die Docker-Registrierung, die Docker-Images von Jenkins ansammelt (auf diese Registrierung sollte über den Kubernetes-Cluster zugegriffen werden können).
3. Verschieben Sie Umgebungsvariablen in Jenkins Geheimnisse oder verwenden Sie ein separates Tool, um Konfigurationen von externem Git-Repo zu sammeln und zu kombinieren (wir verwenden Spring Cloud Config über die REST-API, um JSON / YML-Definitionen für jede Anwendung in jeder Umgebung zu sammeln).

Mit Jenkins können Sie ein kontinuierliches Liefersystem basierend auf generischen Pipelines konfigurieren. Möglicher Fluss wäre:

1. Entwickler beenden ihre Arbeit in Korrespondenz mit GitFlow (letzte Pull-Anfrage in Release-Zweig zusammengeführt)
2. Webhook löst Jenkins-Pipeline aus:
   • Stufe 1: Umgebungsdefinition sammeln
   • Stufe 2: Erstellen Sie die NodeJS-App mit npm
   • Stufe 3: Erstellen eines Nginx Docker-Images mit Verteilung
   • Stufe 4: Schieben Sie das Docker-Image in die Docker-Registrierung
   • Stufe 5: Bereitstellen / Aktualisieren des Dienstes in Kubernetes unter Verwendung von Standarddefinitionen
3. Benachrichtigungen bezüglich der Ergebnisse senden

Dieser Vorgang kann mit Rancher visualisiert werden. Ich kann Ihre Fragen im Chat beantworten.