DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

本文讲的是DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践【编者的话】企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发、应用交付、上线运维等环节,包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术、涉及的核心功能模块以及相关方案。

为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能化云平台专利技术来构建。 此外,平台提供各种标准化或非标准的运行环境以及各种运维管理功能,用户可以在秒级按需获取各类资源和环境,平台最大的价值在于解放开发、测试、运维人员,降低用户对应用软件的交付成本及时间。

MoPaaS企业版由Cloud Foundry提供标准运行环境、标准中间件服务接入方式、认证授权、软路由、组织管理、资源分配等功能。但Cloud Foundry新的运行时Diego虽然支持运行Docker镜像,但是功能相对较弱,并且运行在Diego中的应用架构必须符合一定的标准。MoPaaS 企业版 使用Kubernetes来提供对非标准运行环境及中间件服务的支持;所以对于不符合Cloud Foundry架构标准的应用,可以方便地运行到Kubernetes 的环境中。这样,MoPaaS企业云平台相对比较灵活,对应用运行环境和应用架构没那么多限制,所以一些老的应用迁移至云平台变得非常容易。MoPaaS管理Cloud Foundry和Kubernetes资源,进行统一的管理和调度。

MoPaaS平台助力用户根据业务需要实现计算资源的动态调配和应用的快捷交付,特别是帮助用户显著节省 IT 支出和应用提供的成本,缩短应用上线时间以及简化IT和应用的管理。此外,作为用户持续创新数字平台以及业务连续性的保证,MoPaaS也帮助企业用户有效地应对市场的变化,通过持续创新不断保持市场竞争力。

MoPaaS平台(企业版)总体架构如下:

应用运行环境和中间件服务

应用运行环境和中间件服务是PaaS平台的核心功能模块,用户发布应用至平台时,只需发布应用本身,应用所依赖的操作系统、软件环境、中间件服务等都由平台提供,通过自动化方式配置和部署。

应用运行环境

PaaS平台需要支持不同类型的应用,应用架构及所依赖的软件环境各有不同。MoPaaS平台目前支持三大类应用运行环境,以及三种应用发布方式。

三类应用运行环境包括:

  1. 基于Cloud Foundry的标准运行环境
    标准运行环境由平台预先制作好,优化相关配置后提供给用户使用,适合对环境没有个性化要求的应用,用户无需自己制作运行环境和进行相关配置,申请标准运行环境后,只需要将可执行包推送至平台即可。
    • 多语言和框架:覆盖Go、Ruby、Python、Java、JS、PHP的多语言运行及框架
    • 语言和框架的扩展机制和BuildPack扩展
    • 服务插件及扩展机制:提供多种基础,如代码托管(Git)、数据库(MySQL、PostgreSQL、MongoDB)、缓存(Redis和MemCached)、消息队列(RabitMQ等)、Jenkins,以及众多的第三方服务扩展
  2. 基于Docker的MoPaas镜像
    MoPaaS镜像,适合对环境配置有个性化要求的应用,用户可以基于MoPaaS基础镜像构建自己的应用镜像来运行,构建时还可以修改基础镜像配置。通过MoPaaS镜像运行环境可以节省用户构建基础镜像的时间,通过用户自定义应用镜像,支持更多的应用类型运行至MoPaaS平台中。
  3. 基于Docker的自定义镜像
    自定义镜像需要用户自行制作运行环境,由用户在本地制作完成镜像后推送至平台运行,自定义镜像方式所有环境完全由用户自己定义,相对比较灵活,可以完全满足用户的个性化需求。

三种应用发布方式:

  1. 可执行包发布(war、zip)
    用户首先需在本地将应用编译打包成可执行包,然后在平台上申请运行环境和中间件服务,通过Web UI或命令行操作将可执行包推送至平台,平台接收到可执行包后会将其Build成一个应用镜像后发布到平台运行。
  2. 源码发布
    用户将代码提交至平台的Git源码仓库或者平台应用关联的一个Git源码仓库,通过手动或者自动触发一个持续集成流程后将应用Build成镜像后发布到平台运行。
  3. 镜像发布
    用户将自己制作的镜像推送到MoPaaS平台发布。

