Déployez Ruby sur Nodion

Déployez Ruby étape par étape

1. Commitez Gemfile et Gemfile.lock Le build exécute bundle install sans les groupes development et test, avec la version de Bundler indiquée par BUNDLED WITH dans Gemfile.lock. Avec Rack 3, une app fondée sur config.ru a aussi besoin de la gem rackup et d'un serveur comme Puma. Gemfile

   source "https://rubygems.org"
   
   gem "sinatra"
   gem "rackup"
   gem "puma"

2. Ajoutez un config.ru Avec un config.ru et sans config/puma.rb, Nodion lance bundle exec rackup config.ru -p $PORT et définit RACK_ENV=production. Une petite app Sinatra tient dans le fichier lui-même : config.ru

   require "sinatra/base"
   
   class App < Sinatra::Base
     get "/" do
       "Hello from Frankfurt"
     end
   end
   
   run App

3. Créez l'app Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, choisissez la branche et la région EU Central, et laissez la stratégie de build sur Buildpacks. Seules les variables avec l'option Build existent pendant le build ; toutes les autres sont définies à l'exécution. Marquez les clés d'API et les mots de passe comme secrets.
4. Rattachez une base de données et exécutez les migrations Créez une base de données PostgreSQL ou MySQL dans la même région et rattachez-la dans l'onglet Environment ; l'app reçoit DATABASE_URL au déploiement suivant. Une ligne release: dans un Procfile s'exécute une fois par build avant le démarrage de la nouvelle version, par exemple pour les migrations de sinatra-activerecord. Si elle échoue, la version en cours reste en ligne. Procfile

   release: bundle exec rake db:migrate

Bon à savoir

• Fixez la version de RubyNodion lit .ruby-version, puis une ligne ruby avec une version complète dans le Gemfile ; sans l'un ni l'autre, vous obtenez Ruby 3.4. Ruby 3.3 et 4.0 sont aussi disponibles. Sans BUNDLED WITH, Bundler 2 tourne sur Ruby 3 et Bundler 4 sur Ruby 4.
• Configuration Puma ou simple app.rbSi config/puma.rb existe, Nodion exécute bundle exec puma -C config/puma.rb : configurez-y donc le port de Puma avec port ENV.fetch("PORT", 3000). Sans ce fichier ni config.ru, Nodion exécute bundle exec ruby app.rb, et le script doit écouter sur 0.0.0.0 et sur le PORT défini par Nodion.
• Sidekiq et autres workersAjoutez worker: bundle exec sidekiq au Procfile ainsi qu'une ligne explicite web: bundle exec rackup config.ru -p $PORT ; 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. Valkey dans la même région fournit à Sidekiq sa REDIS_URL.

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 sur Nodion : questions et réponses