我们使用一个脚本来检查正在运行的容器是否以最新映像启动。我们还使用upstart init脚本来启动docker映像。

    #!/usr/bin/env bash
    set -e
    BASE_IMAGE="registry"
    REGISTRY="registry.hub.docker.com"
    IMAGE="$REGISTRY/$BASE_IMAGE"
    CID=$(docker ps | grep $IMAGE | awk '{print $1}')
    docker pull $IMAGE

    for im in $CID
    do
        LATEST=`docker inspect --format "{{.Id}}" $IMAGE`
        RUNNING=`docker inspect --format "{{.Image}}" $im`
        NAME=`docker inspect --format '{{.Name}}' $im | sed "s/\///g"`
        echo "Latest:" $LATEST
        echo "Running:" $RUNNING
        if [ "$RUNNING" != "$LATEST" ];then
            echo "upgrading $NAME"
            stop docker-$NAME
            docker rm -f $NAME
            start docker-$NAME
        else
            echo "$NAME up to date"
        fi
    done

init看起来像这样

docker run -t -i --name $NAME $im /bin/bash

一种“docker方式”是使用docker hub自动构建。当上游容器被重建时，Repository Links特性将重建你的容器，Webhooks特性将向你发送通知。

看起来webhooks仅限于HTTP POST调用。您需要设置一个服务来捕获它们，或者可能使用其中一个POST发送电子邮件服务。

我还没有深入研究，但是新的Docker通用控制平面可能有一个检测更新容器和重新部署的功能。

我不打算讨论您是否希望在生产中进行无人值守的更新(我认为不需要)。我只是把这个留在这里作为参考，以防有人觉得有用。在终端中使用以下命令将所有docker映像更新到最新版本:

# docker images | awk '(NR>1) && ($2!~/none/) {print $1":"$2}' | xargs -L1 docker pull

另一种方法是假设您的基本映像很快就会落后(这很可能发生)，并定期强制应用程序构建另一个映像(例如每周)，如果它发生了更改，则重新部署它。

据我所知，像官方Debian或Java这样的流行基础镜像会更新它们的标记来满足安全修复，所以标记不是不可变的(如果你想要更强的保证，你需要使用参考[image:@digest]，在最新的Docker版本中可用)。因此，如果你要用docker build -pull构建你的映像，那么你的应用程序应该得到你引用的base image标签的最新和最好的。

由于可变标记可能令人困惑，所以最好每次都增加应用程序的版本号，这样至少在您的方面，事情会更清楚。

因此，我不确定在前面的答案之一中建议的脚本是否能完成工作，因为它不重新构建应用程序的映像——它只是更新基本映像标记，然后重新启动容器，但新的容器仍然引用旧的基本映像散列。

我不提倡在容器中运行cron类型的作业(或任何其他进程，除非真的有必要)，因为这违背了每个容器只运行一个进程的原则(关于为什么这样更好有各种各样的争论，所以我不打算在这里讨论)。

You can use Watchtower to watch for updates to the image a container is instantiated from and automatically pull the update and restart the container using the updated image. However, that doesn't solve the problem of rebuilding your own custom images when there's a change to the upstream image it's based on. You could view this as a two-part problem: (1) knowing when an upstream image has been updated, and (2) doing the actual image rebuild. (1) can be solved fairly easily, but (2) depends a lot on your local build environment/practices, so it's probably much harder to create a generalized solution for that.

If you're able to use Docker Hub's automated builds, the whole problem can be solved relatively cleanly using the repository links feature, which lets you trigger a rebuild automatically when a linked repository (probably an upstream one) is updated. You can also configure a webhook to notify you when an automated build occurs. If you want an email or SMS notification, you could connect the webhook to IFTTT Maker. I found the IFTTT user interface to be kind of confusing, but you would configure the Docker webhook to post to https://maker.ifttt.com/trigger/`docker_xyz_image_built`/with/key/`your_key`.

如果你需要在本地构建，你至少可以通过在Docker Hub中创建一个连接到你感兴趣的repo的虚拟repo来解决上游映像更新时收到通知的问题。虚拟回购的唯一目的是在重新构建时触发一个webhook(这意味着它的一个链接回购被更新)。如果你能收到这个webhook，你甚至可以用它来触发你这边的重建。

我回答的前提是:

容器使用标签运行。 相同的标签可以指向不同的图像UUID，因为我们喜欢/觉得合适。 对图像的更新可以提交到新的图像层

方法

首先使用安全补丁更新脚本构建所有容器 为以下内容构建一个自动化流程 使用安全补丁脚本将现有映像运行到新容器 提交对映像的更改为 现有标记->，然后逐个重新启动容器 新版本标签->用新标签替换少数容器->验证->将所有容器移动到新标签

此外，可以升级基本映像/可以定期构建具有完整的新基本映像的容器，这是维护者认为必要的

优势

我们在创建新的安全补丁映像时保留映像的旧版本，因此如果需要，我们可以回滚到以前正在运行的映像 我们保留了docker缓存，从而减少了网络传输(只有被更改的层连接到网络上) 升级过程可以在过渡到产品化之前在阶段中进行验证 这可以是一个受控的过程，因此只有在必要/被认为重要时才可以推送安全补丁。