compose 🚀 - 如果镜像存在于本地，docker-compose up 不会下拉最新镜像

docker-compose pull && docker-compose up不切实际的原因是什么？

shin- 于 2016-06-10

👍42 👎21 😕3

我认为支持/反对的大多数观点与问题中讨论的将--pull到docker run的观点相同。它们的范围从用户体验和一致性，到简化脚本/工作流程，再到群集成（出于好奇， docker-compose pull对群做了什么？）。
我不认为这是一个主要问题，但需要考虑。在其他地方需要该功能的同一类型用户也可能会在这里享受它。

kag0 于 2016-06-10

👍4

我正在尝试执行“docker-compose build”，但它不会刷新 Dockerfile 中引用的图像，除非您使用 _--pull_。

您还可以在开始时使用 _up --build_ 构建容器。但不会拉取最新的图像。我们可以期待像“docker-compose up --build --pull”（或类似的）这样的东西吗？也许将它放在 YML 中是有意义的，因为并非所有构建都必须刷新（参见本地图像）。

decoomanj 于 2016-06-30

除了（或另外）将 --pull 添加到 cli 之外，在 docker-compose 文件中的服务定义上添加一些内容怎么样？，例如

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

这样，如果有一项我不在乎的服务是最新的，而我却在乎，那么 docker-compose 就不会浪费时间下载我不感兴趣的图像

cressie176 于 2016-10-11

👍203 ❤47

我来这里是为了寻找这个功能，因为我们在 Kubernetes 的生产集群中使用它。标签是“imagePullPolicy”，它可以设置为“IfNotPresent”、“Always”或“Never”。类似于 compose 环境的东西会很好。

blockloop 于 2017-02-13

👍47

在我们的例子中，我们需要每天重建基础镜像，以确保为应用程序更新最新的依赖项。 Docker 组合以拉取具有相同标签的最新镜像是一个不错的功能。为什么不！

PengBAI 于 2017-03-03

有这方面的消息吗？

marcelovcpereira 于 2017-03-22

👍6 👎1

你好，

有关于这个问题的消息吗？

sugun999 于 2017-05-12

👎1

+1

jonathan-kosgei 于 2017-05-14

👎24 👍1

+1

ivytribe 于 2017-05-23

👎23 👍1

正如我之前提到的， docker-compose pull && docker-compose up在功能上是相同的。没有充分的理由为其添加另一个标志。

shin- 于 2017-05-23

👎155 👍3 😕2 😄2

想象一下 git 没有pull因为git fetch && git merge origin/master在功能上是相同的。

blockloop 于 2017-05-23

👍178 😄79

例如，如果您在撰写文件中使用的某些图像位于缓存中，则添加pull: true标签可能很有用。 docker-compose pull提取 _all_ 撰写文件中的图像，如果这些图像在您的缓存中但不在存储库中，则该拉取将失败。

telly23 于 2017-06-08

👍36

+1

fulllove890 于 2017-06-12

👎27 😄1

docker-compose pull && docker-compose up变得不切实际的一种情况是当您使用多个 docker-compose 文件时。你可以很容易地得到像docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up这样的命令。

JustinLivi 于 2017-06-23

👍34

我们有一个在本地开发的场景，我们只想从远程拉取一些图像。本地开发的一个（或多个）应该保持不变。在这种情况下，我们有义务在运行 docker-compose up 之前手动构建/拉取图像。
pull: true将是有益的。

xellsys 于 2017-07-12

👍12

@shin-重新考虑您对此的决定怎么样？我相信对它们的评论和反应看起来已经足够自我描述了。

lig 于 2017-07-25

👍1

不，我很好。这是一个开源项目，如果您不同意我们在添加功能时采取的保守方法，欢迎您fork。

shin- 于 2017-07-25

👎163 😕55 👍16

同意向docker-compose up命令添加标志或向配置添加参数。我们使用带有附加配置的基本映像，这些配置在开发过程中往往会经常更改。我们想要创建一个万无一失的环境，开发人员可以在其中简单地运行 docker-compose up，而无需调试他们不需要调试的内容。

