Deployment docker映像是否应该与代码绑定？

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

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

仅使用fcgi服务器创建docker映像，并从装入点运行代码

使用fcgi服务器和代码创建docker映像

赞成1。似乎

• 更新代码更容易，因为docker容器可以继续运行
• 配置可以与代码捆绑在一起
• 我可以很容易地（如果我想的话）为特定的客户添加一些小的更改

赞成2。似乎

• 所有内容都在一个映像中，不需要处理其他文件，只需将其拉出来并运行即可

1的缺点

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

两个犯人

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

就目前而言，第一年的客户数量将很低，当需求较低时，任何解决方案都足够好。我更关注的是——100名以上的客户将如何应对

另外，为了将来，我想为这个项目设置CI，所以我们不需要手动更新所有客户实例。Docker映像可以自动生成，但这还不够

我关心的基本问题是——哪种解决方案更简单、更容易自动化

---

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

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

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

• 一个只更新代码的程序（当没有依赖项更改时）
• 您也可以在其中更新映像，并重新启动容器（当存在依赖项更改时）

这很可能是不可取的，因为很难实现自动化

因此，我建议将代码捆绑在图像上

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

---

最终，Docker是，因此打包应用程序（即在图像上捆绑代码）似乎是更好的使用方法