dockerfile 阶段_多阶段dockerfile的缺点

dockerfile 阶段

Since its introduction in 2017, the Docker multi-stage build feature has been promoted as a practical way of obtaining streamlined images. However, I have always viewed it as a bodge that channels users towards bad habits. Instead of explaining why I think one should never use this feature ever, I would rather like to layout the shortcomings that must be overcome in order for the feature to become a better practice.

自2017年推出以来，Docker的多阶段构建功能已得到推广，是获取简化映像的实用方法。 但是，我一直认为它是引导用户养成不良习惯的庞然大物。 我不想解释为什么我认为永远不要使用此功能，而是想安排必须克服的缺点，以使该功能成为更好的实践。

卖点 (The Selling Point)

Multi-stage builds were introduced into Docker as a way of using multiple containers to produce a final image. This facilitated the implementation of what was dubbed the builder pattern in which a separate build image was created before the binary image. The build image would contain all of the necessary build tools while the binary image would only contain the application binary and the necessary runtime platform. For example, if the source code is written in Java, the build image would contain a JDK, but the binary image would only need a JRE.

Docker中引入了多阶段构建，这是使用多个容器生成最终映像的一种方式。 这有助于实现所谓的构建器模式 ，该构建器模式是在二进制映像之前创建一个单独的构建映像。 构建映像将包含所有必需的构建工具，而二进制映像将仅包含应用程序二进制文件和必需的运行时平台。 例如，如果源代码是用Java编写的，则构建映像将包含JDK，但是二进制映像仅需要JRE。

This is in contrast with a more naive way of building the binary image which would be to start from an image containing all of the build tools and the runtime platform. This naive way produces an image that is much larger and that contains programs and data that are unnecessary for running the application. Not only is this deadweight going to impact the bandwidth needed for downloading the image to production, but it leaves potential attack vectors laying around.

这与构建二进制映像的更幼稚的方式形成对比，后者是从包含所有构建工具和运行时平台的映像开始的。 这种幼稚的方式会产生更大的图像，并且包含运行应用程序所不需要的程序和数据。 这种沉重负担不仅会影响将映像下载到产品所需的带宽，而且还会留下潜在的攻击媒介。

真正的目的 (The True Purpose)

I would like to argue that the true motivation behind multi-stage builds was to fix a problem with using Docker Hub automated builds.

我想指出，多阶段构建背后的真正动机是为了解决使用Docker Hub 自动构建的问题 。

In keeping with the philosophy of making container technology as accessible as possible, Docker Hub has long facilitated image production through automated builds. All you need is to have the Dockerfile hosted on a GitHub or Bitbucket code repository and to link the image repository to it. Docker Hub will then build the image on every push.

遵循使容器技术尽可能易于访问的理念，Docker Hub长期以来一直通过自动构建来促进映像制作。 您所需要做的就是将Dockerfile托管在GitHub或Bitbucket代码存储库上，并将映像存储库链接到它。 然后，Docker Hub将在每次推送时构建映像。

This involves cloning the code repository and then running docker build. This ruled out the builder pattern. A user had to choose between living with unnecessarily large image sizes or using an alternative to Docker Hub automated builds. Docker probably saw a drop in the use of this feature, and understandably wanted to bring users back. Features, like this one, that are accessible to a wide variety of users have a high potential for attracting business.

这涉及克隆代码存储库，然后运行docker build 。 这排除了构建器模式。 用户必须选择使用不必要的大尺寸图像还是使用Docker Hub自动构建的替代方案。 Docker可能对此功能的使用有所减少，可以理解的是希望将用户带回。 像这样的功能可供众多用户使用，具有吸引业务的巨大潜力。

竞赛 (The Competition)

When I first heard about multi-stage builds, I didn’t see much use for it personally. I wasn’t using Docker Hub automated builds and had no plans to in the immediate future. When I experimented with the feature, I started to draw comparisons with competing solutions.

当我第一次听说多阶段构建时，我个人认为它没有太多用处。 我没有使用Docker Hub自动构建，也没有计划在不久的将来。 当我尝试该功能时，我开始与竞争解决方案进行比较。

