Docker Compose documentation ，及其 example use case很高兴弄清楚您必须拆分不同的工作环境(开发、生产等)的各种可能性。

web: 
  image: example/my_web_app:latest 
  links: 
    - db 
    - cache 
 
db: 
  image: postgres:latest 
 
cache: 
  image: redis:latest 

但是，我不太清楚何时使用图像而不是构建。

这是唯一与他们唯一的 image: example/my_web_app:latest 相匹配的描述。例子:

Another common use case is running adhoc or administrative tasks against one or more services in a Compose app. This example demonstrates running a database backup.

其余的示例案例使用 build: .
我知道在第一次打开容器时使用图像而不是构建可以为您提供更好的性能，因为图像已经准备好构建。但是，我可以预见这样做的许多问题:

[开发] 开发人员可能会更改 Dockerfile 配置(并且他们需要在推送任何更改之前以某种方式对其进行测试)。

[开发] 源代码文件会改变(但我想你可以通过共享卷轻松解决这个问题)。

[生产] 您可能并不总是想在 :latest版本(或者你呢？)。

[any] 通过使用图像(和 :latest 标签)，您无法控制所接触的文件版本。而是每次出现时docker-compose up它将更新到最新的工作版本。

前面的一些观点可能并不完全正确。随意拆除它们。

请您参考如下方法:

通常你会想要使用 build .在以下场景中:

发展

自动化测试

这通常在您进行开发或测试并且代码尚未准备好用于生产时完成。例如测试失败，代码无法编译，代码错误等。

通常，您只会在准备好发布以进行部署时创建镜像。届时，您将创建镜像，通过其标签对其进行版本升级，并将其推送到您的个人 DTR 或 Docker Hub。

在 docker compose 中使用版本时，您不受 :latest 的约束。 ，您可以指定要确保在任何给定环境中运行正确版本的任何版本。例如，在生产环境中，您可能希望创建一个名为 docker-production.yaml 的撰写文件。配置如下:

web: 
  image: "example/my_web_app:${TAG}" 
  links: 
    - db 
    - cache 
db: 
  image: postgres:9.5.2 
cache: 
  image: redis:3.0.7 

哪里 ${TAG}是在运行时替换的环境变量，例如 docker-compose up -d -f docker-production.yaml .您可以阅读有关变量替换的更多信息 here .

compose 的强大之处在于，您可以使用构建系统自动启动的变量替代来创建构建文件，而不再局限于 :latest甚至是硬编码版本。

笔记:

团队运行构建、交付、部署的方式因他们而异
找出最适合他们和他们的产品的方法build .情景可能并非对所有情况都准确，但
准确了解我公司如何使用 compose。

这假设 build .在 docker-compose context而不是 docker build语境。