Déployer Phoenix quand votre file de tâches est déjà dans la release

La plupart des frameworks ont besoin d’un deuxième processus déployable juste pour faire tourner des tâches de fond — un dyno worker, un conteneur séparé, quelque chose à garder synchronisé avec le build de l’application web. Phoenix n’en a généralement pas besoin, parce qu’Oban tourne comme partie du même arbre de supervision OTP que l’endpoint web lui-même : le gestionnaire de tâches n’est pas une deuxième application, il est déjà vivant au moment où web démarre.

Ce qui est lu depuis mix.exs

• Les entrepôts de données sont détectés depuis les dépendances, pas déclarés deux fois : ecto_sql/postgrex provisionne Postgres, ecto_ch/ch provisionne ClickHouse, redix provisionne Redis.
• SECRET_KEY_BASE est généré une fois, pas laissé à vous de produire et de stocker vous-même.
• MIX_ENV=prod et PHX_SERVER=true sont réglés automatiquement — les deux indicateurs d’environnement dont une release Phoenix compilée a réellement besoin pour servir du trafic plutôt que de rester inactive.

railyard create my-app https://github.com/me/my-app --addons postgres

ou la même URL Git depuis le tableau de bord une fois GitHub connecté.

La partie qui est vraiment différente dans les releases compilées

Une release Elixir compilée n’a pas de mix à l’exécution — la commande de migration qui fonctionne en développement (mix ecto.migrate) n’existe pas dans l’artefact qui est réellement livré. Railyard trouve où la release met son propre migrateur et lance celui-là à la place (bin/migrate si la release en définit un, sinon bin/<app> eval), et mix phx.server devient bin/<app> start de la même façon. Cette distinction — commande de développement contre ce que la release compilée expose réellement — est la chose la plus courante qui fait trébucher un premier déploiement Elixir sur n’importe quelle plateforme, et elle est gérée avant même que la première migration ne tourne.

Si un nœud de worker dédié en vaut vraiment la peine

Oban n’a besoin d’aucun deuxième processus pour la plupart des applications — mais si le volume de tâches est assez élevé pour qu’une file lente puisse commencer à affamer les requêtes web, la séparer sur son propre nœud reste un ajout d’une ligne, pas un changement d’architecture :

web:    bin/my_app start
worker: bin/my_app eval "MyApp.Release.worker()"

railyard scale my-app worker=2

Même release, même build, démarré différemment — ajoutez-le ou modifiez-le depuis l’onglet Workers sans changement de dépôt requis.

Config et secrets

Tout ce que config/runtime.exs lit avec System.get_env/2 — BASE_URL, HTTP_PORT, LISTEN_IP, DATABASE_URL, CLICKHOUSE_DATABASE_URL et le reste — est une variable simple sous Variables, ou réglée via railyard env:set my-app KEY=VALUE, jamais intégrée dans la release compilée. La même release tourne sans changement de staging jusqu’à la production.

Référence complète : Documentation Phoenix et Elixir, Workers et tâches planifiées.