0penShift是如何支撑持续交付的？

感谢郭经理的专业答复，郭经理将完整的持续交付流程描述的非常清楚。在这里我只补充一点

在另一个问题的答复中我也提到 OpenShift 与大部分主流的开发体系是可以无缝对接的，比如 jira 、Iris、github 、gitlab。 用户可以仍然使用其原有习惯发起统一持续发布任务，能够有效的实现代码的持续集成持续发布的目的。 但在实现持续发布的过程中通常我个人愿意建议企业级用户将实现持续交付的镜像库分为三层。用户只与第一层和第二层镜像库发生自动化关联的持续发布，第三层处于生产区，其持续发布是独立的倾向 Ops 的，而不是 Dev 的。

第一层，是企业级基础镜像库，它将用于存储企业内部所有用于基础构建的的基础镜像，包括通过一些前期沉淀形成的技术型基础镜像，用于帮助企业内部实现基础镜像统一化、安全化、可控化。特别是一些基础的安全防范、安全扫描、漏洞扫补都需要在这一层完善，保障整体企业持续构建的安全可靠。在一些大型企业中，这个基础镜像库可以是去中心化多点同步的，包括在边缘计算场景中，这个基础镜像中心也可以是全国统一同步的。

第二层，是OpenShift内部镜像库，在OpenShift 内是通过 Image Streams组件提供的，它的任务是承载/管理用户在持续构建中不断创建各种版本的业务镜像。这部分能力 OpenShift 已经完全为用户设计好了，在 OpenShift 中它是租户隔离的。可以与基础镜像及产品镜像库自动安全互通的，但是被安全隔离的中间镜像库。

第三层，是真正的产品镜像库，它的任务是承担所有产品化版本的镜像。除了保障镜像的安全、可靠外。它的变更是需要审批的，他的入库是自动化的，通过版本控制统一调度的。因为它将会承担最终面向用户的产品版本镜像。企业将基于这个镜像库来完成最终产品化镜像的发布与回退。因此它的镜像必须具备完整的轨迹管理与审计管理，必须要保留完整的版本序列。保证业务发布时，不同组件间的版本同步性，同步上线或同步回退。

虽然第一层和第三层有时候在物理上可以合一，但逻辑上还是要分开的，因为其中的管理策略会有差异。

如果要打造一个持续交付的流水线，首先要考虑多环境的问题。一般一个应用程序会有多个环境，比如开发环境、集成测试环境、系统测试环境、用户验收测试环境、类生产环境、生产环境。如何在OpenShift中隔离并建立对这些环境的部署流程有多种方案可以选择。

1. 同一个project中使用label和唯一名称来区分不同的环境；
2. 集群中的不同project来隔离环境；
3. 跨集群来隔离环境。
   我们以第二种方式为例，演示下多环境管理问题。
   
   在上图中，我们有一个build project。build project包含了一组相互依赖性比较强的应用，每个应用对应一个build config，产生的Image Stream存放在image register中。而每个环境各对应一个project，其中包含了该应用的deployment config，其镜像输入是build config产生的Image Stream。之所以这样做，有以下几点考虑：
4. 不同的环境分布在不同的project中，可以很好的借助project的特性进行环境隔离。比如sys project的容器只能部署在label为sys的node上，prod project的容器只能部署在label为prod的node上。
5. 不同的project可以分别定义权限访问和控制。比如只有QA才能操作sys project中的资源，运维工程师才能操作prod project中的资源。
6. 不同的环境共用一个Image Stream，保证了应用程序镜像在不同环境中的是完全一致的，防止由于测试环境和生产环境不一致而引入缺陷。