01
Explorar a lista de estágios
O exemplo separa build e execução. A numeração começa em zero. Clique no estágio para ir ao FROM e expanda uma instrução para ler o texto original com sua explicação.
Docker / Contêineres
Formatador de Dockerfile
Encontre o trecho indicado pelo diagnóstico e confira os recuos antes de alterar o código original.
Formatador de Dockerfile
Código Dockerfile
Resultado
Processamento na memória deste navegador, sem requisições de build ou ao registro.
Resultado desatualizado. Verifique novamente antes de exportar.
O Formatador de Dockerfile facilita a revisão quando as instruções de build se misturam às do estágio de execução. A entrada permanece disponível enquanto você navega pelo arquivo.
Você pode formatar Dockerfile online e examinar um build multi-stage sem executar comandos. Este linter de Dockerfile oferece verificações estáticas, mas a análise completa de boas práticas Dockerfile exige as ferramentas e políticas do projeto.
Por que usar este Formatador de Dockerfile
Localizar cada estágio
O Formatador de Dockerfile mostra cada FROM na ordem original, com a imagem, o nome opcional e a posição. Mesmo sem nome, um estágio pode ser selecionado para voltar à declaração no editor.
Conferir antes de substituir
A prévia aparece separada da entrada. Compare os recuos e a quantidade de linhas alteradas. A aplicação só acontece quando você confirma; desfazer recupera também o resultado e os diagnósticos anteriores.
Controlar o momento e o alcance da mudança
02
Alternar a verificação automática
O processamento aguarda 350 ms após a edição. Desligar o modo automático cancela tarefas pendentes. No modo manual, use o botão ou Ctrl/Cmd + Enter. Qualquer mudança bloqueia a exportação do resultado antigo.
03
Comparar os recuos
O padrão é de quatro espaços nas linhas continuadas. Dois espaços ou tabulação também estão disponíveis. A prévia informa o número de linhas afetadas e perde a validade se a entrada mudar.
Informações ligadas ao código
Diagnósticos com linha e coluna
Erros e avisos são contados separadamente. Os links levam à posição da origem. A categoria está em português, enquanto o detalhe expansível preserva a mensagem original do motor em inglês.
Referência das instruções usadas
Veja por que ARG e ENV têm papéis diferentes e por que EXPOSE não publica uma porta. A lista corresponde ao arquivo atual. Comandos de shell aparecem como texto e não são interpretados ou executados.
Preservação de comentários e heredocs
A formatação mantém ordem e capitalização. Heredoc sem fechamento é um erro. Um argumento com aparência de JSON que não seja um array de strings recebe um aviso para conferir a intenção de usar a forma shell.
O que esta análise não conclui
- Sem build ou auditoria de segurança
- O utilitário não executa RUN, lê o contexto nem baixa imagens. Assim, não confirma existência de arquivos, disponibilidade da imagem, vulnerabilidades ou conformidade com políticas de segurança.
- Cobertura limitada de regras
- Não equivale a Hadolint, ShellCheck ou a todas as verificações do BuildKit. Frontends personalizados podem ultrapassar a cobertura do parser. Comentários ignore são respeitados, mas geram um aviso sobre a supressão de diagnósticos.
- Sem reescrever a lógica
- Só são ajustados recuos de instruções, linhas compostas por espaços e recuos de continuação. Não há fusão de RUN nem ordenação de pacotes. COPY --from pode apontar para uma imagem externa; isso não é um erro por si só.
- Uma entrada com limites definidos
- O limite é de 131072 unidades UTF-16 e 2000 linhas físicas. Acima disso, o processamento para sem cortar o texto. Listas exibem 50 itens por vez; a exportação contém todo o resultado atual com quebras LF.
Formatador de Dockerfile: dúvidas frequentes
Que alterações a formatação faz no arquivo?
O motor ajusta espaços antes de instruções, linhas que contêm apenas espaços e recuos de continuação. Comentários, ordem e capitalização permanecem. Compare a prévia antes de aplicar, principalmente em comandos continuados.
Como verificar as boas práticas do Dockerfile?
Esta página verifica um conjunto limitado de problemas estáticos. Para recomendações adicionais, use os controles de Hadolint ou BuildKit adotados no projeto. Um resultado sem erros aqui não dispensa essas verificações.
Por que usar uma tag específica na imagem base?
Uma tag mutável pode passar a apontar para outros conteúdos. Versões específicas ou digests ajudam na reprodutibilidade, mas não garantem segurança. Esta ferramenta não consulta o registro nem troca a referência automaticamente.
É possível baixar o arquivo depois de formatar?
Sim. Quando o resultado está atualizado e sem erros, o download salva o texto completo com o nome Dockerfile. Alterações na entrada ou no recuo bloqueiam a exportação até a próxima verificação.
O Dockerfile colado é enviado a algum servidor?
O texto é processado no navegador sem envio para um serviço de formatação ou registro de imagens. Não há histórico local após recarregar a página. Baixe o resultado para mantê-lo sob seu controle.
Ficou com alguma dúvida?
Revisar a próxima alteração
Volte ao Formatador de Dockerfile, confira uma linha ou a divisão entre estágios e exporte a prévia atual quando estiver de acordo.
Valide o build real no seu ambiente depois da revisão estática.