中间件服务

中间件服务是应用运行必不可少的软件资源,比如数据库,平台通过两种方式提供中间件服务:

  1. 平台内部提供的中间件服务
    平台内部提供的中间件服务以容器方式运行,目前运行在Kubernetes,可提供集群或主从方式保证中间件服务的高可用性。中间件服务运行在容器跟应用很大的不同是,我们可以要求应用在设计时尽量无状态,但是大部分中间件是需要在本地存储数据的,不可能是无状态的,因此在容器中运行中间件服务的关键是要解决数据本地存储的问题,目前Kubernetes支持多种PersistenceVolume,可以将数据存储到外挂的网络存储服务上来解决这个问题。
  2. 平台接入外部提供的中间件服务
    有些第三方中间件服务暂时不适合运行到容器,特别是第三方提供的中间件,比如Oracle,或者有专门的运维团队运维,像这样的中间件可以独立于平台部署,通过比较松耦合的方式接入到平台供用户使用。具体方案如下:

应用外部接入方式

部署在Diego或Kubernetes上的应用,都是以容器方式运行,容器会被调度和管理,因此我们访问应用时,不能直接访问容器的IP+Port。

Cloud Foundry将容器的IP+Port动态更新至Route管理的路由表实现外部接入,默认支持HTTP(S) 协议。Kubernetes的Service能够提供很强大的功能,通过提供ClusterIP作为Pod的对外访问接口,并提供软负载均衡。但是Service的Cluster IP地址只能在集群内部访问,可以通过NodePort方式对外暴露服务。一旦采用NodePort,整个集群的所有节点都可以通过指定的端口访问到应用。

如果需要域名访问这个应用的话,只需要将Kubernetes节点的IP+NodePort注册到Route的路由表中实现。如果应用需要支持TCP协议访问,对于Diego管理的容器可以将容器IP+Port动态更新到前端负载均衡。对于Kubernetes,将集群的节点IP+NodePort动态更新至前端负载均衡。实现原理如下:

MoPaaS平台提供独立的 Router Proxy 模块,动态加载路由表,支持TCP 和 HTTP 的负载均衡,域名映射灵活,可快速变更。

CI/CD在PaaS平台中的应用

平台集成了Git作为源码管理仓库,当用户在平台上新建一个应用时,自动会为此应用分配一个Git仓库。应用也可以关联平台外部的Git仓库,源码仓库一旦和应用关联之后,就可以实现将源代码自动发布至平台运行的整个流程。

发布之前需要经过一个持续集成流程,持续集成流程可以预先定义,不同的交付团队可能会有差异,只有所有阶段都通过才能发布成功。在开发测试阶段,可以开启自动构建功能,当代码发生变更时自动触发构建流程,并及时反馈集成状态和结果。

功能截图如下:

平台通过Jenkins配置整个持续集成流程,整个流程由代码质量检查、单元测试、构建、部署等几个阶段组成。当触发部署时,先判断当前应用在Jenkins平台上是否已经创建对应的持续任务,如果已经存在的话就触发第一个任务,如果不存在则创建这些任务。每一个任务成功执行才会触发下一个任务的执行,组成持续集成流程的所有任务执行过程。任务执行过程中的启动、成功、失败等状态会通过Webhook反馈给平台,平台会记录这些状态,并根据执行结果改变执行流程。

实现原理如下:

持续集成可以帮助我们频繁地、自动化地构建应用软件,构建完成后需要将应用发布到平台运行。随着频繁的发布应用到生产环境,风险也会随之增加。所以要做到持续发布,需要通过灰度发布、回滚等机制保证发布过程的安全性。

MoPaaS平台支持灰度发布和应用回滚策略,实现应用发布的平滑过渡,保证系统整体的稳定性,避免频繁发布对用户所造成的影响。

实现原理如下:

上线流程原理如下:

弹性伸缩与自动化运维

弹性伸缩

MoPaaS平台提供两种方式实现弹性伸缩:手动和自动。

用户可以根据自己的需求,设置相关的定时或周期性的策略,在适当的时机增加或减少资源,从而节约人力和资金成本,保证应用健康平稳运行。

