Ruby auf Nodion deployen

Ruby Schritt für Schritt deployen

1. Gemfile und Gemfile.lock committen Der Build führt bundle install ohne die Gruppen development und test aus, mit der Bundler-Version aus BUNDLED WITH im Gemfile.lock. Unter Rack 3 braucht eine config.ru-App zusätzlich das Gem rackup und einen Server wie Puma. Gemfile

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

2. config.ru anlegen Mit einer config.ru und ohne config/puma.rb startet Nodion bundle exec rackup config.ru -p $PORT und setzt RACK_ENV=production. Eine kleine Sinatra-App passt direkt in die Datei: config.ru

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

3. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central und lass die Build-Strategie auf Buildpacks. Nur Variablen mit dem Häkchen Build gibt es im Build, alle anderen nur zur Laufzeit. API-Keys und Passwörter markierst du als Secret.
4. Datenbank anhängen und Migrationen ausführen Lege eine PostgreSQL- oder MySQL-Datenbank in derselben Region an und hänge sie auf dem Tab Environment an; die App bekommt beim nächsten Deploy DATABASE_URL. Eine release:-Zeile in einer Procfile läuft bei jedem Build einmal, bevor die neue Version startet, zum Beispiel für die Migrationen von sinatra-activerecord. Scheitert sie, bleibt die laufende Version live. Procfile

   release: bundle exec rake db:migrate

Gut zu wissen

• Ruby-Version pinnenNodion liest .ruby-version, dann eine ruby-Zeile mit vollständiger Version im Gemfile; ohne beides bekommst du Ruby 3.4. Ruby 3.3 und 4.0 gibt es ebenfalls. Ohne BUNDLED WITH läuft Bundler 2 auf Ruby 3 und Bundler 4 auf Ruby 4.
• Puma-Config oder eine einfache app.rbGibt es config/puma.rb, startet Nodion bundle exec puma -C config/puma.rb; bind Puma dort mit port ENV.fetch("PORT", 3000). Fehlen diese Datei und config.ru, startet Nodion bundle exec ruby app.rb, und das Skript muss selbst auf 0.0.0.0 und dem PORT lauschen, den Nodion setzt.
• Sidekiq und andere WorkerErgänz die Procfile um worker: bundle exec sidekiq und eine ausdrückliche Zeile web: bundle exec rackup config.ru -p $PORT; ohne web:-Zeile wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Dann legst du auf dem Tab Processes einen Prozess worker ohne Port an. Valkey in derselben Region liefert Sidekiq die REDIS_URL.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.
• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.

Ruby auf Nodion: Fragen und Antworten