在我的同事检查我的拉取请求并说它破坏了构建之后，我实际上点击了这个线程。原因是基础镜像只是缺少几个包 - 但在最终的 Dockerfile 中得到了执行。这将是一个很好的功能，但显然不是你用过的东西，@shin-。

如果您在新版本中引入此功能，我们会很高兴。

alwye 于 2017-10-06

👍1

@ shin-我认为git示例中展示了 pull 选项是多么方便/有用。老实说，我希望这样的事情不需要分叉任何项目。

我完全理解保守的方法，但感觉它甚至不再被视为一种选择。也许它可以成为即将推出的版本的一部分？

kgalli 于 2017-10-19

👍5

pull: IfNotPresent会很好。所以有可能使用回退，比如
1）使用本地图像
2）如果不是本地拉
3）如果无法拉动，则构建

pwFoo 于 2017-10-30

👍1

@shin-你一直在问为什么 && 方法不会削减它的原因，我的原因是这个。我将它用于“应用程序”图像进行测试（Puppet PDK/Onceover）。撰写文件是模板 repo 的一部分，因此当 puppet 开发人员（真正的操作人员）需要创建一个新模块时，他们会分叉该 repo。 Jenkins 在该模块存储库上运行图像以进行合并验证（在内部我们有一个 jenkins 插件来处理作业的更新。）现在使用它的人不会是 docker 专家，并且不得不告诉他们执行 && 是额外的他们可以（并且可能会）搞砸的步骤。我不明白为什么它会很困难或它会造成什么劣势，但这种推理似乎是一个值得添加它的理由。它可以帮助我们开发人员发送需要较少指导和步骤的东西。

缺点是......防止懒惰

jrich523 于 2017-11-17

👍2

这是更好的理由： &&是同步的。但是 docker-compose 内置了对并行执行器的强大支持，可以优化这些东西。 docker-compose up --pull --build可以开始构建镜像并在拉取后立即运行，而不是等待所有镜像拉取后才开始构建

ostrolucky 于 2017-11-29

👍24 ❤9

@shin假设自己很少使用更新 Dockerfiles。
但是如果你每天更新一个开发人员会用到的 Docker 镜像，如果只是一个开发人员忘记拉他每天必须做的镜像（尤其是那些不太熟悉 docker 的人，那就是实际上不是他们知道和记住它的事）。灾难计划。
将此选项添加到 docker-compose.yml 是一个大问题吗？
我的意思是，它不会改变其他东西，它只是增加了功能。 ..

这是我不能使用 docker-compose 并且需要使用旧版 docker run 命令编写包装脚本的致命原因，但这很丑陋。

sgohl 于 2017-12-04

❤7 👍5

试图弄清楚这张票被关闭的情况 - 有人可以详细说明吗？如果有任何帮助，我很赞成在docker-compose up添加一个--pull标志。

themanifold 于 2018-02-27

👍2

我认为这里有两个提案正在讨论：

1 - 是否应该将其添加为命令行选项？实际上发布的问题。
2 - 是否应将此选项添加到 YML 文件中。

我绝对同意后者，尽管@shin实际上并没有对此发表评论。用相同的论点驳回它，即它在功能上相同将是不连贯的。 YML 文件中的所有内容在功能上都与命令行相同。

我可以看到他关于前者的观点，但我认为理由有点过于宽泛。通过将一系列语句与&&链接在一起，我可以在命令行上做任何事情。让我们明确一点，这是两个命令，而不是一个。标准应该是：是否有足够的需求来做到一步而不是两步？因为如果它使用得足够频繁，链接命令的数量就会不断增长。关键是，当您编写脚本时，您希望它尽可能简洁。

orodbhen 于 2018-03-12

👍3

@orodbhen无需争论。这里没有人听我们说话。

lig 于 2018-03-13

😕2

再加上添加标志的理由……在过去一年左右的时间里，我发现自己正在寻找这个东西，但到了这里却发现我已经点赞了几条评论，支持--pull标志。我想我下次也会再次在这里找到自己。

