Déployer Rails sans écrire de Dockerfile

L’hypothèse derrière la plupart des guides « comment conteneuriser Rails » est qu’il faut d’abord écrire un Dockerfile. La plupart du temps, non — la méthode de build ne devient votre problème que quand les valeurs par défaut n’arrivent vraiment pas à comprendre votre application, ce qui est plus rare qu’il n’y paraît.

Ce qui choisit vraiment la méthode de build

Méthode	Quand elle s’exécute
Dockerfile	le dépôt en a un qui construit vraiment l’application — un Dockerfile de développement qui attend un bind mount est ignoré automatiquement, pas exécuté aveuglément
Railpack	la valeur par défaut pour tout dépôt sans Dockerfile
Nixpacks	solution de repli quand Railpack ne peut pas planifier le dépôt
Buildpacks	seulement quand choisi explicitement sous Settings → Build method

Une application Rails toute neuve sans Dockerfile se construit sur Railpack sans rien écrire à la main. L’ordre compte plus que les noms : Railyard vérifie d’abord s’il y a un vrai Dockerfile, et ne se tourne vers les builders automatiques que s’il n’y en a pas.

Ce qu’une application Rails reçoit sans qu’on le demande

C’est la partie qui remplace ce qu’un Dockerfile écrit à la main devrait sinon faire :

• RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES et RAILS_LOG_TO_STDOUT sont définis si vous ne l’avez pas déjà fait.
• Les assets se construisent avec SECRET_KEY_BASE_DUMMY=1, donc un vrai secret n’est pas nécessaire au moment du build — SECRET_KEY_BASE lui-même est généré une fois et chiffré.
• pg, mysql2/trilogy, et redis/sidekiq dans le Gemfile correspondent à la base de données gérée adéquate — les bases supplémentaires de Rails 8 (cache, queue, cable) déclarées dans config/database.yml reçoivent chacune leur propre URL de connexion automatiquement.
• Sidekiq, Solid Queue, GoodJob, Resque ou Delayed Job — celui qui est réellement dans le Gemfile.lock — est proposé comme processus worker.
• Active Storage sur disque reçoit un volume persistant sans aucune configuration; attachez un bucket à la place et les variables S3 s’injectent de la même façon.
• assets:precompile s’exécute dans l’étape de build automatiquement, toolchain Node inclus — une étape tailwindcss:build ou esbuild enchaînée dessus fonctionne simplement, sans étape de Dockerfile séparée.

Quand vous avez vraiment besoin d’en écrire un

Un Dockerfile mérite sa place quand l’application dépend de quelque chose de vraiment extérieur à l’écosystème Ruby — un binaire compilé que les builders automatiques ne savent pas installer, une étape d’exécution non standard, une image de base exigée pour des raisons de conformité. En dehors de ça, le chemin automatique gère même les vieilles gems natives (nio4r, Puma 5 et antérieurs) qui compilent proprement sous le GCC actuel sans aucun changement de Dockerfile.

L’étape de release exécute bin/rails db:prepare avant que chaque version ne prenne le trafic par défaut — une ligne release: d’un Procfile l’emporte si vous en avez déjà une. Ne définissez une release_command personnalisée que quand db:prepare ne suffit vraiment pas, comme un script de migration de données ponctuel.

Référence complète du framework : Rails, et ce que l’étape de build fait vraiment : Méthodes de build.