So ziehst du einen Service auf einen anderen Server auf Sliplane um

Lukas Mauser

6 min

Wie die Migration auf einen anderen Server abläuft, hängt von deinem Setup ab. In manchen Fällen kannst du einen Service sogar ganz ohne Downtime umziehen. Klappt das bei deinem Service nicht, lohnt es sich, die Migration vorab zu planen: Sag deinen Usern Bescheid und such dir eine Zeit aus, in der wenig los ist.

Um Risiko und Downtime klein zu halten, ist es eine gute Idee, die Migration erst in einer Staging-Umgebung zu testen. Und wenn du viele Services migrierst oder das regelmäßig machst, kannst du Teile des Prozesses mit der Sliplane API automatisieren.

Bevor du loslegst

Diese Anleitung geht davon aus, dass du schon einen Zielserver hast, auf den dein Service umziehen kann. Falls noch nicht, erstell zuerst einen neuen Server. Denk nur dran, dass ein Server Kosten verursacht, sobald er existiert, auch wenn noch keine Services darauf laufen.

Außerdem lohnt sich ein kurzer Blick auf die Abhängigkeiten des Services, den du migrieren willst:

Geteilte Volumes. Nutzen mehrere Services dasselbe Volume, musst du eventuell alle diese Services zusammen migrieren.
Services, die miteinander sprechen. Das interne Netzwerk ist nur von Services auf dem selben Server erreichbar. Kommunizieren Services also über interne Hostnamen (z.B. servicexyz.internal), musst du eventuell alle zusammen migrieren. Dann kommt es auf die Reihenfolge an: Fang mit dem Service ganz unten in der Kette an, z.B. erst die Datenbank, dann das Backend, dann das Frontend.
Services, die auf den migrierten Service zugreifen. Der öffentliche Endpunkt (die sliplane.app Domain und freigegebene Ports) und der interne Hostname deines Services können sich bei der Migration ändern. Am besten notierst du dir alle Services, die sich mit ihm verbinden, damit du ihre Config danach anpassen kannst.
IP-Allowlists. Dein Service nutzt künftig die IP-Adresse des neuen Servers. Die findest du in den Einstellungen des neuen Servers, so kannst du sie schon vorab in alle Allowlists eintragen (Datenbanken, externe APIs, Firewalls).

DNS TTL senken (optional). Wenn du eine eigene Domain nutzt, kannst du die TTL ihrer DNS-Records aufs Minimum senken (z.B. 60 Sekunden). So greift die Domain-Umstellung am Ende innerhalb einer Minute statt nach Stunden. Weil Resolver deine Records noch für die alte TTL cachen, machst du das am besten früh. Liegt deine TTL aktuell bei 24 Stunden, senk sie einen Tag vorher.

So funktioniert die Migration

Die Migration besteht aus drei Schritten: Erst ziehst du die Daten um, dann den Service, und zum Schluss passt du Domains und DNS-Records an.

Schritt 1: Daten umziehen

Hat dein Service Volumes, ziehst du im ersten Schritt alle davon auf den neuen Server um. Hat er keine, kannst du direkt zu Schritt 2 springen. Der Umzug der Daten besteht aus drei Schritten:

Service pausieren in den Service-Einstellungen oder über das Drei-Punkte-Menü in der Projektübersicht. Hängt ein Volume an mehreren Services, die hineinschreiben, pausier alle davon. Mehr zum Pausieren von Services
Manuelles Backup erstellen für jedes Volume über Create Backup im Drei-Punkte-Menü des Volumes auf dem alten Server. Je nach Größe dauert das ein paar Sekunden bis mehrere Minuten. Mehr zu Volume Backups
Backups auf dem neuen Server wiederherstellen, indem du beim Backup auf Restore klickst und den neuen Server als Target server auswählst. Sobald die Wiederherstellung fertig ist, findest du auf dem neuen Server ein neues Volume mit dem Inhalt des Backups. Mehr zum Wiederherstellen von Backups

Wiederherstellungen auf einen anderen Server funktionieren nur auf Servern der aktuellen Generation. Legacy Server werden in der Liste angezeigt, sind aber deaktiviert.

Das Pausieren ist aus zwei Gründen wichtig. Erstens verhindert es Datenkorruption: Eine Datenbank schreibt z.B. gleichzeitig in mehrere Dateien. Erwischt das Backup sie mitten im Schreiben, passen sie nicht mehr zusammen, und die wiederhergestellte Datenbank startet vielleicht nicht oder enthält korrupte Daten. Zweitens verhindert es Datenverlust, denn alles, was nach dem Backup geschrieben wird, bleibt auf dem alten Server und landet nicht auf dem neuen.

