Faça deploy de Ruby na Nodion

Faça deploy de Ruby passo a passo

1. Faça commit do Gemfile e do Gemfile.lock O build executa bundle install sem os grupos development e test, com a versão do Bundler indicada em BUNDLED WITH no Gemfile.lock. Com o Rack 3, uma aplicação com config.ru também precisa da gem rackup e de um servidor como o Puma. Gemfile

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

2. Adicione um config.ru Com um config.ru e sem config/puma.rb, a Nodion arranca bundle exec rackup config.ru -p $PORT e define RACK_ENV=production. Uma pequena aplicação Sinatra cabe no próprio ficheiro: config.ru

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

3. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea, escolha o branch e a região EU Central e mantenha a estratégia de build em Buildpacks. Durante o build só existem as variáveis com a opção Build; todas as outras são definidas em tempo de execução. Marque as chaves de API e as palavras-passe como secretas.
4. Associe uma base de dados e execute as migrações Crie uma base de dados PostgreSQL ou MySQL na mesma região e associe-a no separador Environment; a aplicação recebe DATABASE_URL no deploy seguinte. Uma linha release: num Procfile é executada uma vez por build antes de a nova versão arrancar, por exemplo para as migrações do sinatra-activerecord. Se falhar, a versão em execução continua online. Procfile

   release: bundle exec rake db:migrate

A ter em conta

• Defina uma versão fixa do RubyA Nodion lê .ruby-version e depois uma linha ruby com a versão completa no Gemfile; sem nenhum dos dois, obtém Ruby 3.4. Também estão disponíveis Ruby 3.3 e 4.0. Sem BUNDLED WITH, o Ruby 3 usa o Bundler 2 e o Ruby 4 usa o Bundler 4.
• Configuração do Puma ou um simples app.rbSe existir config/puma.rb, a Nodion executa bundle exec puma -C config/puma.rb, por isso configure aí a porta do Puma com port ENV.fetch("PORT", 3000). Sem esse ficheiro nem config.ru, a Nodion executa bundle exec ruby app.rb e o script tem de escutar em 0.0.0.0 e na porta PORT definida pela Nodion.
• Sidekiq e outros workersAdicione worker: bundle exec sidekiq ao Procfile juntamente com uma linha web: bundle exec rackup config.ru -p $PORT 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. O Valkey na mesma região fornece ao Sidekiq a sua REDIS_URL.

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 na Nodion: perguntas e respostas