Faça deploy de Docker Compose na Nodion

Faça deploy de Docker Compose passo a passo

1. Verifique o seu ficheiro Compose A Nodion lê docker-compose.yml, docker-compose.yaml, compose.yml ou compose.yaml, escolhendo o ficheiro mais próximo da raiz do repositório. Precisa de pelo menos um serviço de aplicação além das bases de dados e caches; um ficheiro só com bases de dados e caches é ignorado. docker-compose.yml

   services:
     web:
       build: .
       environment:
         DATABASE_URL: postgres://app:app@db:5432/app
         REDIS_URL: redis://cache:6379
     db:
       image: postgres:17
     cache:
       image: valkey/valkey:8

2. Escolha Docker Compose ao criar a aplicação Crie uma aplicação a partir do seu repositório na região EU Central. Quando a análise encontra um ficheiro Compose utilizável, aparece uma opção Docker Compose; nunca vem pré-selecionada. Escolha-a e reveja o plano: antes de criar a aplicação, ainda pode escolher o tamanho e as instâncias de cada processo e ajustar o tamanho dos volumes.
3. Veja o que passa a serviço gerido A Nodion usa o nome da imagem: postgres e postgis passam a Managed PostgreSQL, pgvector passa a pgvector, redis e valkey passam a Valkey, mysql e mariadb passam a MySQL, clickhouse passa a ClickHouse e minio passa a um bucket. Qualquer outro serviço executa a sua imagem como processo dessa única aplicação. A tag da imagem não determina a versão da base de dados, e os utilizadores e as palavras-passe são definidos pela Nodion. O Managed PostgreSQL não tem a extensão PostGIS, por isso uma aplicação que precise de PostGIS perde as funções espaciais após a importação; deixe essa base de dados fora do ficheiro Compose.
4. Verifique as variáveis de ligação Uma variável do serviço de aplicação que aponta para outro serviço pelo nome, como @db:5432 acima, passa a ser uma associação: a Nodion injeta o endereço real no deploy. Caso contrário, as bases de dados chegam como DATABASE_URL e o Valkey como REDIS_URL. Das restantes variáveis, só são copiadas as do serviço de aplicação principal, e os valores que parecem segredos são marcados como secretos.
5. A partir daí, gira a aplicação no dashboard O primeiro deploy aguarda até as bases de dados estarem prontas. Depois disso, o ficheiro Compose deixa de ser lido: cada push faz o build da aplicação com a estratégia Dockerfile ou buildpacks encontrada no mesmo repositório, e é no dashboard que altera os processos, as variáveis e os tamanhos.

A ter em conta

• Experimental e feita uma só vezA importação é um atalho para a configuração inicial, não um runtime do Compose. Se o seu ficheiro não for convertido corretamente, crie a mesma configuração à mão: uma aplicação, uma base de dados associada no separador Environment e processos adicionais no separador Processes.
• O que a Nodion ignoraRedes, perfis, healthchecks do Compose, depends_on como ordem de arranque, deploy.replicas, bind mounts e volumes anónimos. Um segundo serviço com o seu próprio build: partilha a única imagem da aplicação.
• VolumesOs volumes nomeados passam a volumes Nodion, de 5 GB por omissão e editáveis no plano, montados nos processos que os utilizam.

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