某股份制商業(yè)銀行定制化PaaS介紹
某股份制商業(yè)銀行的PaaS平臺是由睿云智合(Wise2C)與Rancher合作，基于Rancher做的定制化開發(fā)?；跇I(yè)務場景和銀行業(yè)的特殊需求，同時為了兼顧能夠?qū)崿F(xiàn)對以后Rancher版本的平滑升級，我們在Rancher之上做了一層邏輯抽象。 一、軟件架構與部署方案 整體軟件架構如下圖所示： 頂層的DCOS作為統(tǒng)一的管理平臺，可以通過PaaS以及IaaS提供的API實現(xiàn)對云平臺的集中管控。左側藍色部分是原生Rancher，DCOS與紅色定制化部分通過API來訪問Rancher。由于未對Rancher做任何改動，可以做到對Rancher版本大于1.2的平滑升級。 紅色部分為定制化邏輯抽象部分，歸納起來可以按照功能職責大致分為以下微服務（后面會詳細介紹）： 1 鑒權認證 2 資源管理 3 應用編排 4 彈性伸縮 5 日志收集 6 監(jiān)控告警 7 鏡像倉庫 這些微服務在部署時按照Rancher將infrastructure stack部署到環(huán)境中的思路，使用一個獨立的Rancher環(huán)境來部署這些微服務，部署拓撲結構如下圖所示： 圖中每一個虛線框?qū)猂ancher中的一個環(huán)境；“擴展ENV”這個環(huán)境直接使用Rancher server的主機作為Agent，上面運行定制化的微服務。其他環(huán)境分別對應到某個租戶的特定網(wǎng)絡，單個網(wǎng)絡內(nèi)部流量不使用Rancher原生的overlay，而采用Wise2C實現(xiàn)的扁平化網(wǎng)絡，網(wǎng)絡之間流量由外部防火墻控制。 二、角色與權限模型 PaaS平臺的角色與權限模型沿用了Rancher的一部分概念，又引入了自己的內(nèi)容。主要差異在于兩方面： 1 PaaS平臺引入了對鏡像倉庫的管理，這在Rancher中是沒有的；即角色的權限，除包含操作Rancher外，還能夠操作鏡像倉庫。鏡像倉庫與PaaS的權限模型是一致的； 2 另外，客戶引入了租戶的概念，這點與Rancher中不同，租戶是可以跨越多個Rancher的環(huán)境的 Rancher權限模型： 平臺管理員： 擁有整個Rancher平臺的所有權限； 環(huán)境用戶： 1 Owner擁有環(huán)境的所有權限； 2 Member擁有除對環(huán)境內(nèi)部用戶授權外的所有權限； 3 Restricted User擁有環(huán)境內(nèi)部除對用戶授權以及操作基礎資源外的所有權限； 4 Read Only擁有環(huán)境內(nèi)部資源的只讀權限； PaaS平臺權限模型： 平臺管理員： 等同于Rancher的平臺管理員權限再加上對鏡像倉庫管理的所有權限； 租戶內(nèi)部角色： 1 租戶管理員擁有管理租戶資源以及對租戶內(nèi)部用戶進行授權的所有權限；再加上對鏡像倉庫管理的所有權限 2 高級成員在PaaS平臺內(nèi)擁有對租戶內(nèi)用戶授權以及操作基礎資源外的所有權限；在鏡像倉庫內(nèi)，擁有對鏡像倉庫設置鏡像同步規(guī)則、創(chuàng)建、刪除鏡像倉庫Namespace、改變鏡像狀態(tài)等權限； 3 受限成員在PaaS平臺內(nèi)擁有對租戶內(nèi)用戶授權以及操作基礎資源外的所有權限；在鏡像倉庫所屬Namespace內(nèi)，擁有上傳、下載鏡像的權限； 4 Read Only在PaaS平臺內(nèi)，擁有查看租戶類資源的權限；在鏡像倉庫所屬Namespace內(nèi)，擁有查看鏡像倉庫資源的權限； 具體映射關系如下圖所示： 鑒權部分的軟件設計如下所示： 所有對PaaS訪問的API請求均經(jīng)由API proxy做鑒權控制之后代理到系統(tǒng)內(nèi)部具體的微服務上。PaaS不直接參與租戶的增刪查改，API proxy通過與PaaS外部的Keystone通信來獲取用戶角色以及租戶信息。 三、資源管理 網(wǎng)絡部分 1 由于金融行業(yè)對網(wǎng)絡安全性方面的要求比較苛刻，而Rancher所能夠提供的均是基于某個環(huán)境內(nèi)部的overlay網(wǎng)絡。Overlay必然會導致很多報文無法被安全設備透明的過濾，這是行業(yè)內(nèi)無法接受的；因此，必須采用扁平網(wǎng)絡。 2 處于安全的考慮，會出現(xiàn)同一個stack內(nèi)部的多個service需要分別部署到不同的網(wǎng)絡分區(qū)的需求，采用當前Rancher的managed網(wǎng)絡顯然無法滿足需求；因此，必須支持多網(wǎng)絡。 對于扁平網(wǎng)絡的支持，我在之前的文章（在Rancher 1.2中實現(xiàn)基于CNI的扁平網(wǎng)絡）中有詳細的介紹，主要是使用ebtable直接在linux bridge上對流量做控制，從而避免使用overlay；這樣，外部安全設備能夠透明的看到各個容器之間的流量。 對于多網(wǎng)絡的支持，我們是通過在Rancher之上實現(xiàn)一層抽象邏輯來實現(xiàn)的。整個模型演變?yōu)橐粋€網(wǎng)絡映射為Rancher的一個環(huán)境（環(huán)境內(nèi)部運行一個扁平網(wǎng)絡）。這部分主要涉及對平臺中所有網(wǎng)絡的管理，以及維護租戶與網(wǎng)絡之間的映射關系。 下面舉一個例子來描述該流程： 1 平臺管理員在PaaS上創(chuàng)建一個網(wǎng)絡，指定網(wǎng)絡的參數(shù)（子網(wǎng)掩碼、網(wǎng)關、所屬安全域、所屬隔離域等），這些數(shù)據(jù)會保存到數(shù)據(jù)庫； 2 平臺管理員根據(jù)需要為租戶分配第一個網(wǎng)絡；此時，抽象層需要真正在Rancher上創(chuàng)建出網(wǎng)絡所對應的環(huán)境；以及創(chuàng)建監(jiān)控、日志、以及定制化系統(tǒng)所需的system級別的應用堆棧； 3 當平臺管理員為租戶分配第二個以上的網(wǎng)絡時，抽象層還需要將該Rancher環(huán)境與租戶其他網(wǎng)絡對應的Rancher環(huán)境之間建立env link關系，否則跨Rancher環(huán)境的應用堆棧各service之間無法使用Rancher DNS進行互訪。 存儲部分 客戶PaaS在存儲部分最終選定NFS作為其存儲方案，前期也有討論過使用ceph等，這部分我在之前的文章（探討容器中使用塊存儲）中也有專門分析過為什么不選用那種方案。 由于單個租戶可以擁有多個網(wǎng)絡（也就是多個Rancher環(huán)境），而在Rancher中Rancher-NFS driver所創(chuàng)建volume是基于環(huán)境層面的。為了能夠?qū)⒃搗olume映射到租戶層面，我們在抽象層中做了這層映射操作。 具體流程如下： 1 平臺管理員在PaaS中指定參數(shù)創(chuàng)建出一個NFS server；同網(wǎng)絡一樣，此時只是將數(shù)據(jù)保存到數(shù)據(jù)庫； 2 平臺管理員為租戶分配NFS server，此時抽象層真正操作租戶網(wǎng)絡所對應的多個Rancher環(huán)境，在逐個環(huán)境內(nèi)添加用于提供Rancher-NFS driver的system...
Read More