Faire migrer une application Rails hors de Heroku sans la réécrire

La raison pour laquelle la plupart des équipes restent sur une plateforme gérée plus longtemps que prévu n’est pas le prix. C’est que la migration a l’air d’un projet sans fin claire. Ce billet est le chemin le plus court que nous connaissions, dans l’ordre qui garde l’application en service à chaque étape.

Étape 1 : déployez-la sans la changer, avec des buildpacks

Ne commencez pas par écrire un Dockerfile. Commencez par prouver que l’application tourne ailleurs, tout simplement.

Cloud Native Buildpacks lit votre dépôt de la même façon que le build de Heroku, en utilisant des couches d’exécution préconstruites plutôt qu’en compilant un langage depuis la source. En pratique, une application Rails ou Django standard se construit sans qu’un seul fichier soit modifié.

Si elle démarre, vous avez déjà prouvé la partie difficile : rien dans votre application ne dépendait vraiment de la plateforme.

Étape 2 : déplacez les services de données

Votre application a presque certainement besoin de Postgres et de Redis. Provisionnez-les comme addons, et Railyard injecte les chaînes de connexion dans l’environnement de la même façon que vous en avez l’habitude.

Deux choses à vérifier :

• Extensions. Si vous utilisez pgvector, PostGIS ou un équivalent, assurez-vous que le Postgres provisionné les inclut. Le nôtre inclut pgvector.
• Le dump. Restaurez un vrai dump de production dans la nouvelle base avant la bascule, et mesurez le temps que ça prend. C’est l’étape que les équipes sous-estiment.

Étape 3 : déclarez vos processus

Si votre application a un Procfile, Railyard le lit : processus web, processus worker, et le hook release: qui exécute les migrations avant que quoi que ce soit ne serve du trafic. Ce dernier point compte plus qu’il n’y paraît : c’est ce qui empêche une migration de s’exécuter contre une version du code qui a déjà commencé à recevoir des requêtes.

Étape 4 : passez à un Dockerfile, si vous le voulez

Une fois qu’elle fonctionne, un Dockerfile vous donne la reproductibilité et des builds à chaud plus rapides. Ce n’est pas obligatoire, et c’est bien plus facile à écrire pour une application que vous pouvez déjà déployer que pour une que vous ne pouvez pas.

Avec un cache de couches appuyé sur un registre, les rebuilds à chaud d’une grosse application Rails prennent environ une minute et demie.

Ce qui casse vraiment

À force de le refaire, les problèmes récurrents sont :

1. Les applications qui apportent leur propre infrastructure. Certaines applications démarrent tout leur environnement pendant assets:precompile et ont besoin qu’un cluster de recherche existe. Ça échoue sur n’importe quelle plateforme sans l’addon : ce n’est pas un problème de migration, c’est une exigence de l’application que vous aviez oubliée.
2. La mémoire de build sur de petits serveurs. Un serveur de 2 Go qui compile des extensions natives peut manquer de mémoire. Construisez soit sur un builder dédié, soit avec un plafond de mémoire pour le build, afin qu’il échoue proprement plutôt que d’emporter la machine avec lui.
3. Le disque éphémère présumé. Tout ce qui écrit sur le disque local a besoin d’un volume persistant, sinon le prochain déploiement le fait disparaître sans bruit.

Ce que vous obtenez à la fin

Votre application tourne sur des serveurs dans la région que vous avez choisie, au prix de votre fournisseur, sans majoration, et si vous arrêtez un jour de payer pour le plan de contrôle, les conteneurs continuent de servir le trafic. Le flux de travail reste le même que celui que vous avez quitté : vous faites un push, vous regardez le build, vous revenez en arrière si quelque chose ne va pas.