如何让 docker-compose 使用存储库中的最新图像

Question

我不知道自己做错了什么，但如果不先从系统中完全删除旧容器，我根本无法让 docker-compose up 使用我们注册表中的最新映像。尽管 docker-compose pull 获取了更新的图像，但 compose 似乎正在使用之前启动的图像。

我查看了How to get docker-compose to always re-create containers from fresh images?，这似乎与我的问题相似，但那里提供的解决方案都不适合我，因为我正在寻找可以在生产服务器上使用的解决方案，但我没有想要在再次启动它们之前移除所有容器（可能的数据丢失？）。我希望 compose 仅​​检测更改图像的新版本，拉取它们，然后使用这些新图像重新启动服务。

我为此创建了一个简单的测试项目，其中唯一的目标是让版本 nr 在每次新构建时增加。如果我浏览到创建的 nginx 服务器，则会显示版本 nr（这在本地按预期工作）。

码头工人版本：1.11.2 码头工人撰写版本：1.7.1 操作系统：使用 docker-toolbox 在 CentOS 7 和 OS X 10.10 上测试

我的 docker-compose.yml：

version: '2'
services:
  application:
    image: ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
    volumes:
      - /var/www/html
    tty: true

  nginx:
    build: nginx
    ports:
      - "80:80"
    volumes_from:
      - application
    volumes:
      - ./logs/nginx/:/var/log/nginx
  php:
    container_name: buildchaintest_php_1
    build: php-fpm
    expose:
      - "9000"
    volumes_from:
      - application
    volumes:
      - ./logs/php-fpm/:/var/www/logs

在我们的 jenkins 服务器上，我运行以下命令来构建和标记图像

cd $WORKSPACE && PROJECT_VERSION=$(cat VERSION)-dev
/usr/local/bin/docker-compose rm -f
/usr/local/bin/docker-compose build
docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest

这似乎正在做它应该做的事情，因为每次构建完成并且版本 nr 被碰撞时，我都会在我们的存储库中获得一个新的版本标签。

如果我现在跑步

docker-compose pull && docker-compose -f docker-compose.yml up -d

在我计算机上的一个文件夹中，其中的内容只有 docker-compose.yml 和构建 nginx 和 php 服务所需的 Dockerfiles，我得到的输出不是注册表中标记的最新版本号或显示在 docker-compose.yml (0.1.8) 中，但之前的版本是 0.1.7。但是，pull 命令的输出表明已获取了新版本的图像：

Pulling application (ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest)...
latest: Pulling from ourcompany/buildchaintest
Digest: sha256:8f7a06203005ff932799fe89e7756cd21719cccb9099b7898af2399414bfe62a
Status: Downloaded newer image for docker.locotech.fi:5000/locotech/buildchaintest:0.1.8-dev

只有当我运行时

docker-compose stop && docker-compose rm -f

然后运行docker-compose up 命令是否可以让新版本按预期显示在屏幕上。

这是 docker-compose 的预期行为吗？即我是否应该在再次运行up 之前始终执行docker-compose rm -f，即使在生产服务器上也是如此？还是我在这里做一些违背粮食的事情，这就是为什么它不起作用？

我们的目标是让我们的构建过程构建并创建 docker-compose.yml 中所需图像的标记版本，将它们推送到我们的私有注册表，然后“发布到生产步骤”以简单地复制 docker -compose.yml 到生产服务器并运行docker-compose pull && docker-compose -f docker-compose.yml up -d 以使新图像开始生产。如果有人对此有提示或可以指出此类设置的最佳实践教程，也将不胜感激。

Answer 1

为了确保您使用的是来自注册表（例如 docker hub）的最新版本的 :latest 标签，您还需要再次拉取最新标签。如果它发生变化，当你再次docker-compose up 时，将下载并启动差异。

所以这将是要走的路：

docker-compose stop
docker-compose rm -f
docker-compose pull   
docker-compose up -d

我将它粘贴到我运行以启动 docker-compose 并确保图像保持最新的图像中：https://hub.docker.com/r/stephanlindauer/docker-compose-updater/

