Despliega Ruby en Nodion

Despliega Ruby paso a paso

1. Haz commit de Gemfile y Gemfile.lock La build ejecuta bundle install sin los grupos development y test, con la versión de Bundler que indica BUNDLED WITH en Gemfile.lock. Con Rack 3, una app con config.ru también necesita la gema rackup y un servidor como Puma. Gemfile

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

2. Añade un config.ru Con un config.ru y sin config/puma.rb, Nodion arranca bundle exec rackup config.ru -p $PORT y define RACK_ENV=production. Una pequeña app Sinatra cabe en el propio archivo: config.ru

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

3. Crea la app En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea, elige la rama y la región EU Central, y deja la estrategia de build en Buildpacks. Durante la build solo existen las variables con la casilla Build marcada; todas las demás se definen en tiempo de ejecución. Marca las claves de API y las contraseñas como secretas.
4. Vincula una base de datos y ejecuta las migraciones Crea una base de datos PostgreSQL o MySQL en la misma región y vincúlala en la pestaña Environment; la app recibe DATABASE_URL en el siguiente despliegue. Una línea release: en un Procfile se ejecuta una vez por build antes de que arranque la nueva versión, por ejemplo con las migraciones de sinatra-activerecord. Si falla, la versión en ejecución sigue activa. Procfile

   release: bundle exec rake db:migrate

A tener en cuenta

• Fija la versión de RubyNodion lee .ruby-version y después una línea ruby con la versión completa en el Gemfile; si no hay ninguna de las dos, obtienes Ruby 3.4. También están disponibles Ruby 3.3 y 4.0. Sin BUNDLED WITH, en Ruby 3 se usa Bundler 2 y en Ruby 4, Bundler 4.
• Configuración de Puma o un simple app.rbSi existe config/puma.rb, Nodion ejecuta bundle exec puma -C config/puma.rb, así que configura ahí el puerto de Puma con port ENV.fetch("PORT", 3000). Si no existe ese archivo ni config.ru, Nodion ejecuta bundle exec ruby app.rb, y el script tiene que escuchar en 0.0.0.0 y en el PORT que define Nodion.
• Sidekiq y otros workersAñade worker: bundle exec sidekiq al Procfile junto con una línea web: bundle exec rackup config.ru -p $PORT 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. Valkey en la misma región le da a Sidekiq su REDIS_URL.

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 en Nodion: preguntas y respuestas