微信号:david-share

介绍:乐于分享,才有进步.

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

2017-01-12 01:22 魏新宇

世上的高手

世上高手大约有两种:

第一种如下图这为老先生,一辈子纵横江湖数十载,所学武功实用有效,招数简明而力道雄厚,善于“简单粗暴”迅速解决问题。在老爷子的心目中:能用黑虎掏心解决的问题,干啥非要耍一套袈裟伏魔功?能用虚拟化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。




 
大卫分享 更多文章 红帽武学的藏经阁 | 如何善用Red Hat Customer Portal 厉害了word哥 | 从两张图看红帽最高深的武功 |OpenShift 红帽武学的藏经阁 | 如何善用Red Hat Customer Portal 红帽武学的藏经阁 | 如何善用Red Hat Customer Portal 读天龙八部,品红帽的各项武功
猜您喜欢 首届语言与智能高峰论坛|业界大牛畅谈语言与智能 国庆送大礼,向那些明知困难重重,却坚持改变自我的学子们致敬! 7-Eleven 零售的哲学 Flask Basic Auth的实现 如何理解社区或社群的典型运营路径和逻辑?