Déployez Ruby on Rails sur Nodion

Déployez Ruby on Rails étape par étape

1. Lancez le build avec le Dockerfile généré Créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central. Rails 7.1 et les versions suivantes fournissent un Dockerfile : le formulaire présélectionne donc la stratégie Dockerfile. C'est la voie à suivre pour les apps avec jsbundling, cssbundling ou Vite : le build JavaScript s'exécute dans votre Dockerfile, tel que vous l'avez configuré.
2. Définissez la master key et le port Dans l'onglet Environment, ajoutez RAILS_MASTER_KEY comme secret, avec le contenu de config/master.key. Nodion ne définit pas de PORT pour les apps avec Dockerfile : le serveur écoute sur le port du processus web, que le formulaire reprend de EXPOSE. Rails 7.1 et 7.2 exposent le port 3000 pour Puma. Rails 8 expose le port 80 pour Thruster, qui tourne devant Puma ; l'image s'exécute avec un utilisateur non root, définissez donc HTTP_PORT=8080 et indiquez 8080 comme port du processus web dans l'onglet Processes.
3. Rattachez PostgreSQL Créez une base de données PostgreSQL dans la même région et rattachez-la dans l'onglet Environment ; Rails utilise la DATABASE_URL qu'il reçoit au déploiement suivant. Le bin/docker-entrypoint généré exécute bin/rails db:prepare avant le démarrage du serveur Rails : les migrations en attente s'exécutent donc au démarrage de la nouvelle version. Vous pouvez aussi définir ./bin/rails db:migrate comme commande de release de l'app (champ d'API release_command, voir le guide Docker), qui s'exécute une fois par déploiement avant le démarrage de la nouvelle version.
4. Utilisez /up comme chemin du health check Rails 7.1 et les versions suivantes répondent 200 sur /up dès que l'app a démarré ; définissez ce chemin comme chemin du health check dans les paramètres de l'app. Nodion appelle chaque instance avec son IP interne comme Host : si vous définissez config.hosts, excluez donc /up de l'autorisation des hôtes, sinon la release n'est jamais mise en ligne. config/environments/production.rb

   config.hosts << "www.example.com"
   config.host_authorization = { exclude: ->(request) { request.path == "/up" } }

5. Ou utilisez les buildpacks pour les apps importmap Une app avec importmap et sans package.json peut choisir à la place Buildpacks dans le formulaire de création. Nodion exécute alors bundle install sans les gems de development et de test, puis assets:precompile avec RAILS_ENV=production et SECRET_KEY_BASE_DUMMY=1, démarre Puma avec config/puma.rb sur PORT et définit RAILS_SERVE_STATIC_FILES et RAILS_LOG_TO_STDOUT. Les migrations s'exécutent depuis un Procfile : Procfile

   release: bin/rails db:migrate

Bon à savoir

• Solid Queue et SidekiqAvec les buildpacks, ajoutez worker: bin/jobs (Solid Queue) ou worker: bundle exec sidekiq au Procfile ainsi qu'une ligne explicite web: bundle exec puma -C config/puma.rb ; sans ligne web:, la première entrée du Procfile autre que release: devient la commande par défaut. Ajoutez ensuite dans l'onglet Processes un processus nommé worker sans port. Avec le Dockerfile, donnez plutôt à ce processus la commande ./bin/jobs ou bundle exec sidekiq. Valkey dans la même région fournit à Sidekiq sa REDIS_URL.
• Les bases de données supplémentaires de Rails 8Une app Rails 8 générée pour PostgreSQL déclare aussi, dans config/database.yml, les bases cache, queue et cable pour la production, et DATABASE_URL ne définit que la base principale. Avant le premier déploiement, donnez aussi une connexion aux autres, ou supprimez celles que votre app n'utilise pas.
• Version de RubyAvec le Dockerfile, la version de Ruby vient de RUBY_VERSION dans le Dockerfile. Avec les buildpacks, Nodion lit .ruby-version ou la ligne ruby du Gemfile et propose 3.3, 3.4 (par défaut) et 4.0.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Alternatives à Heroku avec hébergement dans l'UE : 5 options Une plateforme allemande et des clouds américains avec des régions dans l'UE, comparés par siège, régions et bases de données managées.
• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.

Ruby on Rails sur Nodion : questions et réponses