本文讲的是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平台的核心功能模块，用户发布应用至平台时，只需发布应用本身，应用所依赖的操作系统、软件环境、中间件服务等都由平台提供，通过自动化方式配置和部署。
三类应用运行环境包括：
三种应用发布方式：
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 的负载均衡，域名映射灵活，可快速变更。
发布之前需要经过一个持续集成流程，持续集成流程可以预先定义，不同的交付团队可能会有差异，只有所有阶段都通过才能发布成功。在开发测试阶段，可以开启自动构建功能，当代码发生变更时自动触发构建流程，并及时反馈集成状态和结果。
功能截图如下：
平台通过Jenkins配置整个持续集成流程，整个流程由代码质量检查、单元测试、构建、部署等几个阶段组成。当触发部署时，先判断当前应用在Jenkins平台上是否已经创建对应的持续任务，如果已经存在的话就触发第一个任务，如果不存在则创建这些任务。每一个任务成功执行才会触发下一个任务的执行，组成持续集成流程的所有任务执行过程。任务执行过程中的启动、成功、失败等状态会通过Webhook反馈给平台，平台会记录这些状态，并根据执行结果改变执行流程。
实现原理如下:
持续集成可以帮助我们频繁地、自动化地构建应用软件，构建完成后需要将应用发布到平台运行。随着频繁的发布应用到生产环境，风险也会随之增加。所以要做到持续发布，需要通过灰度发布、回滚等机制保证发布过程的安全性。
MoPaaS平台支持灰度发布和应用回滚策略，实现应用发布的平滑过渡，保证系统整体的稳定性，避免频繁发布对用户所造成的影响。
实现原理如下：
上线流程原理如下：
用户可以根据自己的需求，设置相关的定时或周期性的策略，在适当的时机增加或减少资源，从而节约人力和资金成本，保证应用健康平稳运行。
手动方式需要人为触发，可以进行横向和纵向伸缩，横向伸缩是指调整应用的实例数量，也就是组成应用集群的容器数量，平台提供智能化的负载均衡。
纵向伸缩是指扩展应用单个容器的资源配额，比如内存、CPU等。
MoPaaS 平台目前可提供横向伸缩方式。平台可根据应用资源的使用情况，如：CPU、内存，或访问情况，如：QPS，对应用进行横向的扩容或缩容。开启自动扩容后，平台将结合用户自己配置的策略，联合监控数据，自动的创建和释放实例，全程无需人工参与，实现资源合理利用最大化。通过对最小实例数的设定，可保证应用实时可用数量。
自动弹性伸缩的实现方案如下:
Route组件将访问日志记录至文件，通过LogAgent实时采集访问日志数据发送至消息队列。日志结构包括域名、请求时间、Method、URI、协议、响应状态、下行流量、请求来源、浏览器信息、请求容器信息、响应时间等。
通过这些日志数据可以统计出外部对应用的并发访问量、下行流量、成功率、响应性能等指标。
MoPaaS收集到这些访问日志数据之后，通过定时执行数据库存储过程进行统计、分析、合并、清理。
MoPaaS统计最近10秒内的平均每秒并发量，根据用户预先设置好的弹性伸缩规则，计算得出当前并发量所需实例数量，然后通过下发指令给容器平台如Cloud Foundry、Kubernetes实现弹性伸缩功能。功能截图如下：
健康检查包括对平台的自动化监控和检测，一旦监控到性能超标或宕机故障，则触发相关事件。如应用出现故障，则重新启动实例，物理机故障时，实例将迁移至其他主机，相当于一次部署过程。
在传统监控基础上，增加健康检查机制，用户能够一目了然的看到整个流程的各个节点运转情况，实例自动重启与迁移，报警大量减少，人力减少，只有自动恢复失败时才报警。不仅仅减少了人力的投入，也是一种降低成本的表现。
开发测试阶段，日志打到标准输出stdout，可以通过平台提供的Webconsole实时输出，如果需要持久化日志信息，平台提供一个Log4j SDK，这个SDK支持日志输出到一个消息队列中，应用需要持久化日志，只需要通过这个日志SDK输出日志即可，日志被打到消息队列后，由ELK存储日志，平台可以通过ElasticSearch提供的接口搜索需要的日志。
为满足以上需求，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平台目前支持三大类应用运行环境，以及三种应用发布方式。三类应用运行环境包括：
- 基于Cloud Foundry的标准运行环境
标准运行环境由平台预先制作好，优化相关配置后提供给用户使用，适合对环境没有个性化要求的应用,用户无需自己制作运行环境和进行相关配置，申请标准运行环境后，只需要将可执行包推送至平台即可。
- 多语言和框架：覆盖Go、Ruby、Python、Java、JS、PHP的多语言运行及框架
- 语言和框架的扩展机制和BuildPack扩展
- 服务插件及扩展机制：提供多种基础，如代码托管（Git）、数据库（MySQL、PostgreSQL、MongoDB）、缓存（Redis和MemCached）、消息队列（RabitMQ等）、Jenkins，以及众多的第三方服务扩展
- 基于Docker的MoPaas镜像
MoPaaS镜像，适合对环境配置有个性化要求的应用，用户可以基于MoPaaS基础镜像构建自己的应用镜像来运行，构建时还可以修改基础镜像配置。通过MoPaaS镜像运行环境可以节省用户构建基础镜像的时间，通过用户自定义应用镜像，支持更多的应用类型运行至MoPaaS平台中。 - 基于Docker的自定义镜像
自定义镜像需要用户自行制作运行环境，由用户在本地制作完成镜像后推送至平台运行，自定义镜像方式所有环境完全由用户自己定义，相对比较灵活，可以完全满足用户的个性化需求。
三种应用发布方式：
- 可执行包发布（war、zip）
用户首先需在本地将应用编译打包成可执行包，然后在平台上申请运行环境和中间件服务，通过Web UI或命令行操作将可执行包推送至平台，平台接收到可执行包后会将其Build成一个应用镜像后发布到平台运行。 - 源码发布
用户将代码提交至平台的Git源码仓库或者平台应用关联的一个Git源码仓库，通过手动或者自动触发一个持续集成流程后将应用Build成镜像后发布到平台运行。 - 镜像发布
用户将自己制作的镜像推送到MoPaaS平台发布。
中间件服务
中间件服务是应用运行必不可少的软件资源，比如数据库，平台通过两种方式提供中间件服务:- 平台内部提供的中间件服务
平台内部提供的中间件服务以容器方式运行，目前运行在Kubernetes，可提供集群或主从方式保证中间件服务的高可用性。中间件服务运行在容器跟应用很大的不同是，我们可以要求应用在设计时尽量无状态，但是大部分中间件是需要在本地存储数据的，不可能是无状态的，因此在容器中运行中间件服务的关键是要解决数据本地存储的问题，目前Kubernetes支持多种PersistenceVolume，可以将数据存储到外挂的网络存储服务上来解决这个问题。 - 平台接入外部提供的中间件服务
有些第三方中间件服务暂时不适合运行到容器，特别是第三方提供的中间件，比如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平台，或者新开发的应用，像这样的应用的话最好符合一些云化的设计原则，具体要求如下：- 容器和应用实例定位
- 容器和实例与 IaaS 和物理机的解耦，依赖域名或配置管理来对其定位
- 数据持久化
- 持久化数据存放在 DB、NFS、或其它共享存储
- 日志保存至第三方服务
- 实例迁移时内部数据不必保留和迁移
- 状态管理
- 平台不提供状态保存管理，也不依赖Proxy 会话保持功能
- 状态保存至第三方服务，以支持水平扩展、负载动态均衡和故障转移
- 优化 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：您说的是蓝绿发布吗？蓝绿发布应该是保证无宕机的前提下，将老版更新到新版。Ｑ：请问，Kubernetes中的A域名指向一个应用，B域名指向另外一个应用，都要用到80和443端口，这个该怎么做呢？
Ａ：前端加一个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
本文作者：沈阅斌
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享（七十九）：基于容器技术构建企业级PaaS云平台实践