pho3nixf1re 于 2018-03-17

@shin-，请重新打开或锁定此问题。它已开放近两年，不断收到评论（既有智慧又有趣）、数十名参与者和数百张选票。
但是，很明显，撰写团队对追求此功能不感兴趣。因此，让我们不要浪费任何人的时间，也不要寄希望于如果事实并非如此，该问题将再次出现。

kag0 于 2018-03-19

👍9 😕2

请不要使用脏话。

shin- 于 2018-03-22

👎1

虽然我确实认为最初的请求很有用，但这个帖子中的很多人似乎忘记了开源的精神：如果它对你那么重要，你可以自由地 fork 和修改你的内心内容。我知道您可能不想维护分叉，但抱怨维护者不会实现功能会适得其反：这不是功能实现的方式，并且会使维护者希望帮助您减少。

对某项功能的需求并不重要，特别是如果没有人付费使用该产品。除了将每个人都想要的每个功能融入主要产品之外，还有更多需要考虑的事情。我们应该尊重@shin- 对此的回应，并相信有充分的理由不实施它。

bdharrington7 于 2018-03-22

@lig不想争论。只是在做案子。

根据您的需要，分叉可能有点矫枉过正。在我的特殊情况下，我发现 Compose 不太适合脚本编写，除非它是一个非常基本的脚本。使用 Docker Python API 和我自己的 YAML 文件来保存设置更通用，而且通常更简单。

orodbhen 于 2018-03-22

@bdharrington7——但你必须维护你的 fork 并将它安装在你使用的所有机器上（这是很少可能的）。需要注意的是 Docker Compose 很受欢迎，其他人会说：“谁在乎？”

er1z 于 2018-03-23

现实情况是，“它是开源的，创建自己的分支”的评论是不现实的。维护自己的分叉并使其与主存储库中的最新更改保持同步的开销使其几乎不值得投资。更好的方法是向维护者请愿，并提供适当的理由来说明为什么该功能很重要。

可悲的是，这总是会导致一些不满的问题。我认为这里的主要问题是似乎没有提出适当的案例来说明为什么这是一个坏主意。论据

“我们应该尊重@shin- 对此的回应，并相信有充分的理由不实施它。”

只是不会满足人们。社区需要看到“好的理由”。

gregpakes 于 2018-03-23

👍14

重点仍然是，用拳头和乞讨很少会导致
在得到你想要的东西时，很多都发生在这个线程中。
线程中也提出了很多好的用例，
但除非你真的为软件付费，否则没有义务
从维护者那里做任何事情，也不给出任何理由。我是
只是给@shin- 和公司带来怀疑的好处。
在周六，2018年3月24日在上午05时39分格雷格Pakes [email protected]写道：

现实是评论“它是开源的，创建你自己的分支”，
只是不现实。维护自己的叉子和
使其与主存储库中的最新更改保持同步
使得它很少值得投资。更好的方法是请愿
维护者并提供适当的理由说明为什么该功能
重要的。
可悲的是，这总是会导致像这样的问题
不满意。我认为这里的主要问题是似乎没有
已经提出了一个适当的案例来说明为什么这是一个坏主意。这
论点“我们应该尊重@shin- http:///shin-对此的回应，
并相信有充分的理由不实施它。” 只是不是
去满足人们。社区需要看到“好的理由”。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

bdharrington7 于 2018-03-24

重点仍然是，用拳头和乞讨很少会得到你想要的

这不是真的。虽然我不认为这是一种要求免费工作的策略，但它实际上非常有效。这正是请愿书的运作方式，“捶打拳头”的人越多，重要的人就越有可能注意到这一点。 再说一次，我不是说我同意它

线程中也提出了很多好的用例

我可以看到一种情况，它基本上归结为“您可以改为执行这两个命令”。但显然人们不想要它。因此，让他们参与并教育他们为什么这是一项好的工作。

维护者没有义务对此做任何事情，也没有给出任何理由

我同意。但是你必须期望人们对此感到沮丧。这是一种不屑一顾的态度。归根结底，这里的每个人都在同一个团队中。维护项目的人和项目的用户都只希望项目成功。