The first class of competitors that I identified was the class of continuous integration tools. With these tools, one also defines a build process as a pipeline of stages. For example, the stages could be compiling and packaging. Often there could also be stages for various types of testing, code quality evaluation or any number of other static or dynamic analyses.When compared to the wide range of CI tools — and there are a lot — multi-stage builds seem to hold up fairly well. They have the huge advantage of being able to run on a local machine. This makes the feedback loop much shorter, especially when working on the definitions of the stages themselves. Tweaking a CI script can take longer because the pipeline can only be initiated by the CI server which can only happen after changes have been pushed to the central code repository.However multi-stage builds are not quite as feature-rich. This isn’t such a problem for me because I don’t find many of the extra features useful.

我确定的第一类竞争对手是持续集成工具。 使用这些工具，还可以将构建过程定义为阶段的流水线。 例如，阶段可以是编译和打包。 通常，还可能存在用于进行各种类型的测试，代码质量评估或任何其他静态或动态分析的阶段 。与各种各样的CI工具(数量很多)相比 ，多阶段构建似乎可以保持稳定好。 它们具有能够在本地计算机上运行的巨大优势。 这使得反馈循环更短，尤其是在处理阶段本身的定义时。 调整CI脚本可能需要更长的时间，因为管道只能由CI服务器启动，这只能在将更改推送到中央代码存储库之后才能发生。但是，多阶段构建的功能并不十分丰富。 对我来说，这不是一个问题，因为我发现许多其他功能都没有用。

One of the main reasons that I don’t rely on many of the features CI tools provide is that I prefer to delegate to a build automation tool. I would rather the pipeline just have one stage consisting of calling the build automation tool with a specific set of arguments. I find that this is a better assignment of responsibilities. The CI tool is responsible for scheduling builds, whilst the build automation tool is responsible for knowing what to build and in which order.

我不依赖CI工具提供的许多功能的主要原因之一是，我更喜欢委托给构建自动化工具。 我宁愿管道只有一个阶段，即用一组特定的参数调用构建自动化工具。 我发现这是更好的职责分配。 CI工具负责计划构建，而构建自动化工具则负责了解构建内容和顺序。

This method has the added benefit of allowing for the build actions to be run easily on any machine. It also allows for more versatility in running build actions. For example, I might want to skip certain stages or specify a development environment. There are only ways two ways to vary a Docker multi-stage build: using the --target option to stop at a specific stage or using build arguments. With most build automation tools, there are many more useful ways to vary the build. My favourite example is Maven profiles mainly because they shorten the amount of typing on the command line.

此方法的附加好处是允许在任何计算机上轻松运行构建操作。 它还允许在运行构建操作时具有更多的通用性。 例如，我可能想跳过某些阶段或指定开发环境。 只有两种方法可以改变Docker多阶段构建：使用--target 选项在特定阶段停止或使用build arguments 。 使用大多数构建自动化工具，可以使用更多有用的方法来更改构建。 我最喜欢的示例是Maven配置文件，主要是因为它们缩短了在命令行上键入的次数。

If I want some or all of the build actions to be run within a container, this is possible without using a multi-stage Docker build. Some build automation tools facilitate this to various degrees. In my opinion, Haskell Stack has the easiest option for enabling all build actions to be run in a container. Bazel always sandboxes build actions and provides options for using Docker containers as part of that process.

如果我希望某些或所有构建操作在容器内运行，则可以在不使用多阶段Docker构建的情况下实现。 一些构建自动化工具在不同程度上促进了这一点。 我认为， Haskell Stack具有使所有构建操作都可以在容器中运行的最简单选项。 Bazel始终使用沙箱构建操作，并提供使用Docker容器作为该过程一部分的选项。

挑战 (The Challenge)

In my opinion, Docker multi-stage builds don’t currently compare favourably to the competition from build automation tools such as Maven or Bazel. I think that it remains useful for the narrow case of quickly getting an image built through Docker Hub automated builds. For the feature to start becoming competitive beyond that, I would recommend expanding the feature to provide more ways of varying the build steps that are run. I would also recommend providing ways of shortening the command that must be typed for certain variations, perhaps in the same vein as Maven profiles.

我认为，Docker多阶段构建目前无法与Maven或Bazel等构建自动化工具的竞争相提并论。 我认为，对于通过Docker Hub自动构建快速构建映像的狭义情况，它仍然有用。 为了使该功能开始具有竞争力，我建议扩展该功能以提供更多方式来更改运行的构建步骤。 我还建议您提供一些方法来缩短必须为某些变体键入的命令，也许与Maven概要文件一样。

翻译自: https://medium.com/swlh/the-shortcomings-of-multi-stage-dockerfiles-6a40d398fb84

dockerfile 阶段