Answer 2

要获取最新的图像，请使用 docker-compose build --pull

我使用下面的命令，它实际上是 3 in 1

docker-compose down && docker-compose build --pull && docker-compose up -d

此命令将停止服务，拉取最新图像，然后启动服务。

Answer 3

[编辑] 不要使用
以下是规范中的内容，但正如 cmets 中所指出的，尚未实施（docker-compose 1.29.2 和 2）。

自 2020-05-07 起，docker-compose 规范还定义了服务的“pull_policy”属性：

version: '3.7'

services:
  my-service:
    image: someimage/somewhere
    pull_policy: always

docker-compose spec 说：

pull_policy defines the decisions Compose implementations will make when it starts to pull images.

可能的值是（tl;dr，查看规范了解更多详情）：

• 总是：总是拉动
• 从不：不要拉（如果找不到图像则中断）
• 缺失：如果图像未缓存则拉取
• 构建：始终构建或重建

Answer 4

即使我的容器正在运行并且它更新得很好，我也会使用以下内容。

docker-compose pull
docker-compose up -d

Answer 5

为了结束这个问题，似乎有效的方法确实在运行

docker-compose stop
docker-compose rm -f
docker-compose -f docker-compose.yml up -d

即在再次运行 up 之前删除容器。

这样做时需要记住的是，如果您只运行rm -f，也会删除数据卷容器。为了防止我明确指定要删除的每个容器：

docker-compose rm -f application nginx php

正如我在问题中所说，我不知道这是否是正确的过程。但这似乎适用于我们的用例，所以在我们找到更好的解决方案之前，我们将继续使用这个解决方案。

Answer 6

选项down解决这个问题

我运行我的撰写文件：

docker-compose -f docker/docker-compose.yml up -d

然后我删除所有down --rmi all

docker-compose -f docker/docker-compose.yml down --rmi all

Stops containers and removes containers, networks, volumes, and images
created by `up`.

By default, the only things removed are:

- Containers for services defined in the Compose file
- Networks defined in the `networks` section of the Compose file
- The default network, if one is used

Networks and volumes defined as `external` are never removed.

Usage: down [options]

Options:
    --rmi type          Remove images. Type must be one of:
                        'all': Remove all images used by any service.
                        'local': Remove only images that don't have a custom tag
                        set by the `image` field.
    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.
    --remove-orphans    Remove containers for services not defined in the
                        Compose file

Answer 7

我花了半天时间解决这个问题。原因是一定要检查音量的记录位置。

卷： - api-data:/src/patterns

但事实是，在这个地方是我们更改的代码。但是在更新docker时，代码并没有改变。

因此，如果您正在检查其他人的代码并且由于某种原因您没有更新，请检查此。

所以一般来说这种方法是有效的：

docker-compose down

docker-compose 构建

docker-compose up -d

Answer 8

docker-compose pull
docker-compose up -d
docker image prune -af

它对我有用。

先拉最新的图片， 比更新容器， 最后清理我们不需要的图像。

Answer 9

拉新图片：docker-compose pull

使用新镜像重建 docker 容器：docker-compose up --force-recreate --build -d

删除未使用的图像：docker image prune -f

Answer 10

我已经在我们的 7-8 docker 生产系统中看到了这种情况。 在生产中对我有用的另一个解决方案是运行

docker-compose down
docker-compose up -d

这会删除容器，并且似乎“组成”了从最新图像创建新容器。

这还没有解决我的梦想，即每个更改的容器都向下+向上（连续，减少停机时间），但它可以强制“向上”更新容器。

Answer 11

如果 docker compose 配置在文件中，只需运行：

docker-compose -f appName.yml down && docker-compose -f appName.yml pull && docker-compose -f appName.yml up -d

Answer 12

但是

https://docs.docker.com/compose/reference/up/ -quiet-pull 不打印进度信息的拉动

docker-compose up --quiet-pull

不工作？

Answer 13

