如果您提出这个问题，您可能已经开始在本地开发环境使用Docker。如果您已经完成了适当的工作，那么只需一个docker- up就可以保持当前任务，并且你修改代码后立马可以在运行的服务器上看到效果。太爽了！
这里有一个重要的设置就是须要将你的项目代码从宿主机安装到docker容器中。这样的话你就可以选择你的IDE对其进行编辑并且不须要在每次代码有变化时就重新构建镜像。
现在你准备好将迁移到除本地开发之外的其他环境。生产环境怎么样？使用相同的方法有什么问题么？您已经知道有人在部署时将代码直接放入镜像中。你也必须这样做吗?你是不是错过了什么重要的东西?
两种选择：
要在生产环境中运行代码，你可以都使用这两种选择。和在本地使用类似的工作流程。但是制作完整镜像有一些优势，只有在部署工作流程正确的情况下才能挂载你的代码。 更多信息详见下文。
两个正确的工作流程如下:
1.当提交时为Docker 镜像创建一个tag
2.从服务器上拉取这个镜像
3.将这个新镜像运行为容器
4.可选（如果可能的话回滚到之前的镜像版本）
1.对git代码进行添加一个tag标签并标记成release版本
2.从你的服务器check out出这个提交版本
3.从deploy-friendly通用镜像启动容易并挂载你的代码
4.可选（如果需要，回滚到之前的check out出来的版本）
构建Artifacts
这两个工作流程都有一个共同的重要细节。通过创建镜像tag或使用版本标记版本，您将创建 build artifacts。
这种做法符合12因素指南。它指定了将代码库到部署的三个阶段。在构建阶段，您可以精确确定代码的版本，然后向他添加配置信息，最后运行它。
标记的git仓库或者被标记的镜像就是你部署的artifact。它可用于在不同的环境（如测试或生产）中运行，他们只是环境变量有所不同。
如上所述，您可以通过创建带标记的Docker映像来隐式地实现这一点，但不必这样做。你也可以只使用Docker然后在运行时隔离。 如果您使用Git标签之类的东西来确定您的版本，则不一定需要将代码挂载到Docker镜像中。
启动速度
尽管如此，构建带有代码的镜像还是有好处的。这种构建的镜像容器应该能够非常快速地启动，因为它已经完全打包了。在有些情况下，让容器启动并直接处于工作状态是很好的。如果你必须首先安装依赖项，情况就不是这样了，例如使用python pip ，如果你要挂载代码并使用Python，你就必须先安装python依赖。
安装卷（Mounting volumes）可能会比较慢。此外，您正在执行可能会有失败的操作——例如，如果依赖项源暂时不可用。这会导致更多的失败点，而不仅仅是Docker镜像注册。如果在启动时安装的依赖项的源关闭，您将无法启动新的容器。
还有一个优点:您以前在运行时才能发现的bug，它可以在构建过程中会被发现。为此，您应该采用自动化的测试方法，因此您的新版本首先在某种临时环境中运行 - 在生产环境运行之前发现错误。
总结：
如果您是通过标记提交（tagging commits）方式来发布版本，那么您已经以这种方式创建了构建工件（build artifacts）。如果你只是在容器启动时挂载你的代码或二进制文件，那么你的Docker容器只有一个工作 - 提供隔离。 这没有构建新的镜像。你应该在任何是都能够回滚。但是，请记住，他的缺点：启动时启动时间较慢，故障点较多。
原文：https://vsupalov.com/docker-mount-or-add-code-for-production-deploy/
