Von Render migrieren

Render-Services mit Postgres, Env Vars und Domains umziehen.

Auf Render ist jeder Teil einer Anwendung ein eigener Service: Web Service, Background Worker, Private Service, Cron Job. Auf Nodion baust du einmal ein Image und betreibst daraus mehrere Prozesse in einer Application; Cron Jobs hängen an der App. Eine render.yaml liest Nodion nicht, die Einstellungen ziehst du von Hand um.

Was wozu wird

1. Projekt und Datenbank anlegen

Leg ein Projekt an und darin eine PostgreSQL-Datenbank in der Region, in der die App laufen soll. App und Datenbank müssen in derselben Region liegen. Wähl eine Postgres-Version, die mindestens so neu ist wie auf Render. Mehr unter Datenbanken.

2. Datenbank kopieren

Die External Database URL steht auf der Info-Seite der Render-Datenbank; Render nimmt externe Verbindungen nur mit TLS an (Render-Doku). Stopp die Schreibzugriffe deiner Services und erstelle dann den Dump so, wie Render es in seiner Backup-Doku zeigt. -n public nimmt nur das Schema public mit; lass es weg, wenn deine App weitere Schemas nutzt.

bashpg_dump --dbname="RENDER_EXTERNAL_DATABASE_URL" -n public --no-owner \
  --format=directory --jobs=4 --compress=0 -f render.dump/

Öffne in Nodion die Datenbank, Tab Overview, und klick auf Enable public access. Sobald der Endpoint nicht mehr Provisioning zeigt, kopier die Connection URL (immer TLS) und trag unter Allowed sources deine eigene IP ein. Dann einspielen:

bashpg_restore --verbose --no-owner --no-privileges --jobs=4 --format=directory \
  --dbname="postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  render.dump/

Nimm ein pg_restore, das mindestens so neu ist wie der neuere der beiden Server. Prüf Zeilenzahlen im Tab Browse und schalte den öffentlichen Zugang danach wieder ab; die Datenbank läuft intern weiter.

3. Application und Prozesse anlegen

Leg eine Application aus dem Git-Repository des Web Service an. Hat Render nach Build und Start Command gebaut, nimm die Strategie Buildpacks (Buildpacks); ein Procfile legt die Befehle fest, sonst gelten die Standards der Sprache. Lief der Service mit Docker, nimm die Strategie Dockerfile.

Render setzt PORT standardmäßig auf 10000. Nodion setzt PORT für den web-Prozess von Buildpack-Apps (Standard 8080); liest deine App PORT, ändert sich nichts. Steht 10000 fest im Code, ersetz es. Bei Dockerfile-Apps setzt Nodion kein PORT; die App lauscht auf dem Port des web-Prozesses.

Jeden Background Worker aus demselben Repo legst du unter Processes, New process als weiteren Prozess an und trägst seinen Start Command ein. Ein Private Service wird ebenfalls ein Prozess, mit Port. Achtung: Jeder Prozess mit Port bekommt neben der internen Adresse einen öffentlichen Standard-Hostnamen; einen rein privaten Service gibt es nicht. Sichere einen solchen Port in der App ab (zum Beispiel mit Authentifizierung). Die Nodion-Hostnamen lassen sich nur für die ganze App abschalten, sobald eine eigene Domain aktiv ist. Ein Worker, der nur eine Queue abarbeitet, braucht keinen Port. Einen Pre-deploy Command übernimmst du als release:-Zeile im Procfile (Buildpacks) oder als Release Command der App (Settings, Karte Preview environments, wo das Feld erscheint, sobald Previews aktiviert sind, oder release_command über die API). Er läuft bei jedem Deploy einmal vor web; schlägt er fehl, bleibt das vorherige Release aktiv.

4. Env Vars übernehmen

Render dokumentiert keinen Export für Env Vars im Dashboard; die Render-API liefert die Variablen eines Service, aber nicht die aus Environment Groups (Render-API-Referenz, GET /services/{serviceId}/env-vars; zu Environment Groups siehe die Render-Doku). Schreib sie als KEY=wert-Zeilen zusammen, einschließlich der Werte aus Environment Groups, und füg sie unter Environment, Add many ein. Secrets setzt du mit nodion env set KEY=wert --secret, mehrzeilige Werte per CLI oder API. Secret Files gibt es auf Nodion nicht. Leg ihren Inhalt als geheime Variable an (--secret) und lass die App ihn aus der Variable lesen oder die Datei beim Start selbst schreiben. Ins Image gehören Secrets nicht; davor warnt auch Render.

Lösch DATABASE_URL und REDIS_URL von Render wieder: Eine selbst gesetzte Variable überschreibt den Wert einer angehängten Datenbank. Häng die Datenbanken mit Attach database an. Intern läuft die Verbindung ohne TLS (sslmode=disable); erzwingt dein Code SSL, schalte das für diese URL ab, ebenso rediss:// zu Valkey.

5. Cron Jobs übernehmen

Ein Render Cron Job ist ein eigener Service mit Zeitplan in UTC (Render-Doku). Auf Nodion legst du ihn im Tab Cron der App an, deren Code er braucht: Zeitplan in UTC mit fünf Feldern, Befehl, Timeout bis 30 Minuten, bis zu 8 Jobs pro App. Läuft ein Job noch, fällt der nächste Termin aus.

6. Deployen, Domain umziehen, Render abschalten

Deploye und prüf den Tab Logs. Trag dann die Domain im Tab Domains ein und setz die zwei Records, die Nodion anzeigt: TXT _nodion-challenge.deine-domain und einen CNAME (am Apex ein ALIAS) auf den Standard-Hostnamen der App. Einen A-Record als Ziel bietet Nodion nicht; am Apex braucht dein DNS-Anbieter also ALIAS, ANAME oder CNAME-Flattening. Das Zertifikat kommt, sobald der CNAME auf Nodion zeigt; rechne mit ein paar Minuten ohne gültiges Zertifikat und senk die TTL vorher.

Läuft alles, lösch die Render-Services (Render CLI). Render behält keine Backups einer gelöschten Datenbank, heb also deinen Dump auf.

bashrender services delete my-service --confirm

Die Datenbank und eine Key-Value-Instanz löscht Render nicht mit dem Service. Auf bezahlten Instanzen speichert Render Key Value standardmäßig auch auf Disk (Render-Doku): Ein leerer Valkey reicht nur für Caches oder Queues, die du vorher leerlaufen lässt; brauchst du die Keys, zieh sie um, bevor du die Instanz löschst. Lösch die Render-Postgres-Datenbank danach selbst, über Delete Database unten auf ihrer Info-Seite (Render-Doku), und ebenso eine Key-Value-Instanz; die CLI-Befehle dafür stehen in der Render-CLI-Referenz.

Was anders ist

• Es gibt keine Environment Groups und keine Secret Files; Variablen gehören jeweils zu einer App.
• Worker und Private Services sind Prozesse einer App, keine eigenen Services.
• Cron Jobs laufen auf einer bestehenden App mit deren aktivem Release.
• Die CLI holt Logs, kann ihnen aber nicht folgen; live mitlesen kannst du im Tab Logs.

Weiter

Nodion und Render im Vergleich, Preise, Applications und Datenbanken.