我正在使用 Ruby on Rails 进行开发，并开始使用 Docker 进行部署一个月。
以下是我正在处理的步骤。
- 在我的笔记本电脑上开发
- 推送到 gitlab
- 构建包含测试和生产 gem 的单个映像
- 针对此图像运行 rspec
- （通过）推送到注册表，（失败）丢弃图像
通过这个工作流程，我将拥有一个包含所有测试、开发和生产 gem 的图像。
我从与许多人交谈中发现的工作流程
- 我的笔记本电脑上的开发人员
- 推送到 gitlab
- 构建测试映像（测试所需的所有 gem）
- 针对测试图像运行 rspec
- （通过）在没有测试 gem 的情况下构建另一个用于部署的映像并推送到 docker 注册表，（失败）丢弃该映像
使用这种方法，我认为它违反了 Docker 的目的（被测试的图像应该与将要部署的图像无关）。
如何指定和实施测试和推送生产映像的方法？
【问题讨论】：
标签： ruby-on-rails docker
正如Alexei Ledenev 在“Testing Strategies for Docker Containers”中提到的，您的第一种方法有很大的缺点：
- 增加图像大小 - 因为它包含测试工具、所需的包、测试脚本，甚至可能还有测试数据
- 使用特定于测试的配置污染图像运行时环境，甚至可能引入不需要的依赖项（集成测试需要）
- 我们还需要决定如何处理测试结果和日志；如何以及在何处导出它们
另一种方法（接近您提到的第二种方法）是制作“测试感知容器”：
我们认为 Docker 应该让
docker-test成为容器管理生命周期的一部分。如前所述，Docker 有一个非常有用的
ONBUILDinstruction。该指令允许我们在后续构建时触发另一个构建指令。
基本思路是在运行docker-test命令时使用ONBUILD指令。
docker-test命令执行的流程：
docker-test将在应用程序 Dockerfile 中搜索ONBUILD指令，并将……
- 从原始
Dockerfile生成一个临时Dockerfile.test- 使用 docker build 命令支持的附加选项执行
docker build -f Dockerfile.test [OPTIONS] PATH：-test将自动附加到tag选项- 如果构建成功，执行
docker run -v ./tests/results:/var/tests/results [OPTIONS] IMAGE:TAG-test [COMMAND] [ARG...]- 删除
Dockerfile.test文件
（文章继续描述集成测试容器）
【讨论】：