Despliega Ruby on Rails en Nodion

Despliega Ruby on Rails paso a paso

1. Haz la build con el Dockerfile generado Crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea en la región EU Central. Rails 7.1 y versiones posteriores incluyen un Dockerfile, así que el formulario preselecciona la estrategia Dockerfile. Este es el camino para apps con jsbundling, cssbundling o Vite: la build de JavaScript se ejecuta en tu Dockerfile, tal como la has configurado.
2. Define la master key y el puerto Añade en la pestaña Environment RAILS_MASTER_KEY con el contenido de config/master.key como variable secreta. En las apps con Dockerfile, Nodion no define PORT: el servidor escucha en el puerto del proceso web, que el formulario toma de EXPOSE. Rails 7.1 y 7.2 exponen el 3000 para Puma. Rails 8 expone el 80 para Thruster, que se ejecuta delante de Puma; la imagen se ejecuta con un usuario sin privilegios de root, así que define HTTP_PORT=8080 y pon 8080 como puerto del proceso web en la pestaña Processes.
3. Vincula PostgreSQL Crea una base de datos PostgreSQL en la misma región y vincúlala en la pestaña Environment; Rails usa la DATABASE_URL que recibe en el siguiente despliegue. El bin/docker-entrypoint generado ejecuta bin/rails db:prepare antes de que arranque el servidor de Rails, así que las migraciones pendientes se ejecutan cuando arranca la nueva versión. También puedes definir ./bin/rails db:migrate como comando de release de la app (campo release_command de la API, consulta la guía de Docker), que se ejecuta una vez por despliegue antes de que arranque la nueva versión.
4. Usa /up como ruta del health check Rails 7.1 y versiones posteriores responden a /up con 200 en cuanto la app ha arrancado; defínela como ruta del health check en los ajustes de la app. Nodion llama a cada instancia con su IP interna como Host, así que, si defines config.hosts, excluye /up de la autorización de hosts; si no, la release nunca llega a activarse. config/environments/production.rb

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

5. O usa buildpacks para apps con importmap Una app con importmap y sin package.json puede elegir en su lugar Buildpacks en el formulario de creación. En ese caso, Nodion ejecuta bundle install sin las gemas de development y test y assets:precompile con RAILS_ENV=production y SECRET_KEY_BASE_DUMMY=1, arranca Puma con config/puma.rb en PORT y define RAILS_SERVE_STATIC_FILES y RAILS_LOG_TO_STDOUT. Las migraciones se ejecutan desde un Procfile: Procfile

   release: bin/rails db:migrate

A tener en cuenta

• Solid Queue y SidekiqCon buildpacks, añade worker: bin/jobs (Solid Queue) o worker: bundle exec sidekiq al Procfile junto con una línea web: bundle exec puma -C config/puma.rb explícita; sin una línea web:, la primera entrada del Procfile que no sea release: se convierte en el comando por defecto. Después añade en la pestaña Processes un proceso llamado worker sin puerto. Con el Dockerfile, en cambio, asigna a ese proceso el comando ./bin/jobs o bundle exec sidekiq. Valkey en la misma región le da a Sidekiq su REDIS_URL.
• Las bases de datos adicionales de Rails 8Una app de Rails 8 generada para PostgreSQL también incluye en config/database.yml las bases de datos cache, queue y cable para producción, y DATABASE_URL solo define la principal. Antes del primer despliegue, asigna una conexión también a las demás o elimina las que tu app no use.
• Versión de RubyCon el Dockerfile, la versión de Ruby sale de RUBY_VERSION en el Dockerfile. Con buildpacks, Nodion lee .ruby-version o la línea ruby del Gemfile y ofrece 3.3, 3.4 (por defecto) y 4.0.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Alternativas a Heroku con hosting en la UE: 5 opciones Una plataforma alemana y clouds estadounidenses con regiones en la UE, comparados por sede, regiones y bases de datos gestionadas.
• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.

Ruby on Rails en Nodion: preguntas y respuestas