Docker构建何时使用图像而不是构建

Question

Docker Compose 文档及其示例用例非常适合用于分析不同工作环境(开发,生产等)的各种可能性.

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

db:
  image: postgres:latest

cache:
  image: redis:latest

但是,我不清楚何时使用图像而不是构建.

这是他们唯一的image: example/my_web_app:latest例子:

另一个常见用例是针对Compose应用程序中的一个或多个服务运行adhoc或管理任务.此示例演示如何运行数据库备份.

其他示例案例使用 build: .

我知道,在第一次打开容器时,使用图像而不是构建可以提供更好的性能,因为图像已经是准备好的构建.但是,我可以预见到这样做有很多问题:

• [开发]开发人员可能会更改Dockerfile配置(他们需要在推送任何更改之前以某种方式测试它).
• [开发]源代码文件会改变(但我想你可以通过共享卷来轻松解决这个问题).
• [制作]你可能并不总是希望成为该:latest版本(或者你？).
• [任何]通过使用图像(和:latest标签),您无法控制您正在触摸的文件版本.但是每次你出现docker-compose up它都会更新到最新的工作版本.

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

Answer 1

通常,您希望build .在以下方案中使用:

• 发展
• 自动化测试

这通常在您开发或测试并且代码未生成就绪时完成.例如测试失败,代码无法编译,代码错误等.

通常,只有在准备好部署映像时才会创建映像.此时,您将创建图像,通过其标签将其版本化并将其推送到您的个人DTR或Docker Hub.

使用docker compies中的版本时:latest,您可以指定任何版本,以确保在任何给定环境中运行正确的版本.例如,在生产中,您可能希望创建一个名为compose的compose文件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.你可以阅读更多有关变量替换这里.

组合的强大之处在于,您可以使用由构建系统自动启动的可变替换创建构建文件,不再限制您:latest甚至是硬编码版本.

注意:

1. 团队如何运行他们的构建,发布和部署变化很大,因为他们发现什么最适合他们及他们的产品,所以上述 build .场景可能并不准确适用于所有情况,但对于我的公司如何使用撰写是准确的.
2. 这假设build .在docker-compose上下文而不是docker build上下文中.

Answer 2

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

• 我们不手动构建图像.CI做到了(在我们的案例中是GitLab CI)
• 我们有两种类型的图像,开发/测试和生产.

• 有一个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会构建新dev映像并运行测试.
• CI每次都在同一主机中构建映像,因此可以利用缓存.如果Dockerfile没有更改,则构建只需不到一秒钟.
• 创建新标记时,CI会使用$TAG图像标记构建生产图像.
• 对于生产,我们使用一个orchestrator,而不是Compose YAML.我们不希望存储可以docker-compose.yml在项目存储库中的敏感数据.要进行升级,我们只需从注册表中提取新标签(我们可以自动执行此操作,但我不确定在未经过人工测试的情况下部署到生产中:D).

当然,您每次都可以构建映像进行开发,但是有些项目可能需要很长时间才能构建.例如,Python3 + pandas可能需要25分钟才能构建,因此如果你不得不经常在项目之间切换,那就太令人沮丧了.另一方面,拉图像只需不到一分钟.

我们使用这种方法是因为GitLab为我们提供了CI,注册表和运行者来构建图像和运行测试.没有它你就可以做到,但你需要自己集成所有组件.流程并不完美,它有一些缺点,但在我们的场景中很小.