Docker Compose

Importe um ficheiro compose uma vez. A Nodion transforma-o numa aplicação, em processos e em serviços geridos.

Guias de deploy passo a passo: Docker Compose.

Esta opção é experimental. Não é docker compose up. A Nodion não mantém o Compose em execução, não configura redes nem volta a ler o ficheiro em deploys posteriores.

Em Applications → New, ligue um repositório Gite, se a análise encontrar um ficheiro compose com pelo menos um serviço de aplicação, aparece a opção Docker Compose. Nunca está selecionada por omissão. Clique nela para rever o plano e depois crie a aplicação.

Que ficheiro é usado

É usado o ficheiro com um destes nomes que estiver mais perto da raiz:

• docker-compose.yml / docker-compose.yaml
• compose.yml / compose.yaml

Um ficheiro só com bases de dados ou caches (sem serviço de aplicação) é ignorado. Um ficheiro com um erro de análise sintática também é ignorado. Um ficheiro compose numa pasta afastada da raiz, num repositório grande, pode passar despercebido se a análise for truncada.

O que é criado

Uma única aplicação, e não uma aplicação por serviço. Os serviços adicionais tornam-se processos adicionais dessa aplicação. O assistente permite escolher o pacote e o número de réplicas (1-16) antes da criação. deploy.replicas no ficheiro é ignorado.

Tags de imagem como postgres:16 não escolhem a versão do motor gerido. A Nodion usa a versão atualmente definida por omissão para esse motor. Os utilizadores e as palavras-passe da base de dados vêm da Nodion, não das variáveis de ambiente do Compose no serviço de base de dados.

Se um valor de ambiente de um serviço de aplicação apontar para outro serviço como host (postgres://…@db:5432/…, redis://cache:6379), essa chave torna-se uma associação (attach binding) e é injetada no deploy. Caso contrário, as bases de dados do tipo Postgres são associadas como DATABASE_URL, o Valkey como REDIS_URL e o MinIO como as chaves AWS/S3 habituais.

Só o restante ambiente do serviço de aplicação principal é copiado para a aplicação. As chaves que parecem segredos são marcadas como secretas no formulário.

Volumes

Os volumes com nome passam a volumes (5 GB por omissão, editável no assistente) e são montados nos processos correspondentes. Os bind mounts (./data:/data) e os volumes anónimos são ignorados.

Como é feito o build após a importação

A estratégia da aplicação continua a ser Dockerfile ou Buildpacks, com base na mesma análise do repositório. Os campos build.context e build.dockerfile do Compose não são copiados para essas definições. Há um único build Git por aplicação. Um segundo serviço com o seu próprio build: partilha essa imagem.

Um serviço que só tem image: (e não é uma base de dados mapeada) mantém essa imagem e executa-a como processo. O serviço principal com build: passa a chamar-se web.

O primeiro deploy espera até que as bases de dados e os buckets associados estejam prontos. Depois da criação, altere os processos, as variáveis de ambiente e os recursos no dashboard. Editar o ficheiro compose no Git não atualiza o plano.

O que é ignorado

• Redes, perfis e health checks do Compose
• depends_on como ordem de arranque (um contentor auxiliar que só espera é ignorado)
• Bind mounts
• Builds por serviço além da imagem única da aplicação

Se um motor gerido ou o armazenamento de objetos não estiver disponível na região, esse recurso é ignorado e a aplicação é criada ainda assim.