docker图像应该与代码捆绑在一起吗？

Question

我们正在构建SaaS应用程序。我现在没有（对于这个应用程序）对可用性的高要求。它主要用于特定的时区，仅用于商业目的，所以在凌晨3点重新安排的时间根本不应该成为问题。

这是一个使用fastcgi服务器以mono运行的ASP.NET应用程序。出于安全原因，每个客户都将部署自己的应用程序。这将使用docker容器完成，前面有一个Nginx服务器，用于根据URL分发请求。部署它的可能方法适合我：

1. 仅使用fcgi服务器创建docker镜像并从挂载点运行代码
2. 使用fcgi服务器和代码
创建docker镜像 1. p的优点似乎是
• 更新代码更容易，因为docker容器可以继续运行
• 配置可以与代码捆绑在一起
• 我可以很容易地（如果我曾经想要）为特定客户添加小的更改
2. p的优点似乎是
• 一切都在图像中，不需要乱用其他文件，只需拉动它并运行它

缺点1。

• 除了运行容器之外，还有很多客户的许多文件夹

为2的利弊。

• 配置无法在图像中（或者它可以吗？ - 我应该为每个客户创建具体配置吗？）=＆gt;还为每个客户提供了其他文件
• 更新容器更难，因为我需要重新启动它 - 但不是很重要，如开头所述

目前 - 第一年 - 客户数量很少，而当需求低时，任何解决方案都足够好。我正在寻找 - 与100位客户合作的方式。

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

我的担忧基本上是 - 哪种解决方案不那么混乱，可能更容易实现自动化？

我无法找到与docker相关的最佳做法，其中包含类似的情况。

Answer 1

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

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

• 只更新代码的地方（没有依赖项更改时）
• 您也可以更新图像，并重新启动容器（当存在依赖项更改时）

这很可能是不受欢迎的，因为它很难实现自动化。

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

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

---

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