deployment - 每次都构建/推送 Docker - 持续部署是否实用？

Question

如果每天部署 5-10 次，每次部署时都完全重建并推送一个 docker 镜像真的实用吗？

我承认这些好处，正如 CircleCI 的 Continuous Integration and Delivery with Docker 中所述。 ，即:

Note that Elastic Beanstalk also allows you to deploy a Dockerfile and associated source code instead of a built image, but pre-building the image on CircleCI and running some form of verification on it allows your deployments to be more deterministic because you remove the build environment as a variable that differs between test and production.

但是，一旦包含所有依赖项和源代码，我们完全构建的 webapp 镜像就接近 1GB。我只是不明白部署高达 200GB/月(即每天 10 次提交，持续部署)的实际情况，而实际上 99% 的数据在构建之间没有变化。即，它可能只是值(value) 1k 的 HTML、JS 或 CSS 被更改以添加功能。我更喜欢一种方法，其中 docker 镜像包含很少更改的软件，其余部分作为捆绑包的一部分压缩。这仍然会产生一个独立的部署文件(不需要下载更多的依赖项)，但会大大减少构建时间和带宽。

Answer 1

当前接受的方法是在机器镜像中包含一个基本的 Docker 镜像，该镜像具有依赖项、操作系统等。使用该 Docker 镜像作为 FROM Dockerfile 中的一行。这将利用 Docker 的图像层并仅下载差异。

您可能仍希望在子 Dockerfile 中安装依赖项，因为它们会随着时间的推移而改变，但尽量将它们中的大部分保留在基本镜像中，这样下载的次数就会减少。