gregpakes 于 2018-03-24

哪个产品在这里是免费的？如果我使用 docker-compose.exe 并运行 docker EE，这是否真的意味着我实际上是在为产品付费？

artisticcheese 于 2018-03-24

👍2

恕我直言--build应该拉；不需要任何其他标志或配置。如果您不想拉动它，请指定图像版本。

ET-CS 于 2018-04-04

👍3

@ET-CS：图像版本只是标签，仍然可以更改为不同的哈希

lifeofguenter 于 2018-04-05

好点@lifeofguenter谢谢。可以撰写检查图像是否更改为不同的哈希并在这种情况下拉取？

在这样的场景中，我想我希望所有环境（开发，生产）都具有相同的图像，因为开发人员正在使用新的哈希，而生产使用旧的。

我希望--build将所有内容更新到最新。

ET-CS 于 2018-04-18

👍6

所以，这是一个很好的用例：

我为我的微服务项目实现了一个 CI，当我们在后端服务中开发新功能时，它会将新图像拉入注册表。前端团队（对 docker 知之甚少）需要有一种方法在他们的本地机器上调出整个后端堆栈，并且他们依赖于最新的镜像。如果有什么东西坏了，只有这样他们才会记得拉图像。

现在是这样：整个开发冲刺失败了，因为有人忘记更新后端图像，并基于旧版本开发了整个功能。归咎于前端团队，但可以通过此功能避免这种情况（我将使用包装器脚本进行此操作）。

agnjunio 于 2018-05-23

@agnjunio这听起来很不幸，对不起。但是，如果此人忘记运行docker-compose pull ，我不确定他们忘记使用假设的--pull标志的可能性会降低吗？

shin- 于 2018-05-23

@shin-抱歉，我忘了提及一件重要的事情：在我的情况下，解决方案是在 yaml 中添加pull: always标签，也许在image:选项中

agnjunio 于 2018-05-23

@ET-CS 来自https://github.com/docker/compose/issues/3574#issuecomment -382451356：

我希望 --build 将所有内容都更新到最新。

恕我直言 --build 应该拉；不需要任何其他标志或配置。如果您不想拉动它，请指定图像版本。

AFAIK 会通过使用depends_on构建结果的 FROM 进行构建来阻止用例。

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

我赞成https://github.com/docker/compose/issues/3574#issuecomment -252861859 和https://github.com/docker/compose/issues/3574#issuecomment -279460839 中建议的标志

solsson 于 2018-05-25

@solsson
我不确定我明白为什么或在这个用例中阻塞了什么。
如果可以，请分享更多相关信息。

ET-CS 于 2018-05-25

@shin- 这里的不同之处在于，如果我运行docker-compose up --help我将收到关于如何使用 :latest 图像的描述性方式，而现在我必须在文档或谷歌中搜索引导我这个线程，我需要阅读所有评论才能理解docker-compose up没有做我需要/想要的，所以现在我需要运行两个命令。

@agnjunio这听起来很不幸，对不起。但是，如果此人忘记运行 docker-compose pull，我不确定他们忘记使用假设的 --pull 标志的可能性会降低吗？

亲切地

ruanltbg 于 2018-05-30

我们使用 docker-compose 的主要原因之一是能够将docker-compose.yaml文件放入存储库，并在开发人员拉取存储库并运行docker-compose up [service]时具有可重现的输出。

我们在 docker-compose 文件中使用了多个服务，这些服务执行诸如运行 codegen 和运行工具以将 JSON 模式取消引用到单个文件中的任务。
确保这些工具是最新的至关重要，尤其是当我们更新我们的代码生成映像以修复所有项目中出现的一些常见关键问题时。

具有放置能力：

services:
  codegen:
    image: myimage:latest
    pull: Always

将保留我们让开发人员可靠地运行 docker-compose up 并获得预期结果的能力，而不是必须用文档补充每个存储库以提醒开发人员在启动应用程序之前运行一系列命令或脚本以提取最新的可用图像.

