Migrer depuis Render

Migrez des services Render avec leur Postgres, leurs variables d'environnement et leurs domaines.

Sur Render, chaque partie d'une application est un service distinct : service web, worker en arrière-plan, service privé ou tâche cron. Sur Nodion, vous construisez une seule image et lancez plusieurs processus à partir de cette image dans une même application ; les tâches cron appartiennent à l'app. Nodion ne lit pas le fichier render.yaml ; transférez donc les paramètres manuellement.

Correspondances entre Render et Nodion

1. Créez le projet et la base de données

Créez un projet et, dans ce projet, une base de données PostgreSQL dans la région où l'app doit tourner. L'app et sa base de données doivent se trouver dans la même région. Choisissez une version de Postgres au moins aussi récente que sur Render. Plus d'informations dans Bases de données.

2. Copiez la base de données

L'URL externe de la base de données se trouve sur la page Info de la base Render ; Render n'accepte les connexions externes qu'en TLS (documentation Render). Arrêtez les écritures de vos services, puis créez le dump comme l'indique la documentation de backup de Render. -n public ne prend que le schéma public ; omettez-le si votre app utilise d'autres schémas.

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

Dans Nodion, ouvrez l'onglet Overview de la base de données et cliquez sur Enable public access. Dès que l'endpoint n'affiche plus Provisioning, copiez l'URL de connexion (toujours en TLS) et ajoutez votre propre IP sous Allowed sources. Restaurez ensuite :

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

Utilisez un pg_restore au moins aussi récent que le plus récent des deux serveurs. Vérifiez le nombre de lignes dans l'onglet Browse, puis désactivez à nouveau l'accès public ; la base de données continue de tourner en interne.

3. Créez l'application et ses processus

Créez une application à partir du dépôt Git du service web. Si Render utilisait une commande de build et une commande de démarrage, choisissez la stratégie Buildpacks (Buildpacks) ; un Procfile définit les commandes, sinon les valeurs par défaut du langage s'appliquent. Si le service tournait sur Docker, utilisez la stratégie Dockerfile.

Render définit PORT à 10000 par défaut. Nodion définit PORT pour le processus web des apps buildpack (8080 par défaut) ; si votre app lit PORT, rien ne change. Si 10000 est codé en dur, remplacez-le. Sur les apps Dockerfile, Nodion ne définit pas PORT ; l'app écoute sur le port du processus web.

Ajoutez chaque worker en arrière-plan du même dépôt dans Processes, New process, comme processus supplémentaire, et saisissez sa commande de démarrage. Un service privé devient lui aussi un processus, avec un port. Attention : chaque processus doté d'un port reçoit un nom d'hôte public par défaut en plus de son adresse interne ; il n'existe pas de service uniquement privé. Protégez un tel port dans l'app (par une authentification, par exemple). Les noms d'hôte Nodion ne peuvent être désactivés que pour l'app entière, une fois qu'un domaine personnalisé est actif. Un worker qui ne fait que consommer une file d'attente n'a pas besoin de port. Déplacez une commande de prédéploiement vers une ligne release: du Procfile (buildpacks) ou vers la commande de release de l'app (Settings, dans la carte Preview environments, où le champ apparaît une fois les previews activées, ou release_command via l'API). Elle s'exécute une fois par déploiement, avant web ; si elle échoue, la release précédente reste en ligne.

4. Transférez les variables d'environnement

Render ne documente aucune méthode pour exporter les variables d'environnement depuis le dashboard ; l'API Render renvoie les variables d'un service, mais pas celles des groupes d'environnement (référence de l'API Render, GET /services/{serviceId}/env-vars ; pour les groupes d'environnement, voir la documentation Render). Rassemblez-les sous forme de lignes KEY=value, y compris les valeurs des groupes d'environnement, et collez-les dans Environment, Add many. Définissez les secrets avec nodion env set KEY=value --secret et les valeurs sur plusieurs lignes via la CLI ou l'API. Nodion n'a pas de fichiers secrets : stockez leur contenu dans une variable secrète (--secret) et faites en sorte que l'app la lise depuis la variable ou écrive elle-même le fichier au démarrage. Les secrets n'ont pas leur place dans l'image, comme le rappelle aussi Render.

Supprimez ensuite les variables DATABASE_URL et REDIS_URL de Render : une variable que vous définissez vous-même remplace la valeur d'une base de données rattachée. Rattachez les bases de données avec Attach database. Au sein de Nodion, la connexion passe sans TLS (sslmode=disable) ; si votre code force SSL, désactivez-le pour cette URL, et faites de même pour rediss:// vers Valkey.

5. Transférez les tâches cron

Sur Render, un cron job est un service à part entière avec une planification en UTC (documentation Render). Sur Nodion, vous l'ajoutez dans l'onglet Cron de l'app dont il utilise le code : une planification à cinq champs en UTC, la commande, un délai d'expiration de 30 minutes maximum et jusqu'à 8 tâches par app. Tant qu'une exécution est en cours, la suivante est ignorée.

6. Déployez, transférez le domaine, arrêtez Render

Déployez et vérifiez l'onglet Logs. Ajoutez ensuite le domaine dans l'onglet Domains et créez les deux enregistrements qu'affiche Nodion : TXT _nodion-challenge.your-domain et un CNAME (un ALIAS à l'apex) vers le nom d'hôte par défaut de l'app. Nodion ne fournit pas de cible pour un enregistrement A ; à l'apex, votre fournisseur DNS doit donc prendre en charge ALIAS, ANAME ou le CNAME flattening. Le certificat suit dès que le CNAME pointe vers Nodion ; comptez quelques minutes sans certificat valide et baissez le TTL au préalable.

Quand tout fonctionne, supprimez les services Render (Render CLI). Render ne conserve aucun backup d'une base de données supprimée ; gardez donc votre dump.

bashrender services delete my-service --confirm

Supprimer le service ne supprime ni la base de données ni une éventuelle instance Key Value. Sur les instances payantes, Render persiste par défaut les données Key Value sur disque (documentation Render) : un Valkey vide ne suffit que pour des caches ou des files d'attente que vous laissez se vider au préalable ; si vous avez besoin des clés, migrez-les avant de supprimer l'instance. Supprimez ensuite vous-même la base Render Postgres, avec Delete Database en bas de sa page Info (documentation Render), ainsi que toute instance Key Value ; les commandes CLI correspondantes figurent dans la référence de la Render CLI.

Ce qui fonctionne différemment

• Il n'y a ni groupes d'environnement ni fichiers secrets ; chaque variable appartient à une seule app.
• Les workers et les services privés sont des processus d'une app, et non des services distincts.
• Les tâches cron s'exécutent sur une app existante, avec sa release active.
• La CLI récupère les logs mais ne peut pas les suivre en continu ; pour les voir en direct, utilisez l'onglet Logs.

Pour aller plus loin

Nodion comparé à Render, Tarifs, Applications et Bases de données.