Migrar a partir do Render

Migre os serviços do Render com o respetivo Postgres, variáveis de ambiente e domínios.

No Render, cada parte de uma aplicação é um serviço próprio: web service, background worker, private service, cron job. Na Nodion, constrói uma única imagem e executa a partir dela vários processos numa só aplicação; os cron jobs pertencem à aplicação. A Nodion não lê o render.yaml, por isso as definições têm de ser transferidas manualmente.

Correspondências entre Render 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 vai correr. A aplicação e a respetiva base de dados têm de estar na mesma região. Escolha uma versão do Postgres pelo menos tão recente como a do Render. Mais informações em Bases de dados.

2. Copie a base de dados

O URL externo da base de dados está na página Info da base de dados no Render; o Render só aceita ligações externas com TLS (documentação do Render). Pare as escritas dos seus serviços e crie o dump como indica a documentação de backups do Render. -n public inclui apenas o esquema public; omita-o se a sua aplicação usar outros esquemas.

bashpg_dump --dbname="RENDER_EXTERNAL_DATABASE_URL" -n public --no-owner \
  --format=directory --jobs=4 --compress=0 -f render.dump/

Na Nodion, abra o separador Overview da base de dados e clique em Enable public access. Quando o endpoint deixar de mostrar Provisioning, copie o URL de ligação (sempre com TLS) e adicione o seu próprio IP em Allowed sources. Depois, restaure os dados:

bashpg_restore --verbose --no-owner --no-privileges --jobs=4 --format=directory \
  --dbname="postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  render.dump/

Use um pg_restore pelo menos tão recente como o mais recente dos dois servidores. Verifique o número de linhas no separador Browse e depois desative novamente o acesso público; a base de dados continua a funcionar internamente.

3. Crie a aplicação e os respetivos processos

Crie uma aplicação a partir do repositório Git do web service. Se o Render fazia o build com um build command e um start command, use a estratégia Buildpacks (Buildpacks); um Procfile define os comandos, caso contrário aplicam-se os valores por omissão da linguagem. Se o serviço corria em Docker, use a estratégia Dockerfile.

O Render define PORT como 10000 por omissão. A Nodion define PORT para o processo web das aplicações com buildpacks (8080 por omissão); se a sua aplicação lê PORT, nada muda. Se 10000 estiver fixo no código, substitua-o. Nas aplicações com Dockerfile, a Nodion não define PORT; a aplicação escuta na porta do processo web.

Adicione cada background worker do mesmo repositório em Processes, New process como processo adicional e introduza o respetivo comando de arranque. Um private service também passa a ser um processo, com uma porta. Atenção: cada processo com porta recebe, além do endereço interno, um hostname público por omissão; não existe serviço apenas privado. Proteja essa porta na aplicação (com autenticação, por exemplo). Os hostnames da Nodion só podem ser desativados para a aplicação inteira, depois de um domínio personalizado estar ativo. Um worker que apenas consome uma fila não precisa de porta. Passe um pre-deploy command para uma linha release: no Procfile (buildpacks) ou para 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). É executado uma vez por deploy, antes de web; se falhar, a release anterior continua online.

4. Transfira as variáveis de ambiente

O Render não documenta nenhuma exportação de variáveis de ambiente a partir do dashboard; a API do Render devolve as variáveis de um serviço, mas não as dos environment groups (referência da API do Render, GET /services/{serviceId}/env-vars; sobre os environment groups, consulte a documentação do Render). Reúna-as como linhas KEY=value, incluindo os valores dos environment groups, e cole-as em Environment, Add many. Defina os segredos com nodion env set KEY=value --secret e os valores com várias linhas através da CLI ou da API. A Nodion não tem secret files: guarde o conteúdo numa variável secreta (--secret) e faça com que a aplicação o leia da variável ou escreva ela própria o ficheiro no arranque. Os segredos não devem ficar na imagem, como o Render também avisa.

Em seguida, elimine das variáveis copiadas do Render DATABASE_URL e REDIS_URL: uma variável definida manualmente substitui o valor de uma base de dados associada. Associe as bases de dados com Attach database. Dentro da Nodion, a ligação é feita sem TLS (sslmode=disable); se o seu código forçar SSL, desative-o para este URL, e faça o mesmo para rediss:// para o Valkey.

5. Transfira os cron jobs

No Render, um cron job é um serviço próprio com um agendamento em UTC (documentação do Render). Na Nodion, adiciona-o no separador Cron da aplicação cujo código ele usa: um agendamento de cinco campos em UTC, o comando, um timeout de até 30 minutos e até 8 jobs por aplicação. Enquanto uma execução ainda estiver a decorrer, a seguinte é ignorada.

6. Faça deploy, transfira o domínio e desligue o Render

Faça deploy e verifique o separador Logs. Depois, adicione o domínio no separador Domains e crie os dois registos que a Nodion mostra: TXT _nodion-challenge.your-domain e um CNAME (um ALIAS no apex) para o hostname por omissão da aplicação. A Nodion não oferece um destino para um registo A, por isso, no apex, o seu fornecedor de DNS tem de suportar ALIAS, ANAME ou CNAME flattening. O certificado é emitido assim que o CNAME apontar para a Nodion; conte com alguns minutos sem certificado válido e baixe o TTL com antecedência.

Quando tudo estiver a funcionar, elimine os serviços no Render (Render CLI). O Render não guarda backups de uma base de dados eliminada, por isso guarde o seu dump.

bashrender services delete my-service --confirm

Eliminar o serviço não elimina a base de dados nem uma instância Key Value. Nas instâncias pagas, o Render persiste por omissão os dados Key Value em disco (documentação do Render): um Valkey vazio só chega para caches ou filas que deixe esvaziar primeiro; se precisar das chaves, migre-as antes de eliminar a instância. Depois, elimine manualmente a base de dados Render Postgres, com Delete Database no fundo da respetiva página Info (documentação do Render), bem como qualquer instância Key Value; os comandos da CLI para ambas estão na referência da Render CLI.

O que funciona de forma diferente

• Não há environment groups nem secret files; cada variável pertence a uma única aplicação.
• Os workers e os private services tornam-se processos de uma aplicação, não serviços próprios.
• Os cron jobs correm numa aplicação existente, com a respetiva release ativa.
• A CLI obtém os logs, mas não os consegue acompanhar em tempo real; para os ver em direto, use o separador Logs.

Próximos passos

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