一个微服务停留在一个docker容器中。现在，假设我要升级微服务 - 例如，某些配置已更改，我需要重新运行它。
我有两个选择：
我可以尝试重用现有的图像，通过在容器启动时运行的脚本，并通过从某个共享卷读取新配置（如果有）来更新微服务。更新后，脚本运行微服务。
我可以简单地删除现有的图像和容器，并使用更新的配置/代码创建新图像（使用新名称）和新容器。
解决方案＃2对我来说似乎更加强大。没有“更新”程序，只有单个容器创建。
然而，令我困扰的是，如果重新创建图像有一些不良的副作用？像很多悬垂的图像或类似的东西。想象一下，这可能会在用户使用应用程序时经常发生 - 例如，如果开发人员正在尝试某些东西，他想要使用不同的微服务配置，并且他会经常重新启动它。但是一旦配置完毕，这不会改变。另外，当我说配置时，我不仅仅意味着配置文件，还包括用户代码等。
答案 0 :(得分：2)
对于生产更改，您需要部署新映像以更改文件。这可确保您的流程可重复。
但是，每次编写新代码时通过创建新图像进行开发将是一场噩梦。最好的选择是运行docker容器并将容器的源目录挂载到文件系统。这样，当您在编辑器中进行更改时，容器中的代码也会更新。
你可以这样做：
docker run -v /Users/me/myapp:/src myapp_image
这样，您只需构建一次myapp_image，之后就可以轻松进行更改。
现在，如果您有一个未安装的正在运行的容器，并且您想要对该文件进行更改，那么您也可以这样做。不建议这样做，但很容易理解你可能想要的原因。
如果你跑：
docker exec -it <my-container-id> bash
这会让你进入容器，你可以在里面进行vim / nano / editor的更改。
答案 1 :(得分：1)
您的选项＃2绝对适用于生产环境。理想情况下，您应该围绕此过程进行一些自动化，通常执行类似蓝绿色部署的操作，您可以根据旧图像逐个替换旧图像，随时测试，然后只有当您满意时才进行测试新部署是否从先前版本清除容器并删除图像。这样，如果需要，您可以快速回滚到以前的版本。
在开发环境中，您可能希望采用不同的方法，在运行时将应用程序绑定到容器中，从而允许您动态地进行更新，而无需重建映像。 Docker Compose docs中有一个很好的例子，它说明了如何使用公共基础组合YML，然后对其进行扩展，以便在开发和生产场景中获得不同的行为。