Fai il deploy di Ruby on Rails su Nodion

Deploy di Ruby on Rails passo dopo passo

1. Fai la build dal Dockerfile generato Crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea nella regione EU Central. Rails 7.1 e versioni successive includono un Dockerfile, quindi il modulo preseleziona la strategia Dockerfile. È la strada per le app con jsbundling, cssbundling o Vite: la build JavaScript gira nel tuo Dockerfile, esattamente come l'hai configurata.
2. Imposta la master key e la porta Aggiungi RAILS_MASTER_KEY come variabile segreta con il contenuto di config/master.key nella scheda Environment. Per le app con Dockerfile Nodion non imposta PORT: il server ascolta sulla porta del processo web, che il modulo prende da EXPOSE. Rails 7.1 e 7.2 espongono la 3000 per Puma. Rails 8 espone la 80 per Thruster, che gira davanti a Puma; l'immagine gira con un utente non root, quindi imposta HTTP_PORT=8080 e indica 8080 come porta del processo web nella scheda Processes.
3. Collega PostgreSQL Crea un database PostgreSQL nella stessa regione e collegalo nella scheda Environment; Rails usa la DATABASE_URL che riceve al deploy successivo. Il bin/docker-entrypoint generato esegue bin/rails db:prepare prima dell'avvio del server Rails, quindi le migrazioni in sospeso vengono eseguite quando parte la nuova versione. Puoi anche impostare ./bin/rails db:migrate come comando di release dell'app (campo API release_command, vedi la guida Docker), che viene eseguito una volta per deploy prima che parta la nuova versione.
4. Usa /up come percorso dell'health check Rails 7.1 e versioni successive rispondono a /up con 200 appena l'app è avviata; impostalo come percorso dell'health check nelle impostazioni dell'app. Nodion chiama ogni istanza con il suo IP interno come Host, quindi se imposti config.hosts, escludi /up dall'autorizzazione degli host, altrimenti la release non va mai online. config/environments/production.rb

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

5. Oppure usa i buildpack per le app con importmap Un'app con importmap e senza package.json può invece scegliere Buildpacks nel modulo di creazione. In quel caso Nodion esegue bundle install senza le gem di development e test e assets:precompile con RAILS_ENV=production e SECRET_KEY_BASE_DUMMY=1, avvia Puma con config/puma.rb su PORT e imposta RAILS_SERVE_STATIC_FILES e RAILS_LOG_TO_STDOUT. Le migrazioni girano da un Procfile: Procfile

   release: bin/rails db:migrate

Da sapere

• Solid Queue e SidekiqCon i buildpack, aggiungi al Procfile worker: bin/jobs (Solid Queue) o worker: bundle exec sidekiq insieme a una riga esplicita web: bundle exec puma -C config/puma.rb; senza una riga web:, la prima voce del Procfile diversa da release: diventa il comando predefinito. Poi aggiungi un processo chiamato worker senza porta nella scheda Processes. Con il Dockerfile, assegna invece a quel processo il comando ./bin/jobs o bundle exec sidekiq. Valkey nella stessa regione fornisce a Sidekiq la sua REDIS_URL.
• I database aggiuntivi di Rails 8Un'app Rails 8 generata per PostgreSQL elenca in config/database.yml anche i database cache, queue e cable per la produzione, e DATABASE_URL imposta solo quello principale. Prima del primo deploy, assegna una connessione anche agli altri, oppure rimuovi quelli che la tua app non usa.
• Versione di RubyCon il Dockerfile, Ruby viene da RUBY_VERSION nel Dockerfile. Con i buildpack, Nodion legge .ruby-version o la riga ruby nel Gemfile e offre 3.3, 3.4 (predefinita) e 4.0.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Alternative a Heroku con hosting UE: 5 opzioni a confronto Una piattaforma tedesca e cloud statunitensi con regioni nell'UE, a confronto per sede, regioni e database gestiti.
• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.

Ruby on Rails su Nodion: domande e risposte