手动方式需要人为触发,可以进行横向和纵向伸缩,横向伸缩是指调整应用的实例数量,也就是组成应用集群的容器数量,平台提供智能化的负载均衡。

纵向伸缩是指扩展应用单个容器的资源配额,比如内存、CPU等。

MoPaaS 平台目前可提供横向伸缩方式。平台可根据应用资源的使用情况,如:CPU、内存,或访问情况,如:QPS,对应用进行横向的扩容或缩容。开启自动扩容后,平台将结合用户自己配置的策略,联合监控数据,自动的创建和释放实例,全程无需人工参与,实现资源合理利用最大化。通过对最小实例数的设定,可保证应用实时可用数量。

自动弹性伸缩的实现方案如下:

Route组件将访问日志记录至文件,通过LogAgent实时采集访问日志数据发送至消息队列。日志结构包括域名、请求时间、Method、URI、协议、响应状态、下行流量、请求来源、浏览器信息、请求容器信息、响应时间等。

通过这些日志数据可以统计出外部对应用的并发访问量、下行流量、成功率、响应性能等指标。

MoPaaS收集到这些访问日志数据之后,通过定时执行数据库存储过程进行统计、分析、合并、清理。

MoPaaS统计最近10秒内的平均每秒并发量,根据用户预先设置好的弹性伸缩规则,计算得出当前并发量所需实例数量,然后通过下发指令给容器平台如Cloud Foundry、Kubernetes实现弹性伸缩功能。功能截图如下:

自动化运维

自动化运维主要包括健康检查和故障恢复。

健康检查包括对平台的自动化监控和检测,一旦监控到性能超标或宕机故障,则触发相关事件。如应用出现故障,则重新启动实例,物理机故障时,实例将迁移至其他主机,相当于一次部署过程。

在传统监控基础上,增加健康检查机制,用户能够一目了然的看到整个流程的各个节点运转情况,实例自动重启与迁移,报警大量减少,人力减少,只有自动恢复失败时才报警。不仅仅减少了人力的投入,也是一种降低成本的表现。

监控报警和日志管理

运行在Cloud Foundry的容器监控数据由Doppler组件统一收集,我们通过Firehose组件可以采集到所有应用的性能数据,如健康状态、CPU使用率、内存使用率、IO、磁盘使用率等等。运行在Kubernetes上的容器通过cAdvisor采集,并统一汇总至Heapster,Heapster可以将数据存储至时序数据库Influxdb中,平台通过查询数据库进行报表展示以及根据预先设置的阈值进行报警。

开发测试阶段,日志打到标准输出stdout,可以通过平台提供的Webconsole实时输出,如果需要持久化日志信息,平台提供一个Log4j SDK,这个SDK支持日志输出到一个消息队列中,应用需要持久化日志,只需要通过这个日志SDK输出日志即可,日志被打到消息队列后,由ELK存储日志,平台可以通过ElasticSearch提供的接口搜索需要的日志。

应用云化的设计原则

在我们实施的多个PaaS 项目中,遇到的最大的问题是将应用迁移到云平台上。由于客户有些应用迁移时要求应用架构、软件版本等与未迁移前保持一致,因此并不是100%的应用都可以原封不动地往PaaS平台上迁移,平台支持非标准化运行环境已经在很大程度上支持了不同环境要求不同架构的应用迁移,但是如果有可能的话,比如应用方允许修改依赖的环境或应用架构以更好的迁移至PaaS平台,或者新开发的应用,像这样的应用的话最好符合一些云化的设计原则,具体要求如下:

  1. 容器和应用实例定位
    • 容器和实例与 IaaS 和物理机的解耦,依赖域名或配置管理来对其定位
  2. 数据持久化
    • 持久化数据存放在 DB、NFS、或其它共享存储
    • 日志保存至第三方服务
    • 实例迁移时内部数据不必保留和迁移
  3. 状态管理
    • 平台不提供状态保存管理,也不依赖Proxy 会话保持功能
    • 状态保存至第三方服务,以支持水平扩展、负载动态均衡和故障转移
  4. 优化 MTTR
    • 使实例的重启和重建变得更快捷

