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 Diensten innerhalb Ihrer ci.yml-Datei aus der Codesphere-Benutzeroberfläche. 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.
Configuring multiple services
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 bei unseren Replicas laufen alle Dienste auf demselben gemeinsamen Dateisystem. Das bedeutet, dass nur Pakete und Build-Artefakte im gemeinsamen /home/user/app und /nix/store Ordner innerhalb der Landschaftsdienste verfügbar sein. Der für diesen Workspace verfügbare Gesamtspeicherplatz wird durch den IDE-Plan des Workspaces definiert und ist später frei konfigurierbar.
Pfade werden standardmäßig aus der Perspektive eines Monorepositoriums bedient, was bedeutet, dass bei der Definition eines Dienstes mit Pfad /foo die Anwendung, die dort läuft, muss auch den Verkehr unter dieser Route bedienen, also zum Beispiel /foo/ wäre aus Sicht dieser Anwendung die Wurzel. Folglich müssen alle Routen der Anwendung foo das Präfix /foo/ Eine gültige Beispielroute wäre also /foo/ihreRoute während /IhreRoute würde not eine gültige Route sein. Wir werden in einem zukünftigen Release eine Option hinzufügen, die dieses Präfix aus allen Routen für Anwendungen entfernt, 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, zum Beispiel können Sie Codesphere innerhalb von Codesphere laufen lassen.
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/de-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.
Example use cases
In diesem Abschnitt werden einige Beispiele erläutert, bei denen der Einsatz des neuen Multi Service Landscape Deployment am sinnvollsten ist.
Separate frontend and 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.
Extending existing applications with additional (AI) services
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, wie z. B. mit einem selbst gehosteten Workflow-Tool mit geringem Code. n8n , einen pdf-Server oder einen Authentifizierungsdienst wie Schlüsselanhänger um nur einige zu nennen, bei denen wir mit einem Mausklick installierbare Vorlagen haben.
Private networking
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 private Netzwerke zu nutzen, müssen Sie Ihre Dienste so konfigurieren, dass sie sich nicht über ihren Pfad, sondern über ihr Dienstnamensmuster aufrufen, d.h. http://ws-server-[ArbeitsbereichId]-[Dienstname]: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) können sich auf diese Weise gegenseitig anrufen, aber private Dienste sind ausschließlich auf diese Weise erreichbar.
Implications of separating IDE and application resources
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 jedoch niemals die Ausführung der Run-Phase beeinträchtigen kann.
Shared filesystem and avoiding concurrent writes
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.
Migrating from single service workspaces
Wir führen dies schrittweise ein (beginnend mit einer Opt-in-Beta), aber schließlich 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, sonst werden Sie beim nächsten Mal, wenn Sie einen Workspace aus der alten Konfiguration erstellen, erneut zur Aktualisierung aufgefordert.
Alternativ können Sie sich dieses Template Repository ansehen, das den separaten Backend/Frontend Anwendungsfall zeigt: https://github.com/codesphere-cloud/landscape-twitter-clone .