某股份制商业银行定制化PaaS介绍
某股份制商业银行的PaaS平台是由睿云智合(Wise2C)与Rancher合作，基于Rancher做的定制化开发。基于业务场景和银行业的特殊需求，同时为了兼顾能够实现对以后Rancher版本的平滑升级，我们在Rancher之上做了一层逻辑抽象。 一、软件架构与部署方案 整体软件架构如下图所示： 顶层的DCOS作为统一的管理平台，可以通过PaaS以及IaaS提供的API实现对云平台的集中管控。左侧蓝色部分是原生Rancher，DCOS与红色定制化部分通过API来访问Rancher。由于未对Rancher做任何改动，可以做到对Rancher版本大于1.2的平滑升级。 红色部分为定制化逻辑抽象部分，归纳起来可以按照功能职责大致分为以下微服务（后面会详细介绍）： 1 鉴权认证 2 资源管理 3 应用编排 4 弹性伸缩 5 日志收集 6 监控告警 7 镜像仓库 这些微服务在部署时按照Rancher将infrastructure stack部署到环境中的思路，使用一个独立的Rancher环境来部署这些微服务，部署拓扑结构如下图所示： 图中每一个虚线框对应Rancher中的一个环境；“扩展ENV”这个环境直接使用Rancher server的主机作为Agent，上面运行定制化的微服务。其他环境分别对应到某个租户的特定网络，单个网络内部流量不使用Rancher原生的overlay，而采用Wise2C实现的扁平化网络，网络之间流量由外部防火墙控制。 二、角色与权限模型 PaaS平台的角色与权限模型沿用了Rancher的一部分概念，又引入了自己的内容。主要差异在于两方面： 1 PaaS平台引入了对镜像仓库的管理，这在Rancher中是没有的；即角色的权限，除包含操作Rancher外，还能够操作镜像仓库。镜像仓库与PaaS的权限模型是一致的； 2 另外，客户引入了租户的概念，这点与Rancher中不同，租户是可以跨越多个Rancher的环境的 Rancher权限模型： 平台管理员： 拥有整个Rancher平台的所有权限； 环境用户： 1 Owner拥有环境的所有权限； 2 Member拥有除对环境内部用户授权外的所有权限； 3 Restricted User拥有环境内部除对用户授权以及操作基础资源外的所有权限； 4 Read Only拥有环境内部资源的只读权限； PaaS平台权限模型： 平台管理员： 等同于Rancher的平台管理员权限再加上对镜像仓库管理的所有权限； 租户内部角色： 1 租户管理员拥有管理租户资源以及对租户内部用户进行授权的所有权限；再加上对镜像仓库管理的所有权限 2 高级成员在PaaS平台内拥有对租户内用户授权以及操作基础资源外的所有权限；在镜像仓库内，拥有对镜像仓库设置镜像同步规则、创建、删除镜像仓库Namespace、改变镜像状态等权限； 3 受限成员在PaaS平台内拥有对租户内用户授权以及操作基础资源外的所有权限；在镜像仓库所属Namespace内，拥有上传、下载镜像的权限； 4 Read Only在PaaS平台内，拥有查看租户类资源的权限；在镜像仓库所属Namespace内，拥有查看镜像仓库资源的权限； 具体映射关系如下图所示： 鉴权部分的软件设计如下所示： 所有对PaaS访问的API请求均经由API proxy做鉴权控制之后代理到系统内部具体的微服务上。PaaS不直接参与租户的增删查改，API proxy通过与PaaS外部的Keystone通信来获取用户角色以及租户信息。 三、资源管理 网络部分 1 由于金融行业对网络安全性方面的要求比较苛刻，而Rancher所能够提供的均是基于某个环境内部的overlay网络。Overlay必然会导致很多报文无法被安全设备透明的过滤，这是行业内无法接受的；因此，必须采用扁平网络。 2 处于安全的考虑，会出现同一个stack内部的多个service需要分别部署到不同的网络分区的需求，采用当前Rancher的managed网络显然无法满足需求；因此，必须支持多网络。 对于扁平网络的支持，我在之前的文章（在Rancher 1.2中实现基于CNI的扁平网络）中有详细的介绍，主要是使用ebtable直接在linux bridge上对流量做控制，从而避免使用overlay；这样，外部安全设备能够透明的看到各个容器之间的流量。 对于多网络的支持，我们是通过在Rancher之上实现一层抽象逻辑来实现的。整个模型演变为一个网络映射为Rancher的一个环境（环境内部运行一个扁平网络）。这部分主要涉及对平台中所有网络的管理，以及维护租户与网络之间的映射关系。 下面举一个例子来描述该流程： 1 平台管理员在PaaS上创建一个网络，指定网络的参数（子网掩码、网关、所属安全域、所属隔离域等），这些数据会保存到数据库； 2 平台管理员根据需要为租户分配第一个网络；此时，抽象层需要真正在Rancher上创建出网络所对应的环境；以及创建监控、日志、以及定制化系统所需的system级别的应用堆栈； 3 当平台管理员为租户分配第二个以上的网络时，抽象层还需要将该Rancher环境与租户其他网络对应的Rancher环境之间建立env link关系，否则跨Rancher环境的应用堆栈各service之间无法使用Rancher DNS进行互访。 存储部分 客户PaaS在存储部分最终选定NFS作为其存储方案，前期也有讨论过使用ceph等，这部分我在之前的文章（探讨容器中使用块存储）中也有专门分析过为什么不选用那种方案。 由于单个租户可以拥有多个网络（也就是多个Rancher环境），而在Rancher中Rancher-NFS driver所创建volume是基于环境层面的。为了能够将该volume映射到租户层面，我们在抽象层中做了这层映射操作。 具体流程如下： 1 平台管理员在PaaS中指定参数创建出一个NFS server；同网络一样，此时只是将数据保存到数据库； 2 平台管理员为租户分配NFS server，此时抽象层真正操作租户网络所对应的多个Rancher环境，在逐个环境内添加用于提供Rancher-NFS driver的system...
Read More