docker 镜像是否应该与代码捆绑在一起？

Question

我们正在构建一个 SaaS 应用程序。我（目前 - 对于这个应用程序）对可用性没有很高的要求。它主要用于特定时区并且仅用于商业目的，因此预定在凌晨 3 点重新启动应该不成问题。

它是一个在 fastcgi 服务器上以单声道运行的 ASP.NET 应用程序。由于安全原因，每个客户都将部署自己的应用程序。这将使用 docker 容器来完成，前面有一个 Nginx 服务器，以基于 URL 分发请求。如何部署它的可能方式适合我：

1. 仅使用 fcgi 服务器创建 docker 映像并从挂载点运行代码
2. 使用 fcgi 服务器和代码创建 docker 映像

1. 的优点似乎

• 更新代码更容易，因为 docker 容器可以继续运行
• 配置可以与代码绑定
• 我可以轻松（如果我愿意的话）为特定客户添加微小的更改

2. 的优点似乎

• 一切都在图像中，无需乱用其他文件，只需拉取并运行即可

1 的缺点。

• 除了正在运行的容器之外，还为许多客户提供了许多文件夹

2 的缺点。

• 配置不能在图像中（或者可以吗？- 我应该使用他们的配置为每个客户创建特定的图像吗？）=> 仍然为每个客户附加文件
• 更新容器比较困难，因为我需要重新启动它 - 但不是什么大问题，如开头所述

现在 - 第一年 - 客户数量会很少，当需求低时，任何解决方案都足够好。我正在关注 - 超过 100 位客户的情况。

另外，为了将来我想为这个项目设置 CI，所以我们不需要手动更新所有客户实例。 Docker 镜像可以自动构建，但不确定是否足够。

我的顾虑基本上是 - 哪个解决方案不那么混乱，也许更容易自动化？

我找不到任何涵盖类似场景的 docker 最佳实践。

Answer 1

您的应用程序的依赖项可能会依赖于代码，因此您有时仍需要重新构建映像并重新启动容器（无论何时添加新的依赖项）。

这意味着您将有两个升级工作流程：

• 仅更新代码的地方（当没有依赖项更改时）
• 您也可以更新映像并重新启动容器（当依赖项发生更改时）

这很可能是不可取的，因为它很难自动化。

所以，我建议将代码捆绑在图像上。

您绝对应该确保您的应用程序的配置可以存储在其他地方（例如，在卷上，或通过环境变量访问）。

---

最终，Docker 是a platform to package, deploy and run applications，因此打包应用程序（即在镜像上捆绑代码）似乎是更好的使用方式。