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

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

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

更新:使用Dependabot - https://dependabot.com/docker/

BLUF:找到正确的插入点来监视容器的更改是一个挑战。如果DockerHub能解决这个问题，那就太好了。(存储库链接已经提到过，但注意在DockerHub上设置它们时-“每当在DockerHub上更新基本映像时，都会在此存储库中触发一个构建。只适用于非官方图片。”)

当我自己尝试解决这个问题时，我看到了几个webhook的建议，所以我想详细说明我使用过的几个解决方案。

Use microbadger.com to track changes in a container and use it's notification webhook feature to trigger an action. I set this up with zapier.com (but you can use any customizable webhook service) to create a new issue in my github repository that uses Alpine as a base image. Pros: You can review the changes reported by microbadger in github before taking action. Cons: Microbadger doesn't let you track a specific tag. Looks like it only tracks 'latest'. Track the RSS feed for git commits to an upstream container. ex. https://github.com/gliderlabs/docker-alpine/commits/rootfs/library-3.8/x86_64. I used zapier.com to monitor this feed and to trigger an automatic build of my container in Travis-CI anytime something is committed. This is a little extreme but you can change the trigger to do other things like open an issue in your git repository for manual intervention. Pros: Closer to an automated pipline. The Travis-CI build just checks to see if your container has issues with whatever was committed to the base image repository. It's up to you if your CI service takes any further action. Cons: Tracking the commit feed isn't perfect. Lots of things get committed to the repository that don't affect the build of the base image. Doesn't take in to account any issues with frequency/number of commits and any API throttling.

我们使用一个脚本来检查正在运行的容器是否以最新映像启动。我们还使用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 pull image:tag
docker-compose -f docker-compose.yml -f production.yml up -d --build

这些命令可以与完成升级所需的任何其他东西一起放在脚本中，尽管一个合适的容器不需要任何额外的东西。

一个简单而伟大的解决方案是牧羊人

One of the ways to do it is to drive this through your CI/CD systems. Once your parent image is built, have something that scans your git repos for images using that parent. If found, you'd then send a pull request to bump to new versions of the image. The pull request, if all tests pass, would be merged and you'd have a new child image based on updated parent. An example of a tool that takes this approach can be found here: https://engineering.salesforce.com/open-sourcing-dockerfile-image-update-6400121c1a75 .

如果你不控制你的父映像，就像你依赖于官方ubuntu映像的情况一样，你可以写一些工具来检测父映像标记或校验和(不是一回事，标记是可变的)的变化，并相应地调用子映像构建。