Faça deploy de Docker na Nodion

Faça deploy de Docker passo a passo

1. Ponha o servidor a escutar em 0.0.0.0 e indique a porta com EXPOSE A Nodion faz o build do seu Dockerfile tal como está e inicia o CMD ou o ENTRYPOINT da imagem. Não define PORT: o seu servidor escuta em todas as interfaces numa porta fixa, e o EXPOSE indica ao formulário de criação que porta usar. Os builds multi-stage funcionam; é executado o último stage. Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea e escolha o branch e a região EU Central. Se o repositório tiver um Dockerfile, o formulário pré-seleciona a estratégia Dockerfile e preenche a porta a partir do EXPOSE. Num monorepo, defina o Base directory (o contexto de build) e o nome do Dockerfile.
3. Forneça os valores de build como build args As variáveis com a opção Build no separador Environment chegam ao build como build args do Docker, por isso declare-as com ARG no stage que as lê. Todas as outras variáveis, e as bases de dados associadas como DATABASE_URL, só existem quando o contentor está em execução. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Execute as migrações uma vez por deploy Defina o comando de migração como comando de release da aplicação: é executado uma vez por deploy a partir da nova imagem, antes de a nova versão arrancar. Se falhar, o deploy é interrompido e a versão em execução continua online. Defina-o com o campo release_command da API; no dashboard, por agora o campo só aparece nas definições da aplicação depois de ativar os ambientes de pré-visualização (preview). Executar as migrações no entrypoint ou no comando de arranque também funciona, mas nesse caso cada instância executa-as em cada arranque.
5. Faça push para fazer deploy Cada push para o branch faz o build de uma nova imagem em Frankfurt. O tráfego passa para ela assim que o processo web responde com 2xx ou 3xx no caminho do health check (por omissão /). Um HEALTHCHECK do Docker na imagem é ignorado.

A ter em conta

• Sem variável PORTSe o seu servidor lê PORT, defina essa variável manualmente, com ENV PORT=8000 no Dockerfile ou como variável no separador Environment, e mantenha-a igual à porta do processo web.
• Imagens pré-construídasDispense o build a partir do Git e faça deploy de uma imagem do Docker Hub, do GitHub Container Registry, do registry da Nodion ou de um registry privado cujas credenciais guardou na Nodion. Aplicam-se as mesmas regras de porta e health check.
• USER, .dockerignore e o commitO USER da imagem é respeitado, um .dockerignore no contexto de build é aplicado e o .git nunca é enviado para o build. Declare ARG NODION_GIT_SHA para escrever o hash do commit na imagem.

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

• 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.
• Alternativas ao Railway na Europa: 5 opções comparadas Contentores e bases de dados faturados por utilização, com uma empresa ou região na UE: cinco alternativas ao Railway comparadas por faturação, bases de dados e localização.

Docker na Nodion: perguntas e respostas