Analise um Dockerfile antes que ele chegue ao review.

Dezessete regras, de DF001 a DF017, cada uma um erro que ainda assim builda: uma imagem base sem tag ou em :latest, um COPY --from que nomeia um estágio que ainda não existe, ADD onde COPY seria o certo, um download remoto sem verificação, um WORKDIR relativo, um apt-get update sozinho na própria camada, um cache de pacotes deixado dentro da imagem, um segredo escrito no histórico da imagem por ENV ou ARG, um estágio final que roda como root, cd em vez de WORKDIR, curl canalizado para um shell, um segundo CMD que vence em silêncio, uma forma exec JSON que não é JSON válido, sudo em um passo de build, MAINTAINER e um COPY . que destrói o cache da instalação de dependências. Cada regra tem a própria subseção nesta página, com um trecho antes e depois.

Não, e não tenta ser. O hadolint é um binário que você instala, e ele combina as próprias regras com tudo o que o ShellCheck reporta sobre o shell dentro das suas linhas RUN — excelente em CI e a resposta certa quando você pode impor uma toolchain. Isto cobre o caso que ele não cobre: um Dockerfile que você quer verificar agora, pelo navegador, em uma máquina onde você não pode instalar nada, sem mandar o arquivo para um servidor. Dezessete regras em vez de uma cauda longa, cada uma com a correção, e mais abaixo uma lista explícita do que ele se recusa a apontar.

Não. O parser e todas as dezessete regras são JavaScript rodando na sua aba — não há servidor, não há chamada de API e não há log, então 0 bytes são enviados. Aqui isso pesa mais do que na maioria das ferramentas: Dockerfiles carregam hostnames de registries internos, índices de pacotes privados, argumentos de build e, de vez em quando, uma credencial que ninguém deveria ter commitado.

Porque cada RUN é uma camada separada com a própria entrada de cache. Quando você depois edita só a linha de instalação, o Docker reaproveita a camada de update em cache — que pode ter semanas ou meses — e roda a instalação contra esse índice de pacotes desatualizado. O resultado é uma versão que você não esperava ou um 404 de um pacote que já foi substituído. Juntar os dois em um único RUN faz o índice e a instalação compartilharem a mesma entrada de cache, então eles nunca podem se contradizer.

Nada, até quem publica dar um push. :latest é um ponteiro móvel, e um FROM sem tag significa :latest, então a imagem base que seu build usou no mês passado e a que ele usa hoje à noite podem ser versões maiores diferentes sem nenhuma mudança do seu lado — e nada no arquivo registra qual você realmente testou. Fixe uma tag que você testou. Se precisar de rebuilds idênticos byte a byte, acrescente também o digest (@sha256:…). Este linter pede uma tag e nunca exige um digest: esse trade-off é seu.

Porque o Docker não rejeita — ele silenciosamente faz outra coisa. A forma exec só é usada quando o argumento é parseado como JSON, e JSON exige aspas duplas. Com aspas simples tudo cai de volta para a forma shell, então o Docker executa /bin/sh -c "['nginx']" e os colchetes e as aspas passam a fazer parte do comando. Nada avisa em tempo de build; o contêiner simplesmente não sobe, ou sobe um shell que não é o processo que você queria como PID 1.

Não diretamente, e ele diz isso em vez de adivinhar. Um .dockerignore é um arquivo separado, então um linter que só lê o Dockerfile não pode saber se node_modules, .git e os artefatos de build estão entrando no contexto de build. O que ele consegue é identificar o padrão que faz um .dockerignore ausente custar caro — um COPY . antes da instalação de dependências, que é o DF017 — e colocar o conselho sobre .dockerignore no texto de correção dessa regra.

Os dois foram considerados e deliberadamente descartados. EXPOSE é documentação: por si só não publica nada, então a ausência não quebra nada e um a mais não custa nada. HEALTHCHECK é ignorado por completo pelo Kubernetes, que é onde essas imagens de fato rodam, então apontá-lo treinaria este público a ignorar o linter. A lista completa do que fica em silêncio, com o motivo de cada item, está no painel “O que ele deliberadamente não aponta” acima do FAQ.

Até 200.000 caracteres — cerca de quatro mil linhas de texto denso, duas ordens de magnitude além de qualquer Dockerfile real. Acima disso ele recusa com uma mensagem em vez de congelar sua aba, porque uma entrada desse tamanho é um log de build ou um arquivo empacotado, não um Dockerfile. Os achados também têm limite, 20 por regra e 200 no total, e o painel informa o limite e o número real sempre que um deles se aplica.