这不是关于“通过运行这些命令来执行此操作的功能已经存在”，而是更好的用户体验。

想象一下，当有人建议将--stop到docker-compose rm ，答案是“ docker-compose stop myapp && docker-compose rm myapp有什么问题，或者如果有人要求实现docker-compose down他们只是问为什么docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ...不切实际？

ahannigan 于 2018-06-01

👍18

这个帖子是 2 年前提出的，我仍然认为在 docker-compose.yml 中添加一个标志是最好的方法。就我而言，我们在一个集群中有 37 个服务，从总数中更新 4-5 个图像并不容易。我现在刚刚创建了一个 shell，它可以监视存储库中的更改，并在重新创建服务（如果已更新）之前对特定图像进行拉取。

jbauson 于 2018-06-30

这里的另一点是docker-compose up有一个--quiet-pull选项。当我第一次试图弄清楚up包含拉力时，我认为它确实是基于它的存在。不使用--quiet-pull导致冗长的拉取是有原因的。

jrynyt 于 2018-07-10

👍3

两年来，人们试图说服 Docker Compose 维护者，拥有 --pull 选项将是一种更好的体验，而无需运行单独的命令。如果 docker-compose 维护者刚刚实现了该功能，首先，每个人的生活都会变得更好。很明显，当前的维护者不想为了社区的改善而添加此功能。

也许我们应该只 fork docker-compose 并自己更新它。

eaglet3d 于 2018-07-20

👍6

如果有人提交 PR，如果被接受是否有机会？
这是开源的。我已经接近考虑实施它一些
次我自己。我认为它可以被接受，否则这个角色将被关闭，
对？

bean5 于 2018-07-20

👍1

我遇到了同样的问题和废话，这里有一群抱怨者。这是免费的开源软件。让维护者休息一下。我相信他们有比这更重要的事情要做。如果有人非常需要这个，你为什么不开一个 PR？如果代码干净且风险最小，我不明白他们为什么不接受它。

ktravelet 于 2018-07-27

👎16 😕2

由于讨论缺乏不执行此请求的充分理由，因此应重新打开此问题。人们更有可能开始处理 _open_ 问题而不是封闭的问题。

dvdgsng 于 2018-08-07

这个“封闭”问题仍然如此活跃的事实确实表明它没有得到很好的处理。

不幸的是，我发现对某些 GitHub 存储库上发布的帖子的回复不是很有帮助。语气通常很简洁，表明反馈不受欢迎。

有些人在这里指出这是一个开源项目，并且（至少我们大多数人）不是付费客户。但是，还值得注意的是，提交问题报告需要花费大量时间，如果您参与了问题的解决，则更是如此。

用户或开发人员在花时间解决问题并找到解决方法后，将决定是否要花更多时间来报告问题。维护者不接受的回应可能会导致他们下次选择不打扰。

在“免费啤酒”的意义上，该软件并不是真正的“免费”。因为我们都在努力参与使其变得更好。让人们愿意测试您的软件并提供反馈是一种宝贵的资源。那些具备必要编程技能的人甚至愿意贡献代码，但他们希望在花时间投入代码之前，得到某种表明他们的贡献受到欢迎的迹象。

显然，仅仅抱怨一个问题并要求它被修复的评论是没有用的，但大多数人并没有这样做，并且像“它是开源的，只是分叉它”之类的评论同样无用。

orodbhen 于 2018-08-07

👍23

@shin- 为什么实施“--build”？它与 docker-compose build && docker-compose up 不同吗？只是试图理解 --build （已添加）和 --pull （已被认为是多余的）之间的哲学差异。理解思考过程可能会帮助我记住事情是如何运作的。如果问题被打开，我很乐意提交 PR。 @everybodyelse...如果你不喜欢你分叉的东西，这真的是“开源精神”吗？我认为开源的精神是“如果你不喜欢某样东西，你 a) 帮助满足你的需求，b) 如果可以，帮助贡献代码”，并且只有在你的需求非常高的情况下才分叉显然只有你才能从中受益。即我认为当我们分享时我们受益最大 - 但我很高兴在这里接受教育。