科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道互联网看红帽最高深的武功OpenShift

看红帽最高深的武功OpenShift

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

第一种,一辈子纵横江湖数十载,所学武功实用有效,招数简明而力道雄厚,善于“简单粗暴”迅速解决问题。在TA心中:能用黑虎掏心解决的问题,干啥非要耍一套袈裟伏魔功?能用虚拟化RHV/vSphere解决的问题,凭啥上OpenStack?vLAN能解决的问题,上啥SDN?

来源:至顶网软件频道 2017年5月25日

关键字:下一代企业应用架构平台 红帽

世上高手大约有两种:

第一种,一辈子纵横江湖数十载,所学武功实用有效,招数简明而力道雄厚,善于“简单粗暴”迅速解决问题。在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。

综合评分:8.12667 分
云能力:8.3 分
营业额:11.3亿美元[2011]
云服务:红帽Cloud Foundation云基础架构

查看更多 >>

邮件订阅

如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

重磅专题
最新文章