Werden die Daten in deinen Volumes nur gelesen oder selten beschrieben, musst du den Service eventuell gar nicht pausieren. Dann kannst du migrieren, während er weiterläuft, und hältst die Downtime so klein wie möglich. Prüf das aber lieber genau, denn ein laufender Service kann im nächsten Schritt zum Problem werden: Sobald du die Kopie deployst, laufen zwei Instanzen deines Services gleichzeitig. Verbinden sich z.B. beide mit derselben externen Datenquelle, riskierst du Datenkorruption.

Schritt 2: Service umziehen

Jetzt deployst du eine neue Version deines Services auf dem neuen Server und hängst die Volumes an, die du in Schritt 1 umgezogen hast.

Am einfachsten geht das mit dem Deploy Copy Feature. Du findest es im Drei-Punkte-Menü auf der Service-Karte in der Projektübersicht. Es kopiert die Config des Services und füllt das Deploy-Formular für dich aus. Du musst dann nur noch den neuen Server auswählen, die Config prüfen und deployen. Mehr zu Deploy copy

Ein paar Dinge solltest du dabei beachten:

Secrets werden nicht kopiert. Deploy copy übernimmt deine Env Vars, außer die, die als Secret markiert sind. Die musst du von Hand neu eintragen.
Wähl die wiederhergestellten Volumes aus. Deploy copy kennt die Volumes aus Schritt 1 nicht. Findet es das ursprüngliche Volume nicht auf dem neuen Server, legt es standardmäßig ein neues, leeres an. Ersetz diese im Deploy-Formular durch die wiederhergestellten Volumes aus Schritt 1 und prüf die Mount Paths.
Domains werden nicht kopiert. Die ziehst du in Schritt 3 um.
Interne Hostnamen funktionieren nur auf demselben Server. Nachdem du einen Service umgezogen hast, musst du eventuell auch abhängige Services migrieren und ihre Verweise auf interne Hostnamen anpassen.
Vermeide ungewollte Upgrades durch latest Tags. Ein Deploy zieht immer das neueste verfügbare Image für einen Tag. Nutzt dein Service den latest Tag, landet die Kopie eventuell auf einer neueren Version als das Original, inklusive Breaking Changes. Um auf Nummer sicher zu gehen, pinn vorher in den Service-Einstellungen die exakte Version, die gerade läuft, damit der neue Server dieselbe Version bekommt.
Zwei Services parallel. Läuft das Original noch, laufen zwei Instanzen gleichzeitig. Für manche Services ist das ein Problem: Verbinden sich z.B. beide mit derselben Datenquelle, riskierst du Datenkorruption.
Öffentliche Endpunkte ändern sich. Die Kopie bekommt eine neue sliplane.app Domain, und öffentlich freigegebene TCP/UDP-Ports ändern sich ebenfalls. Pass also alle Verweise auf deinen Service an.

Schritt 3: Domains und DNS-Records anpassen

Nutzt du eigene Domains, ist jetzt der Moment, sie umzustellen. Eine Domain kann immer nur an einem Service hängen. Du entfernst sie also zuerst beim alten Service und fügst sie dann im Tab Domains beim neuen Service hinzu. Mehr zu eigenen Domains

Danach passt du deine DNS-Records an die Werte an, die Sliplane anzeigt:

CNAME/ALIAS-Records: auf die neue xyz.sliplane.app Domain zeigen lassen.
A/AAAA-Records: auf die IP-Adressen des neuen Servers zeigen lassen.

Das SSL-Zertifikat wird automatisch ausgestellt, sobald DNS auf den neuen Server zeigt. Hast du die TTL vorher gesenkt, dauert die Umstellung nur ein bis zwei Minuten. Danach kannst du die TTL wieder auf den alten Wert stellen.

Fazit

Das war's, dein Service läuft jetzt auf dem neuen Server. Wir empfehlen, den alten Service noch ein, zwei Tage pausiert zu lassen, damit du zurückwechseln kannst, falls etwas schiefgeht. Wenn alles läuft wie es soll, kannst du den alten Service löschen. Ist der alte Server jetzt leer, lösch ihn ebenfalls, denn er kostet, bis du ihn löschst.