Phoenix et Elixir
Déployez Phoenix avec Postgres, ClickHouse ou Redis, des workers Oban et des migrations au moment de la release.
Étape par étape : Déployer Phoenix sur DigitalOcean · Déployer Phoenix sur Hetzner · Déployer Phoenix sur Vultr · Déployer Phoenix sur OVHcloud · Déployer Phoenix sur Scaleway · Déployer Phoenix sur UpCloud
- Sources de données depuis
mix.exs:ecto_sql/postgrex→ Postgres,ecto_ch/ch→ ClickHouse,redix→ Redis. - Migrations :
mix ecto.migrate. Les releases compilées n’ont pasmixà l’exécution, donc Railyard trouve la release où que l’image la place et exécute son migrateur (bin/migratesi présent, sinonbin/<app> eval).mix phx.serverdevientbin/<app> startde la même façon. - Les variables lues dans
config/runtime.exs(BASE_URL,HTTP_PORT,LISTEN_IP,DATABASE_URL,CLICKHOUSE_DATABASE_URL…) sont reliées automatiquement;SECRET_KEY_BASEest généré. MIX_ENV=prodetPHX_SERVER=truesont définis.
Les tâches en arrière-plan n’ont généralement besoin d’aucun second processus
La plupart des applications Elixir exécutent leurs tâches avec Oban — une queue adossée à Postgres, démarrée depuis le même arbre de supervision que le endpoint web, donc déjà en marche au moment où web démarre, sans aucun worker séparé à déclarer ou à mettre à l’échelle. C’est quand même le modèle 12-factor : l’exécuteur de tâches n’est qu’un des rôles que joue déjà votre release OTP unique, pas un second déployable à garder synchronisé avec le premier.
Si vous voulez vraiment un nœud worker dédié — séparer le traitement des tâches sur son propre processus pour qu’une queue lente ne prive pas le web de ressources — déclarez-le dans un Procfile et faites lire à votre release un flag ou une variable d’environnement pour sauter le démarrage du endpoint :
web: bin/my_app start
worker: bin/my_app eval "MyApp.Release.worker()"
Ajoutez ou modifiez des processus depuis l’onglet Workers de l’application sans toucher au dépôt, et mettez l’un ou l’autre à l’échelle depuis la CLI :
railyard scale my-app worker=2
Configuration et secrets
Tout ce que config/runtime.exs lit avec System.get_env/2 est une simple variable d’environnement : définissez-la sous Variables, ou avec railyard env:set my-app KEY=VALUE depuis la CLI, et la même release compilée tourne sans changement de staging jusqu’en production — la parité dev/prod, pas un build différent par environnement. Pour pointer vers une base de données, ClickHouse ou un Redis qui tourne comme son propre service sur le canvas, référencez-le avec ${{redis.RAILYARD_PRIVATE_URL}} — résolu par environnement. Voir Variables et secrets.
Déployez-la
- Depuis un dépôt : collez l’URL Git, ou choisissez-la dans le sélecteur une fois GitHub connecté — Railyard lit
mix.exs, remplitecto.migrate, la base de données provisionnée etSECRET_KEY_BASE, et déploie à chaque push. - Depuis la CLI :
railyard create my-app https://github.com/me/my-app --addons postgres, ourailyard git:remote && git push railyard maindepuis le dépôt. - En un clic : ajoutez le bouton de déploiement à votre README, ou publiez-la dans le catalogue de modèles pour que n’importe qui puisse la lancer avec ses addons et variables déjà remplis.