Migrar do Heroku

Mova uma aplicação do Heroku com a base de dados, as config vars e o domínio.

Este guia migra uma aplicação do Heroku para a Nodion: código, config vars, Heroku Postgres, Heroku Key-Value Store, jobs do Scheduler e o domínio personalizado. Planeie uma breve pausa nas escritas enquanto a base de dados é copiada. Não existe importador para app.json nem heroku.yml; cada passo abaixo exige apenas alguns cliques ou comandos.

Correspondências entre Heroku e Nodion

1. Crie o projeto e a base de dados

Crie um projeto e, dentro dele, uma base de dados PostgreSQL na região onde a aplicação deve correr (EU Central para Frankfurt). A aplicação e a base de dados têm de estar na mesma região; a Nodion recusa associações entre regiões diferentes. Escolha uma versão do Postgres pelo menos tão recente como a da sua base de dados no Heroku. Mais informações em Bases de dados.

2. Copie a base de dados

Comece por parar todas as escritas. No maintenance mode do Heroku, os dynos de worker e os jobs do Scheduler continuam em execução. Por isso, escale para zero todos os tipos de processo que escrevem (não apenas worker) e remova os jobs do Heroku Scheduler durante a cópia. Segundo o Heroku, o maintenance mode não está disponível para aplicações Fir; nesse caso, escale também web para zero ou pare as escritas na própria aplicação:

bashheroku maintenance:on --app example-app
heroku ps:scale worker=0 --app example-app   # every process type that writes

No Fir:

bashheroku ps:scale web=0 worker=0 --app example-app   # Fir: no maintenance mode

Depois, crie e descarregue um backup. O Heroku grava-o como latest.dump no formato custom do pg_dump (documentação do Heroku). O Heroku recomenda PGBackups para bases de dados até 20 GB; para as maiores, execute pg_dump diretamente com o URL de heroku pg:credentials:url (bases de dados classic) ou heroku data:pg:credentials:url (bases de dados Advanced, documentação do Heroku).

bashheroku pg:backups:capture --app example-app
heroku pg:backups:download --app example-app

As bases de dados Advanced não suportam PGBackups; para essas, e para bases de dados com mais de 20 GB, faça o dump diretamente no mesmo formato custom, com o URL do comando de credenciais correspondente. Segundo o Heroku, as bases de dados Private e Shield não aceitam ligações externas (e o Shield não tem PGBackups); para essas, siga o caminho que o Heroku descreve para Private Spaces.

bashpg_dump -Fc --no-acl --no-owner -f latest.dump \
  "postgres://USER:PASSWORD@HOST:5432/DATABASE?sslmode=require"

Na Nodion, abra o separador Overview da base de dados e clique em Enable public access. Aguarde até que o endpoint deixe de mostrar Provisioning e, depois, copie o URL de ligação que o dashboard mostra (sempre TLS, sslmode=require). Adicione o seu próprio IP às origens permitidas (allowed sources), para que mais ninguém se possa ligar. Em seguida, faça o restauro:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  latest.dump

Use um pg_restore pelo menos tão recente como o mais recente dos dois servidores. Se o restauro indicar erros relativos ao esquema heroku_ext, crie-o primeiro: CREATE SCHEMA heroku_ext; (conselho do próprio Heroku). Verifique o número de linhas no separador Browse da base de dados e, depois, desative novamente o acesso público; a base de dados continua a funcionar internamente.

Um Valkey vazio só é suficiente se a aplicação usar o Key-Value Store como cache, ou como fila que deixa esvaziar primeiro. Se contiver dados de que precisa (sessões ou chaves persistentes, por exemplo), migre esses dados antes de desligar, ou mantenha a origem até deixar de ser necessária.

3. Crie a aplicação

Crie uma aplicação a partir do seu repositório Git com a estratégia Buildpacks. Os buildpacks leem o seu Procfile: web é o processo por omissão e as outras linhas tornam-se tipos de processo (Buildpacks). Para Node.js, um script heroku-postbuild é executado após o build. Tal como no Heroku, o processo web recebe a variável PORT.

