【问题标题】:what are some good strategies for updating docker service images or dockerfile base images更新 docker 服务镜像或 dockerfile 基础镜像有哪些好的策略
【发布时间】:2020-04-08 21:45:51
【问题描述】:

一些 docker 镜像在更新时会重新标记相同的标签。

人们正在采用什么样的策略或方法来确保他们提取更新的基础镜像来提供他们的 Dockerfile FROM 语句或依赖于带有升级(但标签相同)的镜像的服务

我知道 kubernetes 有 pull_policy 语句,但是对于 docker、swarm 或 docker-compose,什么是等效的软选项。

例如,我们使用tiangolo/uwsgi-nginx-flask:python3.6 作为 Flask 应用程序的基础。 这个镜像会不时升级,因此基础操作系统、python、nginx、flask 和其他依赖项都会收到更新,但我们总是使用相同的镜像标签。

docker-compose does not have 在构建期间处理刷新基础镜像的内置方法,因此我们只需在预构建脚本中执行以下操作即可强制拉取新镜像:

find codebase -name "Dockerfile" | while read line; do cat $line | awk '/FROM/ {print $2}' | xargs docker pull

这没关系,但我们没有真正的方法来管理这个更新过程。

有没有更好的办法?

【问题讨论】:

  • 使用 Docker-Compose:container.docker-compose pull && docker-compose up -d 有什么问题?这应该为可变图像标签提取更新的图像并更新受影响的容器。不过,Docker Swarm 可以开箱即用地满足您的需求:每当调度 swarm 服务时,就会从镜像注册表中提取 image:tag。
  • 因为它不会提取我们构建的图像。一些应用程序推送源代码,我们使用 build: context: docker-compose 的选项。如果 From: image:fixed-tag 已更新,我们没有自动跟踪此问题的方法,并且仅提取引用图像的交易,而不是构建。谢谢
  • 我错过了它关于更新指向可变标签的基本图像。似乎没有办法通过隐式 docker-compose 构建来做到这一点。不过,显式构建应该可以让您到达那里:docker-compose build --pull.
  • @Metin 你是对的。我不知道为什么我错过了这个。对此的介绍早于上面链接的问题。正如我们所见,拉取镜像或基础镜像有几种不同的场景,这里没有讨论这个场景。请回答,我会标记它:) github.com/docker/compose/commit/…

标签: docker docker-compose dockerhub


【解决方案1】:

Docker compose 将使用本地映像缓存中的当前映像作为基础映像,除非使用 docker-compose build --pull 显式触发构建。

如果您有一天决定将构建和运行生命周期分开,docker build --pull 提供相同的行为。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-01-22
    • 2017-12-31
    • 2019-07-11
    • 1970-01-01
    • 2020-01-20
    • 1970-01-01
    • 1970-01-01
    • 2020-02-26
    相关资源
    最近更新 更多