Faça deploy de Ruby on Rails na Nodion

Faça deploy de Ruby on Rails passo a passo

1. Faça o build com o Dockerfile gerado Crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central. O Rails 7.1 e as versões posteriores incluem um Dockerfile, por isso o formulário pré-seleciona a estratégia Dockerfile. É este o caminho para aplicações com jsbundling, cssbundling ou Vite: o build de JavaScript é executado no seu Dockerfile, tal como o configurou.
2. Defina a chave mestra e a porta No separador Environment, adicione RAILS_MASTER_KEY com o conteúdo de config/master.key como variável secreta. A Nodion não define PORT para aplicações com Dockerfile: o servidor escuta na porta do processo web, que o formulário preenche a partir de EXPOSE. O Rails 7.1 e 7.2 expõem a porta 3000 para o Puma. O Rails 8 expõe a porta 80 para o Thruster, que fica à frente do Puma; a imagem é executada com um utilizador sem privilégios de root, por isso defina HTTP_PORT=8080 e indique 8080 como porta do processo web no separador Processes.
3. Associe o PostgreSQL Crie uma base de dados PostgreSQL na mesma região e associe-a no separador Environment; o Rails usa a DATABASE_URL que recebe no deploy seguinte. O bin/docker-entrypoint gerado executa bin/rails db:prepare antes de o servidor Rails arrancar, por isso as migrações pendentes são executadas quando a nova versão arranca. Também pode definir ./bin/rails db:migrate como comando de release da aplicação (campo release_command da API, consulte o guia de Docker), que é executado uma vez por deploy antes de a nova versão arrancar.
4. Use /up como caminho do health check O Rails 7.1 e as versões posteriores respondem a /up com 200 assim que a aplicação arranca; defina-o como caminho do health check nas definições da aplicação. A Nodion chama cada instância com o seu IP interno como Host, por isso, se definir config.hosts, exclua /up da autorização de hosts; caso contrário, a release nunca fica online. config/environments/production.rb

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

5. Ou use buildpacks para aplicações com importmap Uma aplicação com importmap e sem package.json pode, em alternativa, escolher Buildpacks no formulário de criação. Nesse caso, a Nodion executa bundle install sem as gems de development e test e assets:precompile com RAILS_ENV=production e SECRET_KEY_BASE_DUMMY=1, arranca o Puma com config/puma.rb na porta PORT e define RAILS_SERVE_STATIC_FILES e RAILS_LOG_TO_STDOUT. As migrações são executadas a partir de um Procfile: Procfile

   release: bin/rails db:migrate

A ter em conta

• Solid Queue e SidekiqCom buildpacks, adicione worker: bin/jobs (Solid Queue) ou worker: bundle exec sidekiq ao Procfile juntamente com uma linha web: bundle exec puma -C config/puma.rb explícita; sem uma linha web:, a primeira entrada do Procfile que não seja release: passa a ser o comando por omissão. Depois, adicione no separador Processes um processo chamado worker sem porta. Com o Dockerfile, em vez disso, atribua a esse processo o comando ./bin/jobs ou bundle exec sidekiq. O Valkey na mesma região fornece ao Sidekiq a sua REDIS_URL.
• As bases de dados adicionais do Rails 8Uma aplicação Rails 8 gerada para PostgreSQL também declara, em config/database.yml, as bases de dados cache, queue e cable para produção, e DATABASE_URL só define a principal. Antes do primeiro deploy, configure também uma ligação para as outras ou remova as que a sua aplicação não usa.
• Versão do RubyCom o Dockerfile, a versão do Ruby vem de RUBY_VERSION no Dockerfile. Com buildpacks, a Nodion lê .ruby-version ou a linha ruby do Gemfile e oferece 3.3, 3.4 (por omissão) e 4.0.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Alternativas ao Heroku com alojamento na UE: 5 opções Uma plataforma alemã e clouds norte-americanas com regiões na UE, comparadas por sede, regiões e bases de dados geridas.
• Dockerfile vs buildpacks: qual deve escolher? Ambos transformam o seu código numa imagem de contentor. A diferença está em quem escreve os passos do build, e isso determina o controlo, a manutenção e as atualizações de segurança.

Ruby on Rails na Nodion: perguntas e respostas