多数 Dockerfile 示例可能都不够严谨
原文：Broken by default: why you should avoid most Dockerfile examples
想把 Python 应用打包成 Docker 镜像，很自然的行为就是上网搜个例子。简单的一搜，就能得出大量简单易懂的结果。
不幸的是这些简单方便的例子经常是有一些这样那样的缺陷，有的显而易见，有的可能就不那么明显了。为了发掘这些问题，本文中将要：
- 用一个在 Google 搜索结果中常见的 Dockerfile 开始。
- 展示其中的问题。
- 给出一些修复问题的建议。
本文的 Docerfile 仅用于解决这里发现的问题，不能算作最佳实践。
先天不足
看看下面的 Dockerfile，这是一个网上搜到的 Python 的容器化例子。做了一点点修改，来隐藏其出处，不过主干是一致的：
# DO NOT USE THIS DOCKERFILE AS AN EXAMPLE, IT IS BROKEN
FROM python:3
COPY yourscript.py /
RUN pip install flask
CMD [ "python", "./yourscript.py" ]
这个 Dockerfile 的一些问题
这个镜像中你能看到什么问题？
问题 1：Python 版本的不确定性
这里第一个需要注意的问题是，基础镜像是：python:3。在编写这个文件的时候，会安装 Python 3.7，但是可能未来某一天的重新构建，可能会变成 Python 3.8。这种版本切换，可能会让这一应用完全无法运行，从而打断了产品的交付过程。
建议：使用 python:3.7 作为基镜像。
问题 2：依赖库版本的不确定性
这里的 pip install flask，没有包含版本信息，所以每次重新构建，都可能升级成最新的 flask（或者 flask 的依赖，又或者 flask 的依赖的依赖）。保持兼容自然没问题，否则的话麻烦就大了。
建议：创建 requirements.txt，其中记载所有依赖的版本号，可以用 pip-tools 完成这一任务。
问题 3：代码的变更会让构建缓存失效
Docker 的层缓存对提高构件速度很有帮助。但是如果把 COPY 操作放在 pip install 前面，所有后续的层就都失效了，也就是说这一镜像会完全重新构建。
建议：在合适的时机进行文件复制。
问题 4：用 root 身份运行
缺省情况下，Docker 容器是用 root 身份运行的，这并不安全。
建议：如果不是有特定需要，例如监听 1024 以下的端口或者完成一些必须 root 身份的操作，建议使用非 root 账号。
改良版本
为了解决上面发现的几个问题，对 Dockerfile 做出如下修改：
FROM python:3.7
COPY requirements.txt /tmp/
RUN pip install -r /tmp/requirements.txt
RUN useradd --create-home appuser
WORKDIR /home/appuser
USER appuser
COPY yourscript.py .
CMD [ "python", "./yourscript.py" ]
这样改进了之后，也并不是就适合在生产环境中运行了，这个镜像还有一些不足。
例如，用一种受控的方式来对 requirements.txt 进行常规更新，以便进行安全更新和 Bug 修复，可能还要禁用缓存对镜像进行周期性重建，来获取安全加固。
参考链接
崔秀龙
简单，是大师的责任；我们凡夫俗子，能做到清楚就很不容易了。