Analisador de boas práticas Dockerfile com linhas

Ele aponta a ausência de WORKDIR, imagens base com a tag mutável latest e instruções RUN consecutivas que podem criar camadas desnecessárias. Cada ocorrência traz a linha de origem, um tipo estável e uma explicação direta, servindo tanto para sua revisão manual quanto para uma etapa automatizada de integração contínua.

Obtenha um relatório curto e acionável do Dockerfile

Cole todo o conteúdo do Dockerfile no campo de texto e execute a verificação. A resposta informa se o arquivo passou, apresenta o total de ocorrências e lista cada problema com numeração de linha iniciada em um, tipo estável para automação e mensagem objetiva. O analisador se concentra em três riscos frequentes de manutenção e não tenta substituir uma suíte completa de segurança de contêineres. A falta de WORKDIR aparece na linha 1 porque se aplica ao arquivo inteiro. Uma instrução FROM é marcada em sua própria linha quando usa latest explicitamente ou omite a tag e, portanto, resolve para latest. Quando dois RUN são consecutivos, o segundo é apontado com referência à linha anterior. Comentários e linhas vazias não escondem essa relação. Um arquivo limpo devolve findings vazio, facilitando o uso de valid como condição de aprovação. Continuações com barra invertida formam uma única instrução lógica, mas a posição informada continua sendo a primeira linha física, igual à exibida no editor.

Entenda a importância dessas três práticas

WORKDIR torna explícito o contexto do sistema de arquivos usado por RUN, COPY, CMD e ENTRYPOINT posteriores. Sem essa instrução, o build herda silenciosamente um diretório definido pela imagem base, que pode mudar em uma atualização. Fixar a imagem de FROM com uma tag versionada ou um digest imutável melhora a reprodução dos builds. Uma referência sem tag e uma referência latest podem mudar de conteúdo mesmo que o Dockerfile permaneça idêntico. Além disso, cada RUN normalmente cria uma camada do sistema de arquivos. Etapas consecutivas de instalação, limpeza ou configuração muitas vezes pertencem à mesma operação de shell, permitindo remover arquivos temporários na própria camada e manter o histórico mais claro. A ocorrência é uma recomendação, pois RUN separados podem ser intencionais quando os limites de cache beneficiam um fluxo consolidado. A ferramenta não reescreve comandos nem presume que toda combinação seja segura. A decisão cabe a quem conhece o build, sua estratégia de cache e o comportamento dos comandos quando ocorre uma falha.

Faça a verificação antes do build mais caro

Use o analisador em uma ação do editor, antes do commit ou no começo da integração contínua, antes de baixar imagens base e compilar a aplicação. Envie o texto-fonte original, e não uma representação processada, para preservar as linhas físicas e as continuações. O algoritmo é determinístico: entradas iguais geram saídas iguais, sem rede, relógio, aleatoriedade, daemon do Docker ou estado dependente do ambiente. Assim, ele também é adequado para Dockerfiles gerados. Trate o relatório como um sinal básico de manutenção, não como prova de segurança ou de que a imagem pode ser construída. A ferramenta não executa shell, não resolve variáveis em nomes de imagem, não inspeciona pacotes, não valida origens de COPY, não exige USER sem privilégios e não procura vulnerabilidades. Combine esta análise rápida com um build real, varredura da imagem, políticas e testes do processo final. Se a entrada tiver apenas espaços ou comentários, a solicitação falha porque não existem instruções Dockerfile para avaliar.