如何在生产中处理基于docker-compose的应用程序的更新

如何解决如何在生产中处理基于docker-compose的应用程序的更新

我有一个基于docker-compose的应用程序，该应用程序将部署到生产服务器。它的两个容器使用如下数据量共享目录内容：

...
services:
  service1:
    volumes:
      - server-files:/var/www

  service2:
    volumes:
      - server-files:/var/www

  db:
    volumes:
      - db-persistent:/var/lib/MysqL


volumes:
  server-files:
  db-persistent:

在构建服务文件的Dockerfile时，将填充服务1的/var/www。我的理解是，如果我在重建service1时更改存储在/var/ww中的代码，其更新将被现有的服务器文件卷隐藏。

什么是更新此部署的正确方法，以便使更改以最小的方式传播停机并没有删除其他卷？

修改

仅为了阐明我当前的部署过程，其工作方式如下：

本地更新代码，并将更改提交/推送到Github
在服务器上拉动更改
运行docker-compose build来重建所有更改的容器
运行docker-compose up -d以重新加载所有更新的容器

问题是/var/www中已更改的代码被已存在的命名卷server-files隐藏。我的问题是处理此更新的最佳方法是什么？

解决方法

首先，docker-compose不适用于生产部署。此问题说明了原因之一：没有自动滚动升级。创建单个节点群将使您的生活更轻松。要进行部署，只需运行docker stack deploy -f docker-compose.yml。但是，您可能需要调整撰写文件并进行一些初始设置。

第二，您误会了如何使用docker。为应用程序代码创建卷绑定只是您在开发中所做的快捷方式，因此您不必在每次更改代码时都重新构建映像。但是，在部署应用程序时，将为应用程序构建生产映像，其中包含运行所需的所有代码。

一旦生成了该生产映像，就将其推送到映像存储库（可能是docker hub）。您的生产服务器从该存储库中提取图像，并使用它来创建运行您的应用程序的容器。

如果要从生产服务器中提取应用程序代码，那么为什么要完全使用Docker？在这种情况下，当您可以直接在主机VM上直接运行所有内容并制作一个简单的脚本来停止应用程序，提取代码并重新启动应用程序时，这只会增加您的工作难度并增加额外的步骤。

最后，我通过在
docker-compose之外管理数据库卷db-persistent来处理此问题。在运行docker-compose up之前，我通过运行
docker volume create db-persistent手动创建了卷，并在docker-compose.yml中，使用以下配置将卷标记为外部卷：

volumes:
  db-persistent:
    external: true

我的部署过程现在如下所示：

从Github中拉出更改
运行docker-compose build以自动构建任何更改的容器。
关闭现有应用程序并通过运行docker-compose down -v
运行docker-compose up再次启动应用程序。

在运行docker-compose down -v的此新设置中，仅删除了server-files卷，而保留了
db-persistent卷。