Ruby on Rails auf Nodion deployen

Ruby on Rails Schritt für Schritt deployen

1. Mit dem generierten Dockerfile bauen Lege eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an. Rails 7.1 und neuer bringen ein Dockerfile mit, deshalb wählt das Formular die Dockerfile-Strategie vor. Das ist der Weg für Apps mit jsbundling, cssbundling oder Vite: Der JavaScript-Build läuft in deinem Dockerfile, so wie du es eingerichtet hast.
2. Master Key und Port setzen Leg auf dem Tab Environment RAILS_MASTER_KEY mit dem Inhalt von config/master.key als Secret an. Für Dockerfile-Apps setzt Nodion kein PORT: Der Server lauscht auf dem Port des Web-Prozesses, den das Formular aus EXPOSE übernimmt. Rails 7.1 und 7.2 nutzen Port 3000 für Puma. Rails 8 nutzt Port 80 für Thruster, der vor Puma läuft; das Image läuft als Nicht-Root-User, setz also HTTP_PORT=8080 und trag auf dem Tab Processes 8080 als Port des Web-Prozesses ein.
3. PostgreSQL anhängen Lege eine PostgreSQL-Datenbank in derselben Region an und hänge sie auf dem Tab Environment an; Rails nutzt die DATABASE_URL, die beim nächsten Deploy ankommt. Das generierte bin/docker-entrypoint führt vor dem Start des Rails-Servers bin/rails db:prepare aus, offene Migrationen laufen also, wenn die neue Version hochfährt. Alternativ setzt du ./bin/rails db:migrate als Release Command der App (API-Feld release_command, siehe Docker-Guide); der läuft bei jedem Deploy einmal, bevor die neue Version startet.
4. /up als Health-Check-Pfad nutzen Rails 7.1 und neuer beantworten /up mit 200, sobald die App gebootet ist; trag den Pfad in den App-Einstellungen als Health-Check-Pfad ein. Nodion ruft jede Instanz mit ihrer internen IP als Host auf. Setzt du config.hosts, nimm /up von der Host-Prüfung aus, sonst geht das Release nie live. config/environments/production.rb

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

5. Oder Buildpacks für Importmap-Apps Eine App mit Importmap und ohne package.json kann beim Anlegen stattdessen Buildpacks wählen. Nodion führt dann bundle install ohne Development- und Test-Gems aus, dazu assets:precompile mit RAILS_ENV=production und SECRET_KEY_BASE_DUMMY=1, startet Puma mit config/puma.rb auf PORT und setzt RAILS_SERVE_STATIC_FILES und RAILS_LOG_TO_STDOUT. Migrationen laufen über eine Procfile: Procfile

   release: bin/rails db:migrate

Gut zu wissen

• Solid Queue und SidekiqMit Buildpacks ergänzt du die Procfile um worker: bin/jobs (Solid Queue) oder worker: bundle exec sidekiq und eine ausdrückliche Zeile web: bundle exec puma -C config/puma.rb; 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. Beim Dockerfile gibst du diesem Prozess direkt den Befehl ./bin/jobs oder bundle exec sidekiq. Valkey in derselben Region liefert Sidekiq die REDIS_URL.
• Die zusätzlichen Datenbanken von Rails 8Eine Rails-8-App, die für PostgreSQL erzeugt wurde, führt in config/database.yml für Production zusätzlich die Datenbanken cache, queue und cable, und DATABASE_URL setzt nur die primäre. Gib den anderen vor dem ersten Deploy ebenfalls eine Verbindung oder entferne die, die deine App nicht nutzt.
• Ruby-VersionBeim Dockerfile kommt Ruby aus RUBY_VERSION im Dockerfile. Mit Buildpacks liest Nodion .ruby-version oder die ruby-Zeile im Gemfile und bietet 3.3, 3.4 (Standard) und 4.0.

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 on Rails auf Nodion: Fragen und Antworten