我认为,您指的是不同的Build Strategy Options。而且,在您的问题中,您可能错过了Pipeline Build strategy。
图片来源
假设,您已经开发了一个基本的 NodeJS 后端应用程序。您的目标是快速启动并在 OpenShift 集群中运行。当我说得很快时,我的意思是,不必学习 Docker 知识。在这种情况下,您将使用 S2I。
- 在其中包含一个
start
脚本package.json
以指向node index.js
.
- 将代码提交到 GitHub(或任何其他 Git 存储库)。
oc new-app .
- 完毕。
码头工人
继续基本的 NodeJS 后端示例,您可能会意识到 OpenShift 使用的基本 NodeJS 映像可能不适合您(出于多种原因)。也许,你想使用Docker 官方 NodeJS 镜像。当然,可能还有其他非 NodeJS 原因为您的应用程序构建容器,例如特殊环境变量等。在这里,您将使用Dockerfile
.
来自 Docker Hub 的 Docker 映像
您还可以部署预构建的 Docker 映像。请注意,默认情况下,OpenShift 安全约束不允许您将容器作为root
. 文章链接将此称为此约束的解决方法。
红帽注册表
但是,与前一种情况相同,此部署需要本文所述的机密(需要登录)。
因此,只要您的容器存储库可以以 OpenShift 的“祝福”方式访问,您绝对可以在外部构建映像并将其拉入以进行部署。
二进制
我可以引用为“场景”的最接近的可能是这个问题。否则,也许构建方法是如此的小众,以至于在执行之前最好在“受控”环境中完成。
我的偏好
就我自己而言,我会走这条路。
- 开发人员(包括我自己)需要专注于完成功能 - 所以,使用 S2I。
- 运营团队(包括我自己)需要专注于打包——因此,使用 1 中已开发的功能并将其转换为
Dockerfile
. 或者,甚至是Jenkinsfile
.
- 管理团队(包括我自己)对将图像放到互联网上很敏感——因此,将 Docker 图像推送到私有存储库。
- 如果要为专有的东西完成上述所有操作,请使用二进制构建选项。
希望这可以帮助。