Q&A

Q:弹性扩容的时候怎么区分需要垂直扩容还是水平扩容?

A:自动扩容是水平扩容,根据并发量、CPU、内存的实时数据分析来实现。

Q:所有的扩容都是水平扩容吗?不太清楚自动化的垂直扩容应该怎么判断,有什么想法不?

A:目前所有扩容都是水平扩展,要垂直扩展只能手动,原因是垂直扩展变更内存、CPU后有些情况下需要重新进行实例分布。

Q:水平扩容只是增加实例就可以了,对吧。缩容呢,怎么判断呢?

A:缩容也是一样的,根据最近10秒内的并发量决定需要多少个实例。

Q:现在扩容的依据是基础监控数据和业务的监控数据同时考虑吗?

A:目前平台主要基于基础监控数据来进行扩容,业务数据如果也是导致应用性能瓶颈的一个因素的话,纳入到扩容策略里面也是比较简单。

Q:数据共享卷的解决方案是如何考虑的,基于cinder还是ceph,创建个数据共享卷要先格式化创建文件系统,如何实现和node节点挂载前的前格式化的,node节点故障,容器发生重生共享卷如何挂载到新节点上呢?

A:共享卷是直接挂到容器上的,不是挂载到宿主机上,Glusterfs、Ceph、NFS等都支持。

Q:灰度发布功能,目前我理解的是分为滚动升级和AB测试,这个目前实现的那种,AB测试具体如何理解呢?

A:您说的是蓝绿发布吗?蓝绿发布应该是保证无宕机的前提下,将老版更新到新版。

Q:请问,Kubernetes中的A域名指向一个应用,B域名指向另外一个应用,都要用到80和443端口,这个该怎么做呢?

A:前端加一个route,进行域名和IP+Port的转发。

以上内容根据2016年8月23日晚微信群分享内容整理。分享人沈阅斌,MoPaaS产品研发总监。11年IT从业经验,国内较早一批从事Cloud Foundry等PaaS技术相关研发工作。擅长Java、J2EE、Spring、Hibernate、Struts、JPA、Cloud Foundry、Docker、Kubernetes、RabbitMQ、Jenkins等技术。 2011年加入MoPaaS负责产品研发和管理工作。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

原文发布时间为:2016-08-28

本文作者:沈阅斌

原文标题:DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

时间: 2017-10-11

DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践的相关文章

DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践

本文讲的是DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践[编者的话]Docker可以显著改善企业软件研发流程.提升企业DevOps效率.借助Docker,企业可以对现有IT系统进行一次梳理,解决IT软件系统部署.升级难的顽疾,重新释放企业生产力,降低企业成本.本次分享介绍了恒生电子运用Docker技术,加上自研配套工具,实现金融交易系统配置.部署.运维自动化的心得,包括: Docker的优势以及我们为什么要使用Docker: 恒生Docker运用现状: 恒生金融交易系统

DockOne微信分享(九十九):海航生态科技舆情大数据平台容器化改造

本文讲的是DockOne微信分享(九十九):海航生态科技舆情大数据平台容器化改造[编者的话]海航舆情监控系统能够为海航集团内部提供监控网络舆情信息,对负面信息.重大舆情及时预警,研判具体舆情或者某一舆情专题事件的发展变化趋势,生成图标报告和各种统计数据,提高舆情工作效率和辅助领导决策.然而,随着项目的持续运行,许多问题逐渐暴露出来,为了解决这些难题,对整个项目重新规划设计,迁移到Hadoop.Spark大数据平台,引进持续化Docker容器部署和发布,开发和运营效率得到显著提升. 一. 舆情平台

DockOne微信分享(一一九):Elastic-Job-Cloud作业云在当当的SRE实践

本文讲的是DockOne微信分享(一一九):Elastic-Job-Cloud作业云在当当的SRE实践[编者的话]本次分享面向对Mesos与SRE感兴趣的听众.随着容器技术在国内的持续流行,关注点已经由容器技术本身向运维方面逐渐过渡,Google一直安利的SRE经验正好契合了这个时代的运维节奏,由此契合SRE概念而衍生的Mesos,Kubernete服务也持续推动着相关理念落地.当当正是在这种背景下研发并推广作业云平台,该平台借助Mesos平台打造高自动化云平台.本次分享将重点为大家带来我们是如

