Depuis Fly.io

Pourquoi les équipes quittent Fly

Fly facilite l’exécution de conteneurs près de vos utilisateurs. Mais la facturation à l’usage est difficile à prévoir, la plateforme décide des régions et des tailles de machines que vous obtenez, et « Fly Postgres » est un Postgres que vous gérez vous-même sur des machines Fly.

Railyard vous offre le même mode de fonctionnement centré sur les conteneurs, sur un serveur Linux de votre propre compte cloud (comme DigitalOcean, Hetzner, Vultr ou AWS), ou sur n’importe quelle machine Ubuntu accessible en SSH. Votre fournisseur vous facture directement, à son prix, et Railyard gère Postgres, Redis et les sauvegardes pour vous.

La façon rapide : l’outil d’importation (bêta)

Applications → New app → Import from Heroku / Render / Fly. Choisissez Fly.io, collez un jeton obtenu avec fly tokens create org et indiquez votre organisation Fly (par défaut, personal). Choisissez une application, vérifiez ce qui sera copié, puis importez et déployez. Railyard ne garde votre jeton que pour cette importation et l’oublie après 30 minutes.

Ce que l’outil d’importation récupère depuis l’API Machines de Fly :

• L’image exacte que Fly exécute, récupérée avec votre jeton comme mot de passe du registre, donc rien n’est reconstruit.
• Les variables d’environnement de la configuration de la machine, et le port interne.
• Les noms des secrets. Fly ne révèle jamais les valeurs des secrets, donc la page de vérification les liste pour que vous les saisissiez à nouveau.

Ce qu’il ne fait que signaler :

• Les autres groupes de processus (un worker, par exemple) ne sont pas copiés. Ajoutez-les comme workers.
• Les volumes démarrent vides. Copiez leurs fichiers vous-même (voir plus bas).
• Les données Postgres ne sont pas copiées par l’outil d’importation Fly. Déplacez-les avec une sauvegarde (voir plus bas).
• Les domaines sont listés, pas rattachés. Ajoutez-les une fois la nouvelle application en ligne.

Bêta : l’outil d’importation est testé contre les réponses documentées de l’API de Fly, et en production il interroge l’API de Fly. Il n’a pas encore été testé de bout en bout sur un vrai compte Fly. Si quelque chose ne passe pas, utilisez les étapes manuelles ci-dessous et dites-le-nous.

La façon manuelle

1. Ajoutez un serveur. Railyard peut en créer un dans votre compte cloud, ou vous pouvez en rattacher un que vous avez déjà. Voir Ajouter un serveur.
2. Créez l’application. Si votre dépôt a un Dockerfile, comme la plupart des applications Fly, pointez Railyard vers le dépôt et il construit à partir de celui-ci. Ou déployez l’image que vous poussez déjà vers un registre. Voir Déployer une image Docker.
3. Définissez le port. Utilisez le internal_port de la section [http_service] ou [[services]] de votre fly.toml.
4. Apportez votre configuration. Copiez le bloc [env] de fly.toml dans Variables. fly secrets list montre les noms des secrets, puis collez les valeurs depuis l’endroit où vous les gardez.
5. Ajoutez une base de données. Rattachez Postgres (et Redis si vous l’utilisez). Railyard crée la base de données et définit DATABASE_URL / REDIS_URL.
6. Déployez et vérifiez l’application sur son adresse sslip.io temporaire.
7. Déplacez les données. Ouvrez un tunnel avec fly proxy 15432:5432 -a <your-postgres-app>, exécutez pg_dump -Fc contre localhost:15432, puis téléversez la sauvegarde avec Resources → Import data sur l’application Railyard. Le téléversement affiche sa progression, et vous pouvez l’annuler. Pour les fichiers sur un volume Fly, utilisez fly ssh sftp get (ou tar via fly ssh console) et restaurez-les dans le volume ou le bucket de l’application.
8. Basculez le DNS. Ajoutez votre domaine dans Railyard, puis pointez l’enregistrement vers votre serveur. Fly continue de répondre jusqu’au changement de l’enregistrement, donc rien ne s’arrête. Puis réduisez l’application Fly à zéro et supprimez-la.

Correspondance des concepts Fly

Fly	Railyard
Machines dans plusieurs régions	Un ou plusieurs serveurs qui vous appartiennent. Le processus web d’une application peut tourner sur plusieurs serveurs derrière le serveur principal
Groupes de processus ([processes])	Types de processus : web plus les workers, depuis un Procfile ou définis à la main
release_command	Commande de release, exécutée une fois avant que la nouvelle version ne reçoive du trafic
Vérifications de santé	Un chemin de vérification. La nouvelle version doit le passer avant que le trafic ne bascule
Volumes	Volumes sur le serveur, avec sauvegardes
Fly Postgres / Managed Postgres	Postgres géré sur votre serveur ou sur un serveur de base de données, avec sauvegardes vérifiées et restauration à un instant précis
fly deploy	git push, railyard deploy, ou un push vers GitHub
fly logs / fly ssh console	railyard logs --follow / railyard run et l’onglet Console
Arrêt automatique des machines	Mise en veille des applications : les stagings inactifs se mettent en veille et se réveillent à la prochaine requête

Ce qui change

Railyard n’a pas d’edge anycast. Votre application est servie depuis la région de votre serveur, et il n’y a pas encore de routage automatique multi-région. En contrepartie, la facture est un prix de serveur fixe et prévisible, les machines vous appartiennent, et si vous arrêtez d’utiliser Railyard, votre application continue de tourner.