docker - Docker撰写何时在构建中使用镜像

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示例附带的唯一描述:



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

[development]开发人员可能会更改Dockerfile的配置(在进行任何更改之前，他们需要进行某种方式的测试)。

[development]源代码文件将更改(但是我想您可以通过共享卷来轻松解决此问题)。

[生产]您可能并不总是希望使用:latest版本(或者，是吗？)。

[any]通过使用图像(和:latest标记)，您无法控制要触摸的文件版本。但是，每次您打开docker-compose up时，它将更新为最新的工作版本。

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

最佳答案

通常，您将在以下情况下使用build .:

开发

自动化测试

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

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

在docker compose中使用版本时，您无需绑定(bind)到: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 .场景可能并非在所有情况下都准确，但是
准确地了解我的公司使用组合的方式。

这假定build .在docker-compose context中，而不是dockerbuild上下文中。

关于docker - Docker撰写何时在构建中使用镜像，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/42170124/