厉害了word哥 | 从两张图看红帽最高深的武功 |OpenShift

世上的高手

世上高手大约有两种：

第一种如下图这为老先生，一辈子纵横江湖数十载，所学武功实用有效，招数简明而力道雄厚，善于“简单粗暴”迅速解决问题。在老爷子的心目中：能用黑虎掏心解决的问题，干啥非要耍一套袈裟伏魔功？能用虚拟化RHV/vSphere解决的问题，凭啥上openstack？vLAN能解决的问题，上啥SDN？

另外一种高手：

所练武艺精妙无比，招数变化层出不穷，出招变化莫测，随着对武功理解的深入，渐入以无招胜有招的境界，加以深厚的内力，使将出来，天下无敌。这是什么武功？大名鼎鼎的Openshift。

Openshift最核心的内功心法

Openshift到底是个啥？

从架构角度，用一句话来形容OpenShift，那它就是企业版的K8S。

从功能角度，用一句话来说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网段）；后者存放企业内可以共享的基础镜像。

关于每个组件的功能以及工作原理，笔者在之前的文章已经介绍过，这里不再赘述，详情请参照：

参考文档：

同时面向运维和开发的企业级PaaS平台--OpenShift

接下来，详细分析Openshift内部架构：

下图中，白色框是K8S自有组件，黄色框是红帽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的文件创建一个模板。

查看创建成功的模板：

至于jason中的配置信息，我们截取一部分进行查看：

在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。