DockOne微信分享(一一八):容器技术在企业级服务里的实践

本文讲的是DockOne微信分享(一一八):容器技术在企业级服务里的实践[编者的话]邻盛在做面向中小微企业做服务的时候, 实际遇到很多情况, 比如对方IT基础过于薄弱, 比如基础设施过于简陋, 比如产品要解决行业需求, 企业个性需求等等,经过几年积累目前摸索出了一套完整的产品方案.目前产品是以容器为核心的一套完整的PaaS平台+全新的微服务架构+底层能力构成的完整解决方案, 目前也进入到了几家传统大型制造企业协助他们完成新一代的信息升级. [深圳站|3天烧脑式Kubernetes训练营]培训内容

DockOne微信分享(一二九):聊聊Service Mesh:linkerd

本文讲的是DockOne微信分享(一二九):聊聊Service Mesh:linkerd[编者的话]随着企业逐渐将传统的单体应用向微服务或云原生应用的转变,虽然微服务或者云原生应用能给企业带来更多的好处,但也会带来一些具有挑战的问题,如怎么管理从单体应用转向微服务所带来的服务间通讯的复杂性,怎么实现微服务间安全,高效,可靠的访问,如何满足多语言多环境的透明通讯,服务发现.熔断,动态流量迁移,金丝雀部署,跨数据中心访问等等.本次分享给大家引入一新概念服务网格(Service Mesh)以及介绍业界

DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps

本文讲的是DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps[编者的话]DevOps是2009年前后提出的一个概念,提倡开发(Development)和运维(Operations)这两个领域的高度协同.从而在完成高频率部署的同时,提高生产环境的可靠性.稳定性.弹性和安全性.本次分享介绍了PPTV聚力传媒以Docker技术为支撑,在DevOps方面做的优化,包括: DevOps简介 Docker在PPTV的应用 DevOps与Docker的结合 实现方案 DevOps

DockOne微信分享(一一零):Docker在沪江落地的实践

本文讲的是DockOne微信分享(一一零):Docker在沪江落地的实践[编者的话]容器化是很多公司技术层向往又惧怕的一项热门技术,它的高效性,封装性能给开发.运维带来许多便利,但其本身也需要较强的技术能力去控制,否则会变成一个无法落地的概念.沪江作为教育界的独角兽,随着业务的增长,在开发.测试.运维上的成本增加日益显著.经过我们一年的探索,终于使Docker技术在沪江落地,不但成功的降低了成本,并吸引了其他部门的关注与试用,取得良好的成效. [上海站|3天烧脑式微服务架构训练营]培训内容包括:

DockOne微信分享(七十八):中英人寿保险有限公司基于容器技术的实践分享

本文讲的是DockOne微信分享(七十八):中英人寿保险有限公司基于容器技术的实践分享[编者的话] 中英人寿在移动应用开发与运维上引入DevOps,极大的提升了开发效率,进而实现持续交付能力.持续交付让移动应用上线的速度从以月为单位提升到周甚至到天. 通过在企业云上使用(Docker.Git.Jenkins etc)搭建自动化部署流水线, 使软件的构建.测试.部署的过程自动化实现.随着IT架构向云架构的转型,在架构级管理工具上采用虚拟化容器管理,实现从IaaS到PaaS的转变.对移动应用系统进行

DockOne微信分享(七十五):应用容器化之Kubernetes实践

本文讲的是DockOne微信分享(七十五):应用容器化之Kubernetes实践[编者的话]本次分享主要以ZooKeeper.Redis.Kafka.MongoDB等应用容器化在Kubernetes平台上面实践.从计算.网络.存储方面解析应用在集成中的问题,以及部分传统应用在容器化过程中设计的应用二次开发等问题.首先介绍应用Docker化的需求和局限.接着介绍基础平台,整体环境包括Kubernetes和ECP,然后介绍具体应用如ZooKeeper在集成中的实践,最后介绍部分开源应用在容器化过程中