Docker撰写何时使用图像构建

Question

Docker撰写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: .

据我所知，有超过建筑图像时开启首次容器起来的时候，因为图像已经准备建立为您提供更好的性能。但是，我可以预见许多问题：

• [开发]开发人员可能会更改Dockerfile配置（并且在推送任何更改之前需要先进行测试）。
• [开发]源代码文件将改变（但我想你可以通过共享卷容易修复）。
• [制作]你可能并不总是想要在:latest版本（或者你是否？）。
• [any]通过使用图像（和:latest标签），您无法控制您正在触摸的文件版本。但是每当你打开docker-compose up它就会更新到最新的工作版本。

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

Answer 1

通常你想使用build .在下列情况：

• 发展
• 自动化测试

这是正常进行，当你正在开发或测试和代码不生产准备。例如测试失败，代码不能编译，编码错误等。

通常情况下，您只会在准备运送部署时创建图像。此时，您将创建该映像，并通过其标记对其进行版本升级，并将其推送到您的个人DTR或Docker Hub。

当使用docker中的版本进行组合时，您不会绑定到: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。

撰写的力量是，您可以创建具有可变替代项的构建文件，由您的构建系统自动启动，不再将其限制为:latest甚至是硬编码版本。

注：

1. 如何团队运行他们的制造，运输，部署差别很大，因为他们 找出最适合他们和他们的产品，因此上述 build .场景对于所有的情况可能不准确，但是对于我的公司如何使用撰写文章准确的是 。
2. 这假设build .在docker-compose context而不是docker build上下文。

Answer 2

正如@ GHETTO.CHiLD所说，这取决于您的需求和您的工作流程。其实我们不执行手动构建。我将解释我们如何管理这个以及为什么。它完全符合我们的流程，但不适用于其他情况。

• 我们不会手动生成图像。我们有CI（）
• 我们有2种类型的图像，开发/测试和生产。

• 有一个docker-compose.yml用于开发，可以简化环境管理。他们只运行docker-compose up，它从注册表中获取映像并将其挂载到容器中。

  version: "2" 
  
  services: 
      web: 
      build: 
       context: ../../ 
       dockerfile: dockerfiles/dev/Dockerfile 
      image: registry.my.domain/my_image:dev 
      volumes: 
       - ../../:/opt/app 
      working_dir: /opt/app 
  

• 如果他们做了更改Dockerfile（例如，他们需要一个新的图书馆），他们可以建立自己的机器（docker-compose build）的图像，但图像不是针对注册表推动。

• 当他们很高兴时，他们推送新的代码（其中包括Dockerfile），CI将构建新的图像并运行测试。
• CI每次都在同一主机中构建图像，因此它可以利用缓存。如果Dockerfile没有更改，则构建不到一秒钟。
• 当创建新标签时，CI使用$TAG作为图像标签构建生产图像。
• 对于生产，我们使用orchestrator，而不是一个Compose YAML。我们不希望在项目存储库中存储可能在docker-compose.yml中的敏感数据。要进行升级，我们只需从注册表中提取新标签（我们可以自动执行此操作，但是我还没有信心在未进行人为测试之前部署到生产环境中：D）。

当然，您可以在每次开发时创建图像，但有些项目可能需要很长时间才能构建。例如，Python3 + pandas可能需要25分钟才能构建，所以如果经常需要在项目之间进行切换，这会让人感到沮丧。另一方面，拉一张图片不到一分钟。

我们使用这种方法，因为GitLab给我们的CI，书记官处和选手建立图像和运行测试。你可以不用它，但你需要自己集成所有组件。流程并不完美，但有一些缺点，但在我们的场景中很小。