Phoenix et Elixir

Phoenix et Elixir

Déployez Phoenix avec Postgres, ClickHouse ou Redis, des workers Oban et des migrations au moment de la release.

  • 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 pas mix à l’exécution, donc Railyard trouve la release où que l’image la place et exécute son migrateur (bin/migrate si présent, sinon bin/<app> eval). mix phx.server devient bin/<app> start de 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_BASE est généré.
  • MIX_ENV=prod et PHX_SERVER=true sont 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, remplit ecto.migrate, la base de données provisionnée et SECRET_KEY_BASE, et déploie à chaque push.
  • Depuis la CLI : railyard create my-app https://github.com/me/my-app --addons postgres, ou railyard git:remote && git push railyard main depuis 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.