多数 Dockerfile 示例可能都不够严谨

原文:Broken by default: why you should avoid most Dockerfile examples

作者:Itamar Turner-Trauring

想把 Python 应用打包成 Docker 镜像,很自然的行为就是上网搜个例子。简单的一搜,就能得出大量简单易懂的结果。

不幸的是这些简单方便的例子经常是有一些这样那样的缺陷,有的显而易见,有的可能就不那么明显了。为了发掘这些问题,本文中将要:

  1. 用一个在 Google 搜索结果中常见的 Dockerfile 开始。
  2. 展示其中的问题。
  3. 给出一些修复问题的建议。

本文的 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 修复,可能还要禁用缓存对镜像进行周期性重建,来获取安全加固。

参考链接

Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

相关

下一页
上一页
comments powered by Disqus