世上高手大约有两种：
第一种，一辈子纵横江湖数十载，所学武功实用有效，招数简明而力道雄厚，善于“简单粗暴”迅速解决问题。在TA心中：能用黑虎掏心解决的问题，干啥非要耍一套袈裟伏魔功？能用虚拟化RHV/vSphere解决的问题，凭啥上OpenStack？vLAN能解决的问题，上啥SDN？
另一种所练武艺精妙无比，招数变化层出不穷，出招变化莫测，随着对武功理解的深入，渐入以无招胜有招的境界，加以深厚的内力，使将出来，天下无敌。这是什么武功？大名鼎鼎的OpenShift。
OpenShift最核心的内功心法
OpenShift到底是个啥？
从架构角度，用一句话来形容OpenShift，那它就是企业版的Kuberrnetes
从功能角度，用一句话来说OpenShift，那它就是下一代应用承载平台
从面向对象角度，用一句话来说OpenShift，那它是“同时面向运维和开发的企业级PaaS平台“。面向运维体现的是容器云，面向开发体现的是DevOps
Gartner说，容器的四大应用场景主要有：DevOps、PaaS、微服务、批量运算。在这四种场景里面，笔者至少看到了OpenShift在前三个场景中的真实实用案例。
接下来我们先看OpenShift各个组件的功能：
OpenShift内部几大组件： Master节点、Node节点、RoutingLayer、Service Layer、持久存储、Registry。
master是OpenShift集群的管理节点，它包含管理组件，如API Server，controller manager server, 和etcd。Master节点通过Node节点上的服务管理Node节点，管理Node节点的健康状态。
Node节点提供容器的运行环境。每个Node节点都被Master管理。Node节点可以是物理机，也可以是虚拟机（当然需要安装RHEL），甚至可以是云环境。
Service Layer负责不同Service之间通讯的。Service是Openshift中的一个客户应用，如Tomcat。
Routing layer：提供对外网服务。把外部的请求，路由到内部Pod IP。
持久存储：为容器的数据盘提供持久存储。
Registry：企业内部镜像库。有两类：集成的库和本地库。前者存放dev阶段的build好的镜像（172网段）；后者存放企业内可以共享的基础镜像。
接下来，详细分析Openshift内部架构：下图中，白色框是Kuberrnetes自有组件，黄色框是红帽OpenShift增加的部分。
在几个核心组件，比较难理解的主要有：Build Config（bc）、Deployment Config（dc）、Image Stream。我们主要介绍这几个组件，其他组件参照笔者上一小节列出的文章链接，可以理解清楚。
bc：bc是一中静态配置，它的配置中有很多信息：如源代码在哪、build的时候拉哪一个分支的代码、基础镜像在哪、生成的应用镜像推送到哪个仓库等等。bc会触发build，生成的是包含应用的镜像。
dc：参数是可以动态变化的，变化以后，会出发一次新的部署。定义了部署的是哪一个应用的镜像、镜像的相关信息、需要挂载的volume。
所以说，我们部署一个应用，通常而言，它可以没有bc，但一定有dc。
image stream：用于跟踪、记录bc所生成的镜像。里面会记录会把bc的结果存到哪个registry中。is存在的一个重要的意义，是实现了bc的解耦（例如不必关注后端具体的registry）。
在Openshift，部署应用的方法，通常有几个（有但不限于）：
通过docker image部署：这种通常直接部署已经包含应用的打包好的镜像，因此通常没有bc。
通过S2I 部署：通过选择building image和指定code。指定完以后，code 先进行build，build成功，会将它push到内部的镜像库，然后部署一个新的pod。因此S2I通常会触发build和deploy。
通过模板部署：模板是可以把和一套应用相关的配置，都写在一起，然后通过这个模板部署应用。使用模板部署最大的好处在于，他可以加快应用的部署速度。模板是由实现写好的yaml或json文件创建的。
下面列出三种常见部署方式的关键步骤截图：
1.通过docker image部署：
部署一个位于docker.io上已经有用image：
点击create后，观察日志。很快pod就创建完了：
查看pod的状态：
将应用expose出去，以便外网访问：
通过浏览器范文，可以看到应用，这是一个地图：
在地图上找到侨福芳草地大厦（红帽办公室）：
通过S2I 部署：
登录openshift图形化界面（cli同理），选择登录用户下的一个项目：
选择给项目增加应用“Add to project”
搜索并选择building image：
然后输入代码所在的git，点击create。
接下来，就出发了build，查看build状态：
观察build的过程中产生的日志：
首先下载镜像：
code下载完毕，开始build，过了一会build完成：
build完成以后，image会被push到内部的registry中:
镜像push到内部库以后，dc会触发一次deploy部署一个pod，过一会，pod部署成功
在实验环境中，查看一个bc：
那么这个bc是做什么的呢？通过命令行进行查看：
通过上面的这个截图，我们可以很清楚的看出：这个bc触发的build操作，实际上是通过java s2i的building image，加上source code （https://github.com/openshift-roadshow/nationalparks.git）把code和images放在一起进行代码构建，然后生成一个包含应用的image（打上latest标签），这个image先被push到intergrated 的registry中。
通过模板部署：
首先创建一个模板,笔者用一个json的文件创建一个模板。
查看创建成功的模板：
至于json中的配置信息，我们截取一部分进行查看：
在OpenShift界面中可以搜到刚刚创建好的模板，通过选择这个模板，就可以创建应用了。
给容器增加监控
给容器增加的通常有两类：监控容器可提供服务、监控容器是否是活着的。如果openshift检测到容器有问题或者不能提供服务，会将现有的容器kill掉，然后新建容器。
添加监控的方法如下，选择add health checks：
列出两个属性：
分别添加，输入设置的参数：
OpenShift实现CI/CD
CI/CD Pipeline
CI/CD流程如下，因为比较好理解，就不再进行中文翻译工作了。
CI/CD与devops的一个显著的区别是上面的第六步，也就是dev阶段build好的image，需要在经过相关人员批准以后，才会在生产上部署。
在openshift中，jenkins也实现了容器化。在实验中，先部署一个Jenkins，用于和S2I做对接。
设置参数：
过一会，jenkins部署成功：
通过routes访问jenkins：
接下来，创建pipeline的pod：
在pipeline中，触发build（手工或者自动的情况都存在）以后，会继续触发dev中的部署和测试，然后在向生产中deploy之前，pending住：
点击input request后，链接到jenkines,点击继续：
触发在生产中，部署完成：
查看pod，有个新的deploy动作，说明从dev阶段传过来的新版本的image，已经在生产商重新deploy。
