如何部署在docker中运行的应用程序-最佳实践？

我们正在讨论如何部署在docker容器中运行的应用程序。目前，我们在包含应用程序代码的管道中构建应用程序映像。这意味着我们必须在每次应用程序更新时构建docker映像

我们考虑的另一种方法是将应用程序代码放在服务器上的卷中。然后，我们在服务器上使用git发布最新版本。因此，图像不必重建

因此，我们讨论的选项是：

构建包含应用程序代码的映像

使用卷并将应用程序代码存储在服务器上

---

最佳做法是什么？为什么？

每次使用新应用程序构建映像时，您都可以轻松地在以后将其部署到客户或生产服务器上。docker映像准备好后，可以将其保存在存储库中。此外，您可以完全控制docker处理当前应用程序的情况

如果要将应用程序保留在已装入的卷中，您必须记住以下问题：

• 应用程序的生命周期—当您必须更新应用程序时，如何处理容器—轻轻停止、覆盖并再次运行
• 如何部署您的应用程序？您必须通过SSH手动部署，或者您只想运行简单的命令docker run，它从您的存储库中运行您的最新版本

装载的卷主要用于以下情况：

• 您希望容器具有外部公开的设置-这也不是一个好主意
• 您希望从外部访问应用程序生成的数据，如日志、数据库等

要完全自动化，您可以：

• 为每个应用程序生成映像并推送到存储库
• 例如，用于自动更新生产服务器上的系统

---

我认为您应该遵循第一种方法，即每次代码发生更改时重建docker映像。理由如下：

首先，如果您使用的是卷，则每次都必须管理应用程序早期版本的干净关闭和删除，并检查应用程序的新版本是否正确运行。您的新应用程序可能会受到以前版本应用程序的依赖关系的影响。这也需要注意

其次，可能会安装一些框架的版本更新，并且将在当前应用程序中安装一些新框架。在这种情况下，第一种方法似乎是唯一的选择

第三，当您使用docker volume时，您将删除docker最重要的功能，即从外部环境抽象。此外，映像可能会因此变得依赖于计算机，这可能会影响您是否要在多个环境中发布应用程序

---

我的建议是使用一些持续集成工具创建一个管道，并完全自动化从代码构建、docker映像构建到部署到您的环境的过程。

这里的其他答案解释了将代码构建到您的映像中的要点，我想更进一步，向您展示如何在遵循此最佳实践的同时获得两个世界的好处

Docker最佳实践要求在部署之前将源代码构建到映像中，而不是部署安装了依赖项的映像，然后将源代码作为卷装入

这为您提供了一个自包含、可移植的容器，可以直接进行测试、部署或回滚

我可以试一下你为什么要考虑热安装代码吗

热安装代码之所以吸引人，有几个原因——它们都很容易实现，而不必牺牲构建自包含映像的最佳实践：

• 构建Docker映像可能会很慢，所以当您可以热装载代码时，为什么要重新构建以进行小的更改呢
  一个补充的最佳实践是使用一个安装所有依赖项的“基本映像”——通常是构建docker映像的缓慢部分。关键是这个基本图像不会经常改变
  但是从它派生的映像--安装源代码的应用程序映像--将随着您要部署的每次提交而改变。这一衍生图像的构建速度将非常快。Dockerfile可以简单到：

  FROM myapp/base .      # all dependencies installed in base image
  ADD code.tar.gz /src   # automatic untaring!
  CMD [...]              # whatever it takes to run your app
  

• 热安装可以加快开发周期，因为开发人员不需要刷新docker容器、重建和运行新容器就可以看到更改
  这是一个公平的观点。我建议创建一个“dev”映像（它也将从基本映像派生），通过卷而不是测试和部署映像中的源代码安装步骤来实现代码装载

---

因此，如果我理解得很清楚，您可以将应用程序“编译”在版本控制下。你的结果没有某种类型的存储库吗？