资源类型拓展

我们添加了OpenShift类型的部署资源，资源拥有和介质完全独立互斥的属性，他描述了我们的介质（镜像）需要部署到哪个环境（容器云），部署到该容器云的哪一个命名空间中去，资源还描述了访问容器云所需要的其他信息如用户名密码或者APIToken以及容器云服务器的证书等信息。

部署原子任务拓展

DevOps具有强大的拓展能力，可以通过在数据库添加OpenShift部署任务的原子任务以及原子任务的属性参数进行拓展，例如：镜像的名称及镜像版本、部署使用的yaml或者yaml模板、部署用到的OpenShift资源，拉取镜像所用的镜像仓库等。

这种方式有什么好处？

DevOps流水线设计的优势显而易见，CICD可以减少大量开发、测试、部署过程中的重复性工作，同时减少了手工的错误，大大提高了功能验证的频率。开发测试人员能够更早的获取变更，更早的进入测试，更早的发现问题，缩短了开发周期，极大的降低了解决问题的成本。在这个过程中，开发人员能够更早发现错误，并且减少解决错误所需的工作量，如果在部署环节发现错误可以回退到上一版本，保证交付物始终有一个可用的版本。

OpenShift Client插件介绍以及排坑

我们用到了Jenkins Plugin中的OpenShift Client用于对OpenShift进行操作，这个插件拥有简洁、全面、可读性强的特点，并且提供了流畅的Jenkins Pipeline语法与OpenShift服务器进行交互，接下来我将对使用这个插件遇到的一些问题进行排坑。

该插件利用了OpenShift命令行工具（oc），该脚本必须在执行脚本的节点上可用，所以要求我们的Jenkins Master和Node节点安装oc命令，并且配置环境变量，同时还要保证打通到我们要管理的OpenShift的网络。

插件要求我们配置OpenShift的证书和ApiToken，证书我们可以直接从OpenShift服务器的安装目录／etc／origin／master／ca．crt拷贝。关于ApiToken的获取，我总结了以下两种方式：

1．通过命令行 oc login －u －poc whoami －t2．通过命令行curl －u admin：abc123 －kv －H ＂X－CSRF－Token： xxx＂ ＇https：／／master．example．com：8443／oauth／authorize？client＿id＝OpenShift－challenging－client＆response＿type＝token＇从返回的Response Header中获取。

从插件的使用上来说，他的Groovy语法糖非常契合OpenShift命令行的使用习惯，学习难度很低，因此熟悉kubectl或者oc命令的运维人员能够在很短时间内掌握。

例如以下三行命令：oc create －f templateYaml  oc describe deploymentconfig test－demooc scale deploymentconfig test－demo －－replicas＝5
可以简单写成

应用容器的部署、升级、停止、扩容操作都可以用简明清晰的语法操作，以下是代码示例：

镜像部署到OpenShift之后， DevOps会自动创建好对应的应用，同时，通过Jenkins回调DevOps返回的数据，我们可以获取应用的一些基础信息。可是对于应用的监控和运维来说，这些信息不够有效，于是我们封装了OpenShift提供的RestApi，提供了OpenShift应用运维常用的几个接口。

当我们通过DevOps将构建好的镜像成功部署到OpenShift之后，只做到这一步是远远不够的，从某种方面来说，我们还没有完全解放运维人员的压力，对于应用部署之后漫长的运维周期，运维人员为了解决应用问题仍然需要面对黑白相间的linux控制台以及敲入各种复杂的命令。