Deployments in Codesphere haben gerade ein großes Upgrade erhalten. Sie können jetzt mehrere Dienste ausführen, die innerhalb eines einzigen Workspace unabhängig voneinander vertikal und horizontal skaliert werden können.
Damit definieren Sie Ihre Landscapes mit all ihren Services innerhalb Ihrer ci.yml-Datei aus dem Codesphere UI. Gleichzeitig verlagern wir den gesamten Codesphere-Editor und die Dateisystemoperationen in ein separates Deployment mit individuellen Ressourcen. Diese Trennung wird die Stabilität der Runtime-Ausführung Ihrer Anwendung weiter verbessern und zukünftige Verbesserungen wie vertikale Skalierung für Dinge wie Builds ermöglichen, ohne Ihre Anwendung zu beeinträchtigen.
Mehrere Dienste konfigurieren
Dienste werden auf der Registerkarte Codesphere CI definiert. Mit dem CI-Konfigurationseditor können Sie neue Dienste erstellen oder bestehende Dienste bearbeiten.
Für jeden Dienst müssen Sie einen eindeutigen Dienstnamen, den Plan des Dienstes, einen Pfad, von dem aus der Dienst den Datenverkehr bedient, den Deployment-Modus (Off-When-Unused oder Always-On) und die Anzahl der Replicas auswählen. Nach der Konfiguration fügen Sie die Befehle hinzu, um die Anwendung dieses Dienstes auszuführen. Für alle, die bereits mit Codesphere Workspaces für einzelne Dienste vertraut sind, kann man sich das so vorstellen, als hätte man mehrere Run Stages.
Ähnlich wie unsere Replicas funktionieren, laufen alle Dienste auf demselben gemeinsamen Dateisystem. Der für diesen Workspace verfügbare Gesamtspeicher wird durch den IDE-Plan des Workspaces definiert und ist später frei konfigurierbar.
Pfade werden standardmäßig aus der Perspektive eines Monorepositorys bedient, d.h. wenn ein Dienst mit dem Pfad /foo definiert wird, muss die Anwendung, die dort läuft, auch den Verkehr unter dieser Route bedienen, so dass z.B. /foo/ das Stammverzeichnis aus der Perspektive dieser Anwendung wäre. Folglich müssen alle Routen der foo-Anwendung das Präfix /foo/ enthalten. Eine gültige Beispielroute wäre also /foo/yourRoute, während /yourRoute keine gültige Route wäre. Wir werden in einem zukünftigen Release eine Option hinzufügen, um dieses Präfix aus allen Routen für Anwendungen zu entfernen, die ursprünglich nicht mit einer solchen Monorepo-Struktur im Hinterkopf entworfen wurden.
Jeder Service kann so konfiguriert werden, dass zusätzliche Replicas für horizontale Skalierungsmöglichkeiten zur Verfügung stehen. Die Kombination dieser beiden Funktionen ermöglicht das Deployment und die Skalierung großer Anwendungslandschaften mit zahlreichen Backend- und/oder Frontend-Diensten, Datenbanken und anderen verwalteten Diensten, z. B. können Sie Codesphere innerhalb von Codesphere betreiben.
Sobald Sie die Konfiguration abgeschlossen haben, gibt es zwei Möglichkeiten: Sie können entweder "Submit & Deployment" durchführen, wodurch die Änderungen gespeichert und die Landschaft aktualisiert wird. Da dies auch Änderungen an Ihrer Rechnungsstellung beinhalten kann, z. B. das Hinzufügen oder Aktualisieren von Serviceplänen, wird ein Bestätigungs-Popup angezeigt, in dem Sie um Ihre Bestätigung gebeten werden.
Die Run-Phase aller geänderten Dienste wird nach der Bestätigung neu gestartet, was zu einer kurzen Ausfallzeit führen kann. Wenn Sie dies vermeiden möchten, folgen Sie bitte dem hier beschriebenen Prozess: https://codesphere.com/articles/zero-downtime-releases
Wenn Sie Ihre CI-Konfigurationsänderungen speichern möchten, ohne sie direkt anzuwenden, können Sie auch ohne Synchronisierung übermitteln. In diesem Fall sehen Sie ein Warnsymbol neben der Run-Phase und einen Sync-Button, um die Landschaft auf den aktuell konfigurierten Stand zu bringen.
Beispielhafte Anwendungsfälle
In diesem Abschnitt werden einige Beispiele erläutert, bei denen der Einsatz des neuen Multi Service Landscape Deployment am sinnvollsten ist.
Getrenntes Frontend und Backend
Dies ist der offensichtlichste und häufigste Fall, in dem separate Dienste, die unabhängig voneinander skalieren können, von Vorteil sind. Kombinieren Sie ein leichtgewichtiges Frontend in dem von Ihnen gewählten Tech-Stack mit einem leistungsfähigeren Backend-Service in einem anderen Stack.
Erweiterung bestehender Anwendungen um zusätzliche (KI-)Dienste
Sie können nun selbst gehostete KI-Funktionen zu jeder Ihrer Anwendungen hinzufügen, indem Sie einen zusätzlichen Backend-Service zusammen mit Ihrer bestehenden Anwendung deployen. Die Dienste eines Workspace können innerhalb des Clusters miteinander kommunizieren, d. h., sie müssen nicht erst über eine öffentliche Internetverbindung gehen. Dies gewährleistet geringe Latenzzeiten und eine effiziente Kommunikation.
KI ist nicht der einzige Dienst, der auf diese Weise hinzugefügt werden kann. Sie können Ihre Anwendungen mit anderen Backend-Diensten erweitern, z. B. mit einem selbst gehosteten Low-Code-Workflow-Tool (z. B. n8n), einem PDF-Server oder einem Authentifizierungsdienst wie Keycloak, um nur einige zu nennen, für die wir mit einem Klick installierbare Vorlagen anbieten.
Private Vernetzung
Landscapes Deployments sind von Haus aus mit privaten Netzwerkfunktionen ausgestattet. Dienste können innerhalb des geschützten Codesphere-Netzwerks privat miteinander kommunizieren und Sie können auswählen, welcher Dienst öffentlich zugänglich gemacht werden soll. Dies eignet sich hervorragend für den Aufbau von Anwendungen vom Typ API-Gateway, ohne dass Sie sich um die Authentifizierung kümmern müssen.
Um ein privates Netzwerk zu nutzen, müssen Sie Ihre Dienste so konfigurieren, dass sie sich nicht über ihren Pfad, sondern über ihr Dienstnamensmuster aufrufen, z. B. http://ws-server-[WorkspaceId]-[serviceName]:3000. Beachten Sie, dass es sich hierbei um einen lokalen http-Aufruf handelt und dass diese URL immer nur für andere Dienste derselben Landschaft zugänglich ist. Sie ist weder über das Frontend noch über das öffentliche Internet zugänglich. Alle Dienste (sowohl öffentliche als auch private Dienste) können sich auf diese Weise gegenseitig aufrufen, aber private Dienste sind ausschließlich auf diese Weise erreichbar.
Auswirkungen der Trennung von IDE- und Anwendungsressourcen
In diesem Abschnitt wird erläutert, wie sich das neue Landscape Deployment von unseren bisherigen Single Service Workspaces unterscheidet und was zu beachten ist, wenn Sie zum ersten Mal mit einem Multi-Service Workspace arbeiten.
Alle Interaktionen, die in der Codesphere IDE stattfinden, werden nun in einem separaten Deployment ausgeführt. Dieses Deployment hat seine eigenen Ressourcen. Dies hat zwei große Vorteile: Erstens können Ihre Interaktionen, z. B. während Releases oder Debugging, niemals Ihren Production Deployment Service beeinträchtigen. Zweitens ermöglicht dies eine viel flexiblere Ressourcenzuweisung für Nicht-Produktions-Workloads, z. B. Builds. Wir werden Optionen hinzufügen, um die IDE-Ressourcen für eine kurze Zeit (z. B. während eines Builds) vertikal nach oben und dann wieder nach unten zu skalieren.
In der Praxis bedeutet dies, dass Ihre Prepare- und Test-Phase auf den IDE-Ressourcen läuft, ebenso wie Ihre Dateibaum-Interaktionen, alle Sprachserver-Ressourcen und Terminal-Interaktionen. Wenn Ihr IDE-Plan für die Arbeitslasten in der Prepare-Phase zu klein ist, kann es beispielsweise zu OOM-Fehlern oder instabiler IDE-Navigation kommen, was aber niemals die Ausführung der Run-Phase beeinträchtigen kann.
Gemeinsames Dateisystem und Vermeidung von gleichzeitigen Schreibvorgängen
Genau wie unsere Replicas werden alle Dienste das gemeinsame Dateisystem nutzen. Die insgesamt verfügbare Speichergröße wird durch den IDE-Plan bestimmt und ist später separat konfigurierbar.
Obwohl dies weniger wahrscheinlich ist als bei Replicas, müssen Sie dennoch sicherstellen, dass Ihre Dienste während der Laufzeit nicht gleichzeitig in dieselbe Datei schreiben. Wenn Ihre Dienste in einzelnen Ordnern strukturiert sind, ist dies in der Regel nicht standardmäßig der Fall.
Der gemeinsam genutzte Speicher ist auf das Verzeichnis home/user/app/ und alle Unterverzeichnisse beschränkt. Wenn Sie in Ihrer Prepare-Phase Pakete installieren oder Konfigurationen festlegen, stellen Sie sicher, dass sich alles im Verzeichnis des gemeinsamen Dateisystems befindet. Alle Änderungen außerhalb dieses Verzeichnisses bleiben nicht über Neustarts hinweg erhalten und stehen den einzelnen Diensten zur Laufzeit nicht zur Verfügung.
Migration von Workspaces für einzelne Dienste
Wir führen dies schrittweise ein (beginnend mit einer Opt-in-Beta), aber letztendlich werden alle neuen Workspaces standardmäßig den neuen Landschafts-Deployment-Modus verwenden. Anwendungsfälle, die nur einen einzigen Dienst verwenden, werden dann ein Landscape Deployment mit einem einzigen Dienst sein.
Wenn Sie bestehende Workspaces oder Repositories mit einer bestehenden ci.yml aktualisieren wollen, wird Ihnen beim Öffnen des CI-Editors im Workspace angeboten, Ihre CI-Konfiguration zu aktualisieren. Dadurch wird Ihr bestehender Run Stage in einen ersten Service verschoben. Bitte beachten Sie, dass dadurch derzeit ein zusätzlicher Plan erstellt wird, der Ihre monatliche Rechnung bei Bestätigung erhöht. Wir arbeiten an einer Lösung, die dies beheben wird.
Nach Abschluss der Aktualisierung müssen Sie die aktualisierte ci.yml in Ihr Repository übertragen, da Sie sonst beim nächsten Mal, wenn Sie einen Workspace aus der alten Konfiguration erstellen, erneut zur Aktualisierung aufgefordert werden.
Alternativ können Sie sich dieses Vorlagen-Repository ansehen, das den separaten Backend-/Frontend-Anwendungsfall zeigt: https://github.com/codesphere-cloud/landscape-twitter-clone.