Deployment Docker每次构建/推送-是否适用于连续部署？

如果您每天部署5-10次，那么每次部署时完全重建和推送docker映像真的实用吗

我承认CircleCI’s中提到的好处，即：

请注意，Elastic Beanstalk还允许您部署Dockerfile和相关源代码，而不是构建映像，但是，在CircleCI上预构建映像并在其上运行某种形式的验证允许您的部署更具确定性，因为您将构建环境作为测试和生产之间不同的变量删除

---

然而，一旦包含所有依赖项和源代码，我们完全构建的webapp映像将接近1GB。我只是不明白，在构建之间几乎99%的内容不变的情况下，部署高达200GB/月（即每天10次提交，持续部署）是多么实际。i、 可能只有1k的HTML、JS或CSS被更改为添加一个功能。我更喜欢docker映像包含很少更改的软件，其余的压缩为捆绑包的一部分。这仍然会产生一个自包含的部署文件（无需下载其他依赖项），但会大大减少构建时间和带宽。

目前接受的方法是在机器映像中包含一个基本Docker映像，该映像包含依赖项、操作系统等。将该Docker图像用作Docker文件中的

FROM

行。这将利用Docker的图像层，只下载差异

---

您可能仍然希望在子Dockerfile中安装依赖项，因为它们会随着时间的推移而改变，但请尝试将大部分依赖项保留在基本映像中，以便下载的内容更少。

因此，请使用静态（ish）内容制作父Dockerfile，并由此生成最终文件。大-小版本控制。当然，您也可以完全按照您描述的方式进行。一切由你决定。或者将git与触发的拉/静态图像一起使用。或者..在node.js这样的环境中，如何定义“依赖项”？i、 e.高达node.js版本（0.10.32等）或包含

节点模块

？我仍在犹豫是否将

节点\ u模块

作为构建映像的一部分。它们比其他模块更容易更改。我确实在图像中包含了节点_模块。事实上，我确信node_模块应该签入repo。如果这样做，则不需要在Dockerfile中安装npm。您的构建上下文将更大，但在构建时不需要安装。我同意在生产环境中运行

npm install

是个坏主意，但我仍然不确定是否将节点_模块提交到repo。如果我有我们的CI服务器测试，然后捆绑节点模块，那么至少我可以确保生产与测试相同，并且我的捆绑包是完全独立的，并且在到达生产服务器后不需要进一步的外部下载。另外，如果您归档了捆绑包，那么您可以随时回滚，而不必担心npm的可用性。