OpenShift是什么？

OpenShift是一个基于主流的容器技术Docker和Kubernetes构建的云平台，OpenShift底层以docker作为容器引擎驱动，以Kubernetes作为容器编排引擎组件，同时，OpenShift提供了开发语言、中间件、自动化流程工具及界面等元素，提供了一套完整的基于容器的应用云平台。
你可以简单的把OpenShift理解为Kubernetes PRO PLUS所以我们如果可以对接了OpenShift，那么也就相当于对接了Kubernetes。

为什么需要通过DevOps来管理OpenShift？

为了确保业务应用在测试环境预发环境生产环境表现的一致性，我们使用了一系列容器相关的工具，这些工具能够帮助我们减少上线时因为介质、环境等不一致带来的问题，可是随着这些工具的深入使用，我们也会希望能够进一步抽象，不论我们的业务应用是部署在云主机还是容器云上，我们都希望能使用同一种方式来进行部署，我们也希望能够进一步简化操作，真正实现一键部署，切实地提高生产效率和质量。

DevOps的核心价值就在于通过打通各个工具链来提高企业生产的效率以及质量，告别终日面对黑白相间的Linux界面，友好的可视化界面能几何倍数提升运维的操作体验；不再因为部署环境发愁，一套DevOps就可以轻松管理多个环境；也不用被繁多的配置文件打乱思绪，我们可以通过大量的模板进行足够灵活的自定义配置。

以上是DevOps实施时的系统架构部署图。通常我们的部署都会分为开发环境、测试环境、生产环境这样不同的部署区，这些不同部署区之间的资源都是相互隔离的，保证不会对彼此产生影响。

在我们的开发测试流水线中，首先，由开发人员提交代码，触发持续集成流水线，构建服务器会自动拉取代码、对代码进行质量扫描，然后编译产物，最后将产物上传到介质仓库。我们支持配置介质仓库的同步策略，如不同环境的介质仓库定时同步、定时推送或者拉取，这样能够保证不同环境部署介质的一致性。对于镜像来说，镜像也是部署介质的一种类型，镜像在完成构建和上传之后，也支持同步到不同环境的镜像仓库。当触发持续部署流程时，部署服务器将介质部署到应用部署机或者容器云环境，对于应用部署机来说，介质从介质仓库服务器获取，对于容器云来说，镜像来源于镜像仓库。

我们是如何进行设计和落地的？

我们进行持续集成与持续部署的总体设计思路是，在DevOps中进行设计，然后通过Jenkins执行，最后通过OpenShift进行部署。我们在DevOps中定义多个原子任务串成流水线，之后进行构建定义或部署架构的设计，生成Jenkins的Pipeline Job的配置文件；然后Jenkins根据这个动态生成的配置文件创建并执行Pipeline Job；在部署完成后，DevOps通过调用Jenkins的Rest API跟踪执行进度和结果，通过OpenShift的Rest API获取应用容器的实例状态以及对应用容器进行运维操作。

镜像构建和上传

在部署之前，我们需要准备好介质，DevOps提供了一系列任务能够帮助我们轻松完成镜像的构建和上传，对于Kubernetes和OpenShift来说，部署介质就是镜像，这意味着，无论是部署到Kubernetes还是部署到OpenShift，只要我们打通到镜像仓库的网络，就可以兼容不同类型的容器云。

DevOps提供了多种镜像构建任务，支持通过指定一个基础镜像进行构建，也支持通过DockerFile进行构建，使用方式上非常灵活。通常来说，企业都会在内网环境搭建私有镜像仓库，在构建之后，我们需要把镜像push到已授信的镜像仓库。

组件类型拓展

我们添加了OpenShift类型的组件进行扩展，组件是部署的最小单元，其中包含了部署介质的各种信息，向前可以对生产介质的代码、分支、构建流水号进行追溯，向后可以对部署之后的应用以及应用状态变更如升级、回滚等操作进行跟踪。组件还包含了它在各个环境中的部署信息以及实例的运行情况如访问地址、运行状态等。