您的docker-compose.yml 使用image 指代ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev。这意味着运行docker-compose build 不会对ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev 执行任何操作。一定有类似下面的命令在某处运行：

docker build -t ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev

这会将版本化的构建放入您的存储库中。但它不会更新其最新标签。这仍然指向之前的版本（例如，0.1.7-dev）。

然后，您在 jenkins 上运行其他命令：

cd $WORKSPACE && PROJECT_VERSION=$(cat VERSION)-dev
/usr/local/bin/docker-compose rm -f
/usr/local/bin/docker-compose build
docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest

作为docker-compose build 的一部分，您实际上是在您的服务器上运行docker pull ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev。但是，这并不能说明标签ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest（您在命令docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION 中引用的）是如何进入您的服务器的。如果latest 标记没有事先由其他东西定义，那么docker tag 命令会给出这个错误：No such image: ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest。因此，在运行您显示的命令之前，您的 jenkins 服务器必须运行以下内容：

docker pull ourprivate.docker.reg:5000/ourcompany/buildchaintest

此命令将导致它拉取当时在您的存储库中设置为 latest 的任何内容。因为在运行上述docker pull 命令之前，您没有提供任何证据证明您曾经将新构建的buildchaintest:0.1.8-dev 推送为buildchaintest:latest，所以我们必须假设这是旧版本的来源。因此，您的 tag 命令有效地做到了这一点：

docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev

如果latest 指向0.1.7-dev 处的同一事物，则与执行相同：

docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.7-dev ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev

然后，稍后，当您运行docker-compose pull && docker-compose up -d 时，它当然会拉取存储库中设置为ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev 的内容，这应该是旧版本，因为您将0.1.7-dev 标记为0.1.8-dev。

注意事项

您似乎假设docker-compose build 做了一些与构建buildchaintest 有关的事情。但是，事实并非如此。您在docker-compose.yml 中设置了image，但没有设置build。这意味着docker-compose build 将不会构建buildchaintest docker 镜像——它只会直接拉取并运行docker 镜像标签。由于docker-compose build 不会尝试构建buildchaintest，因此在调用该图像后尝试标记或推送该图像是没有意义的。

另外，docker-compose push 存在并且如果你同时指定build 和image 会做所有的标记和推送（因为image 用于通知docker-compose 它应该设置一个标签对于建造的东西）。这将推送正确的标签（并且对于您的 docker-compose.yml 文件正确无操作）。

您的docker-compose 中包含build，但没有image。无论你在哪里运行docker-compose up，这些东西都会被构建。因此，在构建服务器上运行docker-compose build（除了测试构建运行完成之外）没有意义（除非您添加image 来设置标签并保存那些构建的图像并使用docker-compose push）。您不会为自己节省任何时间，也不会减少部署期间服务器执行的工作。您正在增加构建事物的次数以及系统中节点之间的可变性（因为构建服务器上构建的任何内容都将不同于服务器上运行的任何内容（例如，文件时间戳、更新的图像标签）。

很遗憾，您的问题不可信。您使用命令，就好像它们具有与应有的行为不同的行为一样。很抱歉攻击你的问题，但我学到了一些关于 docker tag 和 docker-compose 如何工作的令人惊讶的事情（对我来说）。谢谢！

tl;博士

确保您实际标记并将正确的图像推送到您的存储库中！

Answer 14

'up' 命令的 docker-compose 文档明确指出，如果自上次执行“up”后图像发生更改，它将更新容器：

如果服务存在现有容器，并且服务的配置或映像在容器创建后发生更改，docker-compose up 通过停止和重新创建容器来获取更改（保留已安装的卷)。

因此，通过使用“stop”，然后使用“pull”，然后使用“up”，这应该可以避免正在运行的容器丢失卷的问题，当然，对于镜像已更新的容器除外。

我目前正在尝试此过程，并将很快将我的结果包含在此评论中。

Answer 15

我正在使用以下命令获取最新图像

sudo docker-compose down -rmi all

sudo docker-compose up -d