某股份制商業銀行定制化PaaS介紹
某股份制商業銀行的PaaS平臺是由睿云智合(Wise2C)與Rancher合作，基于Rancher做的定制化開發?；跇I務場景和銀行業的特殊需求，同時為了兼顧能夠實現對以后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