Anúncios incomodam? Ir Sem anúncios Hoje 

Formatador de YAML do Docker Compose

DadosDesenvolvedor

ANUNCIADO Remover?

ENTRADA

Processo Automático

SAÍDA

Lado cliente

ANUNCIADO Remover?

Guia

Formatador de YAML do Docker Compose

Cole um docker-compose.yml e obtenha instantaneamente um arquivo limpo e consistentemente formatado com serviços, redes e volumes ordenados da forma esperada pelas convenções do Docker Compose. O formatação valida o arquivo contra a Especificação moderna do Compose, marca chaves descontinuadas como a antiga chave de topo version campo ou legado links, e avisa sobre opções de serviço desconhecidas antes que causem falhas em tempo de execução.

Como usar

Cole o seu docker-compose.yml no área de entrada, ou clique em um dos links de exemplo para carregar uma pilha de amostra.
Escolha a ordem de chave — Convenção Compose ordena os serviços na ordem que os usuários do Compose esperam (imagem, reiniciar, ambiente, portas, volumes, …), Alfabético ordena estritamente de A a Z, ou Preservar mantém a sua ordem original.
Escolha indentação de 2 ou 4 espaços e ative/desative a validação contra a Especificação Compose.
Leia a seção de validação para erros, avisos sobre chaves descontinuadas e notificações informativas sobre referências implícitas a redes.
Copie o resultado ou baixe como docker-compose.yml.

Características

Validação da Especificação Compose – Reconhece a chave de topo services, networks, volumes, configs, secrets, profiles, include, e campos de extensão (x-*); marca qualquer coisa diferente.
Avisos de descontinuação – Destaca a chave de topo legada version , links, external_links, e os limites de recursos da era v2 que devem ser movidos para deploy.resources.
Ordem de chave consciente ao serviço – Reorganiza cada serviço para que as chaves identificativas (image, build, container_name) venham primeiro, a configuração de execução (environment, ports, volumes) fique no meio e as preocupações operacionais (healthcheck, logging, deploy) terminem no final.
Verificação de referências – Detecta serviços que dependem de serviços não definidos e avisa quando um serviço usa uma rede que não está declarada no nível superior.
Requisitos de serviço – Verifica que cada serviço tenha pelo menos um dos image, build, extends, ou provider, e que restart use uma das quatro políticas válidas.
Sanidade de porta + healthcheck – Detecta strings malformadas de portas, falta de target em portas no formato longo, e healthchecks sem um test.
Três exemplos funcionais – Uma aplicação web com Node + Postgres, uma pilha WordPress + MySQL + Redis e uma construção de múltiplos serviços com perfis e limites de recursos.
Local + privado – Todas as operações de análise, ordenação e validação ocorrem no seu navegador. Seu arquivo Compose nunca sai da página.

 Perguntas frequentes

Por que a chave de versão no nível superior é descontinuada?

A chave de versão era usada nas versões antigas do Compose (v1, v2 e v3) para selecionar um esquema para o CLI do Docker Compose. A Especificação atual do Compose combinou esses esquemas em um único esquema continuamente evoluído, então a declaração de versão não altera mais nada — as versões recentes do Docker Compose simplesmente ignoram essa chave e exibem uma mensagem de aviso. Remover essa chave reduz o tamanho do arquivo e evita confusão quando os leitores assumem que recursos da versão v3 estão bloqueados pela declaração.
O que é a Especificação do Compose e como difere das versões antigas dos arquivos do Compose?

A Especificação do Compose é o esquema aberto e neutro de fabricante que substitui os esquemas por versão usados pelo Docker Compose até 2020. É mantida no github.com/compose-spec/compose-spec e implementada pelo Docker Compose, Podman Compose e outros executadores. Em comparação com as versões v2 e v3, a especificação elimina o campo de versão, torna os serviços a chave obrigatória no nível superior e absorve campos exclusivos do Swarm, como deploy, como metadados opcionais que podem ser consumidos por orquestradores.
Por que preferir uma rede compartilhada ao campo links?

links foi herdado da era pré-redes do Docker e apenas estabelece alias DNS entre contêineres na rede padrão. As redes definidas pelo usuário modernas já fornecem resolução DNS automática por nome de serviço para cada serviço, suportam múltiplas redes isoladas por pilha e permitem que você controle os alias DNS com a opção aliases. Por isso, a Especificação do Compose marca links como obsoletos e recomenda o uso explícito de membro de rede em vez disso.
O que cada política de reinício realmente faz?

no nunca reinicia o contêiner. always o reinicia sempre que ele para, incluindo após uma reinicialização do daemon. on-failure reinicia apenas quando o contêiner sai com um status não nulo, opcionalmente limitado por um número máximo de tentativas. unless-stopped comporta-se como always, exceto quando um contêiner foi parado manualmente antes de uma reinicialização do daemon, permanecendo parado. Os quatro valores são strings sensíveis a maiúsculas e minúsculas — qualquer coisa diferente é rejeitada pelo motor do Compose.
Como o Compose decide se deve baixar ou construir uma imagem?

O Compose analisa pull_policy, build e image juntos. Com pull_policy: always, o Compose baixa antes de cada up. Com ausência ou if_not_present (o padrão quando apenas image é definido), ele baixa apenas se a imagem não estiver localmente. Com never, ele nunca baixa. Quando build está presente junto com image, pull_policy: build força uma reconstrução e marca o resultado como image, enquanto pull_policy: missing reconstrói apenas quando a imagem ainda não estiver presente localmente.