Eine Rails-App von Heroku wegziehen

Der Grund, warum die meisten Teams länger auf einer verwalteten Plattform bleiben, als sie eigentlich wollten, ist nicht der Preis. Es ist, dass die Migration wie ein Projekt ohne klares Ende aussieht. Dieser Beitrag ist der kürzeste Weg, den wir kennen, in der Reihenfolge, die die App bei jedem Schritt am Laufen hält.

Schritt 1: unverändert deployen, mit Buildpacks

Fang nicht damit an, ein Dockerfile zu schreiben. Fang damit an zu beweisen, dass die Anwendung überhaupt irgendwo anders läuft.

Cloud Native Buildpacks lesen dein Repository auf dieselbe Weise wie Herokus Build, mit vorgefertigten Runtime-Layern statt eine Sprache aus dem Quellcode zu kompilieren. In der Praxis baut eine Standard-Rails- oder -Django-App ohne eine einzige geänderte Datei.

Startet sie, hast du bereits den schwierigen Teil bewiesen: Nichts an deiner Anwendung hing tatsächlich von der Plattform ab.

Schritt 2: Die Datendienste umziehen

Deine App braucht fast sicher Postgres und Redis. Stelle sie als Addons bereit, und Railyard injiziert die Connection Strings in die Umgebung, genau wie du es gewohnt bist.

Zwei Dinge zum Prüfen:

Extensions. Falls du pgvector, PostGIS oder Ähnliches nutzt, stell sicher, dass das bereitgestellte Postgres sie hat. Unseres hat sie für pgvector.
Der Dump. Stell einen echten Produktions-Dump in der neuen Datenbank wieder her, bevor du umschaltest, und stoppe die Zeit. Das ist der Schritt, den Teams unterschätzen.

Schritt 3: Deine Prozesse deklarieren

Falls deine App ein Procfile hat, liest Railyard es ein – Web-Prozess, Worker-Prozess und der release:-Hook, der Migrationen ausführt, bevor überhaupt Traffic ausgeliefert wird. Letzteres ist wichtiger, als es aussieht: Es ist das, was eine Migration davon abhält, gegen eine Code-Version zu laufen, die bereits Requests entgegennimmt.

Schritt 4: Auf ein Dockerfile wechseln, wenn du willst

Sobald sie läuft, bringt dir ein Dockerfile Reproduzierbarkeit und schnellere Warm-Builds. Es ist nicht erforderlich, und es ist deutlich leichter zu schreiben für eine App, die du schon deployen kannst, als für eine, die du noch nicht kannst.

Mit einem registry-gestützten Layer-Cache landen Warm-Rebuilds einer großen Rails-App bei etwa anderthalb Minuten.

Was tatsächlich kaputtgeht

Aus wiederholter Erfahrung sind die wiederkehrenden Probleme:

Apps, die ihre eigene Infrastruktur mitbringen. Manche Anwendungen starten ihre gesamte Umgebung während assets:precompile und brauchen einen existierenden Such-Cluster. Das schlägt auf jeder Plattform ohne das Addon fehl – das ist kein Migrationsproblem, das ist eine App-Anforderung, die du vergessen hattest.
Build-Speicher auf kleinen Boxen. Ein 2-GB-Server, der native Extensions kompiliert, kann aus dem Speicher laufen. Baue entweder auf einem dedizierten Builder, oder begrenze den Speicher des Builds, damit er saubet fehlschlägt statt die Maschine mitzureißen.
Angenommener ephemeraler Speicher. Alles, was auf die lokale Festplatte schreibt, braucht ein persistentes Volume, sonst verwirft der nächste Deploy es stillschweigend.

Was du am Ende hast

Deine App läuft auf Servern in einer Region, die du gewählt hast, zum Preis deines Providers ohne Aufschlag, und wenn du jemals aufhörst, für die Control Plane zu zahlen, liefern die Container weiter Traffic aus. Der Workflow bleibt derselbe, den du verlassen hast: pushen, den Build beobachten, zurückrollen, wenn etwas nicht stimmt.