上一文中讲述了如何在AWS下搭建OpenShift集群。这篇文章将目光转向如何在OpenShift中实现CI/CD以及产品环境的部署。node
持续交付
若是要打造一个持续交付的流水线，首先要考虑多环境的问题。通常一个应用程序会有多个环境，好比开发环境、集成测试环境、系统测试环境、用户验收测试环境、类生产环境、生产环境。如何在OpenShift中隔离并创建对这些环境的部署流程有多种方案能够选择。git
- 同一个project中使用label和惟一名称来区分不一样的环境；
- 集群中的不一样project来隔离环境；
- 跨集群来隔离环境。
咱们以第二种方式为例，演示下多环境管理问题。bash
在上图中，咱们有一个build project。build project包含了一组相互依赖性比较强的应用，每一个应用对应一个build config，产生的Image Stream存放在image register中。而每一个环境各对应一个project，其中包含了该应用的deployment config，其镜像输入是build config产生的Image Stream。之因此这样作，有如下几点考虑：架构
不一样的环境分布在不一样的project中，能够很好的借助project的特性进行环境隔离。好比sys project的容器只能部署在label为sys的node上，prod project的容器只能部署在label为prod的node上。app
不一样的project能够分别定义权限访问和控制。好比只有QA才能操做sys project中的资源，运维工程师才能操做prod project中的资源。运维
不一样的环境共用一个Image Stream，保证了应用程序镜像在不一样环境中的是彻底一致的，防止因为测试环境和生产环境不一致而引入缺陷。工具
那么你们共用同一个Image Stream，如何实现应用的promotion那？解决方案就是使用tag。测试
如上图所示，一个image stream里面有多个版本的镜像，而OpenShift能够为版本添加自定义tag。在不一样的project里面，咱们配置image的来源为”ImageStreamTag”，名称为”applicationName:environmentName”。好比sys project的镜像名为”App1:sys”，prod project的镜像为”App1:prod”。若是想将version 3的镜像推送到sys环境，只须要简单的给version 3的镜像打上sys的tag，这样部署sys环境时就会自动使用version 3的镜像。ui
1
|
oc tag App1:latest App1:sys |
若是在Deployment Config里面配置了自动监听tag的变更的操做，那么一旦你修改了ImageStream的tag，就会自动触发对应环境的部署。spa
因为应用程序镜像在不一样的环境中是一致的，那么变更的部分都被抽取到了外部配置中。如何根据不一样的环境来加载对应的外部配置那？实现方式有不少种，这里介绍了使用Spring Cloud Config的方案。
首先咱们将针对不一样环境的配置放置在一个git仓中，而后经过Spring Cloud Config Server将其转换为http服务。而咱们在应用中嵌入Spring Cloud Config Client，其会接收一个环境变量来拉取指定环境的配置。而该环境变量能够经过Deployment Config来进行注入。
1
|
oc env dc/sys PROFILE=sys |
使用Spring Cloud Config给予了咱们更多的灵活性。咱们能够选择在应用程序第一次启动的时候拉取配置，也能够设置每隔一段时间自动更新配置，从而实现热更新。
OpenShift虽然提供了构建和部署的能力，咱们有时也须要使用Jenkins之类的工具来可视化以及编排整个流水线。
既然OpenShift是个容器化的管理平台，那么咱们彻底也能够将Jenkins做为一个应用归入到OpenShift中来托管，这样Jenkins的Master和Slave都是容器化的。OpenShift官方提供了一个Jenkins2.0的镜像，其预装了OpenShift pipeline插件，能够很方便地进行构建、部署等操做。
生产环境的部署
OpenShift在产品环境的部署默认是rolling的方式。
每次部署时，它会启动一个新的Replica Controller，部署一个pod，而后削减旧的Replica Controller的pod，如此往复，直到旧的Replica Controller中的全部pod都被销毁，新的Replica Controller的全部pod都在线。整个过程保证了服务不宕机以及流量平滑切换，对用户是无感知的。
而有的时候部署场景要负责些，好比咱们想在产品环境对新版本作了充分的PVT（product version testing）才切换到新版本。那么就可使用蓝绿部署的方式。
蓝绿部署方案的关键点在于一个Router对应两个Service。而Route做为向外界暴露的服务端口是不变的，两个Service分别对应咱们的生产蓝环境和生产绿环境。同时只有一个Service能接入Router对外服务，另外一个Service用来进行PVT测试。切换能够简单的修改Router的配置便可。
1 2 3 4 5 |
port: targetPort: app-blue-http to: kind: Service name: app-blue |
结语
OpenShift在应用的构建以及部署方面为咱们提供了大量开箱即用的功能和解决方案,因此实现持续交付再也不那么艰难。咱们能够将更多的精力花费在提高应用程序质量以及架构方面，交付更好的产品。