我使用nginx作为基本映像将我的SPA Web应用程序停靠，然后复制我的nginx.conf并构建文件。正如Dockerize Vue.js App所说，我认为许多码头化SPA解决方案是相似的。
如果我不使用docker，我将首先构建SPA代码，然后将构建文件复制到nginx根目录（安装/设置nginx之后我根本没有改变它）
那么dockerizing SPA的好处是什么？
-----更新-----
一个答案说：“如果每次发布应用程序的新版本时应用程序都已停靠，那么Nginx服务器将获得所有可用的新更新。”我完全不同意这一点。我不需要最新版本的nginx，毕竟我只使用nginx的基本功能。我的一些团队成员在开发时只使用与Linux捆绑的nginx版本。如果我的docker镜像使用最新的ngixn，它实际上会创建与开发环境不同的环境。
我意识到我的问题可能会被关闭b / c它将被视为基于意见。但我用谷歌搜索它并找不到满意的答案。
如果我不使用docker，我将首先构建SPA代码，然后将构建文件复制到nginx根目录（安装/设置nginx之后我根本没有改变它）
这是一个安全问题......火灾和忘记是关于服务器在这里做的似乎。
如果每次发布应用程序的新版本时应用程序都已停靠，Nginx服务器将获取可用的所有新更新。
请记住，如果您的应用程序不会每周发布新版本，那么您需要考虑至少每周重建docker镜像以获取更新并使所有内容与最新的安全补丁保持同步。
那么dockerizing SPA的好处是什么？
跨开发，升级和生产的相同环境。如果您运行应用程序，则在所有阶段称为100％奇偶校验，无论您部署何种类型的应用程序，都是如此。
如果某些内容在生产中不起作用，您可以通过摘要提取docker镜像并在本地运行以进行调试并尝试了解问题所在。如果您需要ssh到生产服务器，这意味着您的自动化管道已经失败，或者您甚至没有使用一个......
像Webpack这样的工具将Javascript应用程序编译为静态文件，然后可以随您选择的HTTP服务器一起提供。构建SPA后，构建的文件与index.html和其他资产（如图像文件）无法区分：它们只是由某些HTTP服务器提供服务的静态文件。
Docker容器封装了一个正在运行的进程。它本身并不能很好地包含这些静态文件。
您经常会看到运行面向开发人员的HTTP服务器的“SPA Docker容器”。但是，这样做并没有特别的好处。只需在本地开发应用程序，运行npm run build或其他任何内容来创建dist目录，然后以与发布其他资产相同的方式发布，即可获得同样出色的开发人员体验。自动化管道在这里很有用，但这不是Docker极其简单的任务。
（还记得当你这样做时，构建的应用程序在用户的浏览器上运行。这意味着它无法看到任何Docker内部网络机器：它无法使用Docker内部IP地址而无法使用内置的Docker DNS服务。它所到达的一切都必须在docker run -p发布的端口上，它必须使用到达主机的DNS名称。浏览器根本不知道Docker是否参与其中。）
有一些好处。
首先，构建一个Docker镜像意味着你明确地说明你的应用程序的规范运行时是什么 - 这个版本的nginx，具有SSL配置，无论如何。运行时的更改是在源代码管理中，因此您可以预测和可逆地升级。你说你不想要“最新版本” - 但如果最新版本修补了一个关键的安全漏洞怎么办？能够以可预测的方式升级，在“一次性”容器上意味着您可以在需要时进行升级。
其次，如果整个开发团队使用相同的Docker镜像，您可以避免使用不同配置的挑战，使“它可以在我的机器上运行”对bug进行响应 - 在SPA中，nginx的不同配置可能导致不同的行为。加入团队的新开发人员不必安装或配置任何东西，并且可以使用他们想要的任何设备 - 他们可以确定Docker中运行的设备与所有其他开发人员相同。
第三，通过将所有环境容器化（不仅仅是开发，而是测试和生产），您可以轻松地通过管道移动版本，并且只更改特定于环境的值。
现在，对于SPA来说，这些好处是真实的，但可能不会超过创建和维护Docker镜像的成本和工作量 - 不可避免地，Docker镜像成为瓶颈并且是人们首先责备的。如果你看到很多环境特定的痛苦（建议有一个一致的运行时环境是必要的），或者你看到很多“它在我的机器上工作”类型的bug，我只会投资它。