python hadolint

# 聊聊Python里的Hadolint：给Dockerfile做个“体检”

平时写Dockerfile的时候，有没有那么一瞬间觉得不太踏实？明明跑起来了，但总担心镜像层太臃肿，或者哪里藏着安全隐患。这种时候，就需要一个懂行的“体检医生”来帮忙看看。Python生态里就有这么个工具，叫Hadolint。

这东西到底是什么？

Hadolint这个名字，乍一听像是把“Docker”和“lint”拼在了一起。没错，它就是个专门给Dockerfile做代码检查的工具。不过有意思的是，它虽然用Python包的形式分发，内核其实是个Haskell写的程序。Python这边更像是个包装器，让这个工具能更方便地集成到Python项目的工作流里去。

你可以把它想象成家里那个专门检查水电的老师傅。他可能不负责装修（构建镜像），也不负责搬家具（部署容器），但管道有没有漏、线路有没有接错，他一眼就能看出来。Hadolint做的就是这个工作——在Dockerfile真正变成镜像之前，先把里面的“施工图纸”检查一遍。

它能帮你发现什么？

用上Hadolint之后，你会发现Dockerfile里原来藏着这么多可以优化的地方。比如最常见的，很多人喜欢在Dockerfile里写RUN apt-get update && apt-get install -y，但后面清理缓存的操作就忘了。Hadolint会提醒你，安装完包之后最好把/var/lib/apt/lists/清空，这样镜像能小不少。

安全方面它也挺在行。比如用ADD指令从远程URL下载文件，Hadolint会建议换成COPY加上wget或者curl的组合。因为ADD指令会自动解压压缩包，万一远程文件被篡改，可能带来风险。这种细节，平时自己写的时候很容易忽略。

还有些是纯粹的最佳实践。比如每个指令后面加\换行的时候，顺序怎么排更清晰；WORKDIR设了之后，后面的路径用绝对地址还是相对地址更合适。这些建议不会让你的Dockerfile跑不起来，但会让它看起来更专业，维护起来也更方便。

怎么把它用起来？

安装很简单，pip install hadolint就行。不过因为内核是Haskell写的，第一次用可能会自动下载一个二进制文件，稍微等一会儿就好。

用的时候更简单，直接在项目目录下运行hadolint Dockerfile。如果Dockerfile不在当前目录，或者有别的名字，把路径指给它就行。输出结果很直观，每条问题都会标出是警告还是错误，在文件的第几行，属于哪一类问题。

如果想集成到CI/CD流程里，它也能配合。返回非零状态码、输出格式调整这些功能都有。有些团队会在提交代码的钩子里加上Hadolint检查，这样在代码进仓库之前就能发现问题。

一些实际用下来的经验

刚开始用的时候，可能会被它报出的一大堆问题吓到。这时候不用急着全部修复，可以先把那些标为“错误”的解决了，警告类的可以慢慢来。有些规则可能不太符合你项目的实际情况，Hadolint也支持通过配置文件忽略特定的检查项。

配置文件可以放在项目根目录的.hadolint.yaml里，也可以放在用户目录下。里面能设置忽略哪些规则、调整规则的严重程度，挺灵活的。建议团队内部统一一套配置，这样大家检查的标准都一样。

还有个实用的技巧是把它和Docker的多阶段构建结合起来检查。Hadolint能理解多阶段构建的结构，针对不同的构建阶段给出不同的建议。比如构建阶段可能用很多开发工具，但最终镜像应该只留下运行时必需的东西。

和其他工具比比看

市面上检查Dockerfile的工具不止Hadolint一个。比如Docker官方出的dockerfilelint，用Node.js写的，规则集相对少一些，但更轻量。还有dockle、trivy这些，侧重点不太一样，有的专门查安全漏洞，有的查配置合规。

Hadolint的特点在于检查的维度比较全，从写法规范到安全实践再到性能优化都覆盖了。而且因为规则很多（现在有上百条），能发现的问题类型也更丰富。不过这也意味着学习成本稍微高一点，需要花点时间理解它每条规则到底在说什么。

选哪个工具，得看团队的具体需求。如果刚开始接触Docker，想有个全面的指导，Hadolint挺合适。如果已经有一套成熟的实践，只想查漏补缺，可能更轻量的工具就够了。有些团队甚至会组合使用，用Hadolint做日常检查，再用专门的安全工具做深度扫描。

说到底，工具只是工具。Hadolint给出的所有建议，最终都需要人来判断适不适合自己的项目。它就像个经验丰富的搭档，提醒你可能忽略的细节，但方向盘还是在自己手里。用久了会发现，最大的收获不是通过了多少次检查，而是自己写Dockerfile的时候，自然而然就会避开那些常见的坑。