Se o Procfile não tiver nenhuma linha web:, a primeira linha passa a ser usada por omissão e corre no processo web da Nodion. A Nodion verifica esse processo por HTTP antes de o colocar online, por isso um worker sem servidor HTTP não passa nessa verificação. Mantenha uma linha web: para o servidor HTTP da sua aplicação.

As linhas do Procfile não criam processos. Para uma linha worker:, abra Processes, New process, dê-lhe o nome worker e deixe o comando vazio; o processo executa então o tipo de processo com o mesmo nome.

Uma linha release: é executada uma vez por deploy, antes de web arrancar. Se falhar, o deploy falha e a release anterior continua a servir o tráfego. Se fazia o build com heroku.yml no Heroku, use a estratégia Dockerfile: aí não há Procfile, por isso defina o release command da aplicação (Settings, no cartão Preview environments, onde o campo aparece depois de ativar as previews, ou release_command através da API). A Nodion não define PORT em aplicações Dockerfile; a aplicação escuta na porta do processo web (senão, na do EXPOSE da imagem; senão, na 8080).

4. Mova as config vars

Exporte as config vars em formato shell (Heroku CLI):

bashheroku config -s --app example-app > heroku.env

Cole as linhas em Environment, Add many, e importe-as. Verifique o resultado: valores com aspas ou barras invertidas podem ter de ser corrigidos à mão, e valores com várias linhas (chaves PEM, por exemplo) introduzem-se através da CLI ou da API. As variáveis importadas não são secretas; defina os segredos com nodion env set KEY=value --secret.

Depois, elimine DATABASE_URL e REDIS_URL das variáveis importadas: uma variável definida manualmente sobrepõe-se ao valor que uma base de dados associada injeta. Use Attach database para a base de dados Postgres (url como DATABASE_URL) e para o Valkey (url como REDIS_URL).

Dentro da Nodion, a ligação passa pela rede privada sem TLS (sslmode=disable). Se o seu código forçar SSL para a base de dados, como o Heroku exige, desative-o para este URL; o mesmo se aplica a rediss:// para o Valkey.

5. Os jobs do Scheduler passam a cron jobs

Adicione cada job do Heroku Scheduler no separador Cron da aplicação: um agendamento cron de cinco campos em UTC, o mesmo comando, um timeout de até 30 minutos. Uma aplicação aceita até 8 cron jobs; enquanto uma execução ainda estiver a decorrer, o tick seguinte é ignorado.

6. Faça deploy e verifique

Faça deploy, acompanhe o separador Logs e abra a aplicação no respetivo hostname da Nodion. Se / não responder rapidamente com um 2xx ou 3xx, defina o seu próprio caminho de health check em Settings.

7. Mova o domínio

Adicione o domínio no separador Domains. A Nodion mostra dois registos: um registo TXT _nodion-challenge.your-domain e um CNAME (um ALIAS no apex) para o hostname por omissão da aplicação. Pode adicionar o registo TXT com antecedência. O certificado é emitido assim que o CNAME apontar para a Nodion; conte, por isso, com alguns minutos sem certificado válido após a mudança e reduza o TTL antecipadamente.

8. Desligue o Heroku

Quando o tráfego e os dados já estiverem na Nodion, elimine a aplicação no Heroku. Segundo o Heroku, esta operação não pode ser anulada, por isso guarde o latest.dump.

bashheroku apps:destroy --app example-app

O que funciona de forma diferente

• Não há maintenance mode nem pipelines com promoção entre aplicações.
• Em vez de one-off dynos, o separador Shell abre um terminal num processo em execução.
• A CLI obtém os logs, mas não os consegue acompanhar em tempo real; veja-os ao vivo no separador Logs.
• Os ambientes de pré-visualização não precisam de app.json; cada um recebe uma base de dados vazia.
• Um rollback faz novamente deploy de uma imagem anterior com as variáveis de ambiente atuais.

Próximos passos

Nodion comparada com o Heroku, Preços, Aplicações e Bases de dados.