【问题标题】:Docker practice for CI/CD and deploymentCI/CD 和部署的 Docker 实践
【发布时间】:2020-04-03 05:40:17
【问题描述】:

我是 Docker 新手,并且阅读了一些关于它的文章。

我读过很多文章说“对所有环境(开发/阶段/生产)使用相同的映像”和“CI/CD 和部署的映像不同”。

但我无法整合这两个建议,我也找不到 dockerfile 示例。

这是否意味着我必须制作以下两个 docker 图像?

(1) image for deployment
- application code and its dependencies
- there is no CMD 

(2) image for CI/CD
- use (1) as base image
- add extra for CI/CD

【问题讨论】:

标签: docker continuous-integration continuous-deployment continuous-delivery


【解决方案1】:

我认为您的困惑来自第 4 节:

部署图像应包含:

  • 缩小/编译形式的应用程序代码及其运行时依赖项。
  • 没有别的。真的没有别的了。

第二类是用于 CI/CD 系统或 开发人员,可能包含:

  • 原始形式的源代码(即未缩小的)
  • 编译器/压缩器/转译器 (等)

虽然许多开发人员认为它很自然,但我认为这不是一个很好的设置,它显示了第一反模式,将容器视为虚拟机。

在我看来,在开发过程中,目标容器应该包含编译器、测试框架等。它应该只包含编译后的代码及其运行时,就像去往的容器一样产品。

所有这些工具都属于一个不同的容器(我们称之为“实用程序”),特别是为了使构建和测试统一和可重复而创建的。该容器已经安装了构建所有容器或其广泛子集(例如所有 Node 和 Python 容器)可能需要的所有工具。您在调用它时挂载您的源目录,它会编译/缩小/打包代码、生成 gRPC 存根、运行测试套件等。

您可以在本地和 CI/CD 中使用相同的实用程序容器。您的构建和测试管道独立于操作系统(在我们公司,开发人员在他们的桌面上运行 Windows、macOS 和 Linux,但对于构​​建后端服务来说没有区别)。您永远不必处理不同“开发”映像之间的编译器版本、测试框架版本、eslint 配置等不同的动物园。

当然,您可以在生产和开发中以不同的方式运行相同的图像和您的编译代码:例如您可以公开端口以附加调试器等。但它是来自容器外部的(轻量级)配置,而不是不同的构建。

所以不,在我看来,您应该在开发、CI/CD 和产品上使用相同的容器。在我为所有容器工作的一家公司中,所有容器都有加密签名,您只能将一个容器升级到 QA / staging / prod,该容器是从特定提交构建并通过测试,并在每次升级时检查签名。当然,将编译器留在这样的容器中是一种失态。

【讨论】:

  • 哇,我明白了。谢谢!
猜你喜欢
  • 1970-01-01
  • 2019-11-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-12-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多