Dockerfile 将 Docker 镜像的内容定义为文本文件中的一组指令。Dockerfile 语法通常很简单，但有一些问题需要避免。在团队环境中编写复杂的 Dockerfile 时遵循最佳实践可能会很棘手，除非您自动验证文件的内容。

Hadolint是一个 Dockerfile linter，可以为您发现常见问题。它使用抽象语法树 (AST) 来根据预定义的规则集解析 Dockerfile。Hadolint 还包含ShellCheck，因此它也可以在 Dockerfile 的RUN指令中检查 shell 脚本。

入门

Hadolint 以多种格式分发。您可以通过从项目的GitHub 发布页面下载适用于您的操作系统的最新预编译二进制文件来快速开始。如果您不想直接使用二进制文件，

Hadolint 也有自己的 Docker 映像。hadolint/hadolint作为最后的选择，您可以通过网络访问 Hadolint进行实验。

整理 Dockerfile

将 Hadolint 路径传递给 Dockerfile 以开始新的扫描：

hadolint Dockerfile

如果您使用的是 Dockerized 版本，最简单的方法是将文件内容通过管道传输到 Hadolint 容器中：

docker run --rm -i hadolint/hadolint < Dockerfile

扫描结果将显示在您的终端中。在这个例子中，Hadolint 暗示 Dockerfile 的RUN apt-get install声明是不安全的，因为它没有指定明确的包版本。您的图像内容可能会在构建之间发生变化，从而可能会产生令人困惑的问题。

哈多林特在寻找什么？

Hadolint 有几十个内置规则来检查常见的配置和安全问题。linter 旨在使您的 Dockerfile 符合Docker 建议的映像构建最佳实践。

包含的检查包括使用非 root 最终用户、在WORKDIR语句中引用相对路径、添加多个HEALTHCHECK指令以及不使用明确固定的标签和版本。由于 Hadolint 还继承了 ShellCheck 规则集，因此它也会显示该工具识别的常见 Bash 脚本问题。

规则被标识为前缀为HL或的数字SC。HL规则是 Hadolint 的一部分，而SC条目来自 ShellCheck。每个检查都有一个从错误到信息的严重性。如果您在扫描结果中出现错误，这些应该是您首先解决的问题。

自定义配置

Hadolint 是通过.hadolint.yaml文件配置的。它将搜索多个位置，包括您的工作.config目录、 和主目录。只使用第一个找到的文件——位置之间没有合并。

配置文件允许您通过忽略规则并更改其严重性来自定义扫描。虽然默认规则集涵盖了推荐的最佳实践，但您可能会发现某些检查不适用于您的环境。在 Dockerfile 旁边提交一个.hadolint.yaml文件可以让您相应地定制 Hadolint 扫描。大多数配置文件字段也支持作为 CLI 标志和环境变量。
规则被ignored字段禁用。这应该是规则 ID 列表：

ignored:
  - DL3010
  - DL3020

如果您需要降低规则的严重性而不完全禁用它，请改用override密钥。这还可以让您将低严重性问题提升到更高级别。如果您想更加强调特定问题，请使用此选项。

override:
  warning:
    - DL3020

这会将规则 DL3020 从其默认的“错误”级别降级为不太严重的“警告”。此规则要求您在构建上下文中引用文件和文件夹时使用COPY，而不是。ADD

您也可以调整全局严重性级别。如果任何测试报告给定严重级别的错误，设置该failure-threshold字段会指示 Hadolint 以失败状态退出：

failure-threshold: warning

该指令意味着如果在其输出中有错误或警告，Hadolint 扫描将失败。
no-fail: true您可以使用配置选项或–no-failCLI 标志禁用退出并显示失败代码。0无论实际测试结果如何，这都会指示 Hadolint 使用代码退出。如果您想将 Hadolint 作为非阻塞作业包含在 CI 管道中，它会很有用。

信任登记处

配置文件的另一个用途是定义您希望能够在 Dockerfiles 中引用的可信注册表。设置该trustedRegistries字段后，当使用来自另一个注册表的图像时，Hadolint 会警告您：

trustedRegistries:
  - docker.io
  - docker-registry.example.com

标签模式

Hadolint 也提供基本的标签掉毛功能。这使您可以强制通过 DockerfileLABEL指令添加到图像的标签符合指定的约束。这是它如何工作的示例：

label-schema:
  notes: text
  app-version: semver
  built-at: rfc3339

此配置片段定义了您可以在 Dockerfile 中使用的四个标签的数据类型。notes被声明为任意文本字段，而app-version必须是与semver 兼容的版本标识符。built-at被标记为 RFC-3339 日期时间字符串。您可以在Hadolint 文档中获得支持的类型的完整列表。

Hadolint 允许使用未在您的架构中列出的标签。您可以通过设置或使用标志禁用此功能并将LABEL指令限制为仅存在于模式中的指令。strict-labels: true–strict-labels

输出格式

format通过选项或–format标志支持多种输出格式。默认值是tty向终端发出彩色输出。可以使用–no-color标志禁用颜色。

可以使用以下替代格式化程序：

• json– 以详细的 JSON 结构形式提供检测到的问题列表，非常适合与您自己的脚本一起使用。
• checkstyle– Checkstyle兼容报告。
• codeclimate–符合Code Climate的报告。
• gitlab_codeclimate– 与 GitLab 的集成代码质量功能一起使用的代码气候报告的变体。这使您可以在使用 GitLab
• CI 运行 Hadolint 时将错误视为合并请求页面上的小部件。

这些输出格式非常适合以编程方式使用 Hadolint 或作为 CI 管道的一部分。

概括

Hadolint 自动检测 Dockerfile 问题。这有助于您的 Docker 映像遵守最佳实践和组织标准。默认配置是一个很好的起点，但您可以通过重新分类和禁用规则来自定义它以满足您的需求。

您应该考虑将 Hadolint 与您的 CI 工具集成，以便在提交 Dockerfile 更改时获得即时报告。这通过让开发人员立即了解问题来加速代码审查。您还可以在通过社区支持的编辑器扩展工作时在本地使用该工具，从而提供更短的反馈循环。