假设我有一个基于ubuntu:latest的普通容器。现在有一个安全更新和ubuntu:latest更新在docker repo。
我如何知道我的本地映像及其容器运行落后? 是否有一些最佳实践来自动更新本地映像和容器来跟踪docker回购更新,这在实践中会给你同样的好处,让无人值守的升级运行在传统的ubuntu机器上
假设我有一个基于ubuntu:latest的普通容器。现在有一个安全更新和ubuntu:latest更新在docker repo。
我如何知道我的本地映像及其容器运行落后? 是否有一些最佳实践来自动更新本地映像和容器来跟踪docker回购更新,这在实践中会给你同样的好处,让无人值守的升级运行在传统的ubuntu机器上
当前回答
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,你甚至可以用它来触发你这边的重建。
其他回答
Docker映像的依赖管理是一个真正的问题。我所在的团队开发了一个名为MicroBadger的工具,通过监视容器图像和检查元数据来帮助解决这个问题。它的功能之一是让你设置一个通知网络钩子,当你感兴趣的图像(例如基本图像)发生变化时,它会被调用。
我回答的前提是:
容器使用标签运行。 相同的标签可以指向不同的图像UUID,因为我们喜欢/觉得合适。 对图像的更新可以提交到新的图像层
方法
首先使用安全补丁更新脚本构建所有容器 为以下内容构建一个自动化流程 使用安全补丁脚本将现有映像运行到新容器 提交对映像的更改为 现有标记->,然后逐个重新启动容器 新版本标签->用新标签替换少数容器->验证->将所有容器移动到新标签
此外,可以升级基本映像/可以定期构建具有完整的新基本映像的容器,这是维护者认为必要的
优势
我们在创建新的安全补丁映像时保留映像的旧版本,因此如果需要,我们可以回滚到以前正在运行的映像 我们保留了docker缓存,从而减少了网络传输(只有被更改的层连接到网络上) 升级过程可以在过渡到产品化之前在阶段中进行验证 这可以是一个受控的过程,因此只有在必要/被认为重要时才可以推送安全补丁。
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映像的情况一样,你可以写一些工具来检测父映像标记或校验和(不是一回事,标记是可变的)的变化,并相应地调用子映像构建。
我们使用一个脚本来检查正在运行的容器是否以最新映像启动。我们还使用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容器的最简单方法
通过$ crontab -e放置作业:
0 * * * * sh ~/.docker/cron.sh
创建目录~/。Docker与文件cron.sh:
#!/bin/sh
if grep -Fqe "Image is up to date" << EOF
`docker pull ubuntu:latest`
EOF
then
echo "no update, just do cleaning"
docker system prune --force
else
echo "newest exist, recompose!"
cd /path/to/your/compose/file
docker-compose down --volumes
docker-compose up -d
fi