<th id="0poub"></th>
  1. <th id="0poub"><track id="0poub"><dl id="0poub"></dl></track></th><dd id="0poub"><track id="0poub"></track></dd>

    <dd id="0poub"></dd>
    <dd id="0poub"><pre id="0poub"></pre></dd><th id="0poub"></th>
    <th id="0poub"><track id="0poub"></track></th>
    <tbody id="0poub"><pre id="0poub"></pre></tbody>
    <em id="0poub"><acronym id="0poub"><kbd id="0poub"></kbd></acronym></em>
    logo

    地址:深圳南山區大沖國際中心21樓

    聯系我們 : contact@wise2c.com

    產品支持 : service@wise2c.com

    售前咨詢 : sales@wise2c.com

    電話: +86 (755) 33268246

    粵ICP備16049363號

    最佳實踐

    某股份制商業銀行定制化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

    郵政電商平臺“郵樂網”完成容器云平臺項目建設,進一步完善分布式架構系統治理

    眾所周知,容器技術在互聯網電商平臺的應用普及相比傳統企業更早、更為廣泛,2016年10月,郵樂網成為睿云智合第一個互聯網企業客戶。   郵樂網由中國郵政與TOM集團攜手呈獻,是一個結合高端線上網購和線下零售于一體的獨特創新購物服務平臺。中國郵政歷史悠久,線下網絡覆蓋全國,并且擁有完善的物流系統及代收貨款一體化平臺;TOM集團在電子商務領域具備豐富的經驗、先進的科技及應用。雙方互為裨益,以后來者面貌出現的?“郵樂網”,正試圖通過集合中國郵政和TOM集團的資源優勢,以及借鑒雙方在電子商務市場的經驗教訓,來實現在B2C行業的突破。   以高起點、高規格快速搭建的郵樂網電商平臺,核心技術團隊來自滬港地區資深互聯網、金融等領域,在搭建支撐年營收額數百億且高速增長的業務平臺過程中,技術平臺的選型與部署嚴謹而又高效,在全球范圍內對容器云集群管理平臺產品進行了篩選與評估,最終選擇Rancher作為容器云平臺核心框架,由睿云智合提供項目實施與技術支持服務,雙方共同為郵樂網的電商運營平臺提供基于容器的云計算基礎架構解決方案。...

    Read More

    安盛天平借助容器技術提升關鍵業務系統持續運維自動化水平

    在剛剛達成的安盛天平汽車保險有限公司與睿云智合的容器項目合作中,雙方確認,由睿云智合提供全方位的技術支持服務,幫助安盛天平實施應用容器化的持續運維管理平臺建設。雙方將建立長期的技術合作,以逐步實現安盛天平各個關鍵應用系統在接下來分階段、分步驟地完成生產環境容器化后的持續運維管理目標。   安盛天平車險是中國財產險市場上目前以數字化業務為主要核心渠道的兩家公司之一(另一家是平安產險),公司業務系統架構一直以追求靈活響應、高度自動化為目標,是為數不多在信息技術層面能夠快速高效響應數字化業務發展需要的財產保險公司之一。早在2015年末,安盛天平的技術團隊即已投入對Docker技術的研究與學習試用之中,在自行完成了多種容器編排框架產品的內部部署與測試后,最終仍選擇借助第三方技術服務方的力量,與深圳睿云智合共同合作,逐步完成基于自身實際需要的容器化應用持續運維管理平臺的建設,為安盛天平繼續保持在車險數字化業務領域的競爭優勢提供新型容器云技術的有力支持。...

    Read More

    國內首家股份制商業銀行基于容器的PaaS平臺項目正式啟動

    2016年10月,在歷時半年的技術選型和驗證性測試之后,恒豐銀行最終選擇了基于美國Rancher Lab公司提供的容器集群管理平臺來實施輕量級PaaS平臺項目。作為Rancher Lab在中國的戰略合作伙伴,睿云智合承接了該項目的全部研發與實施任務。   恒豐銀行為全國18家股份制商業銀行之一,在極短的時間內完成了公司經營模式和治理架構的大幅改造。由科技驅動業務高速發展的戰略是公司核心經營思路之一,自主研發的各類系統解決方案將直接支持一線業務開展,因此,打造一個內部的軟件生產/交付/運營全生命周期管理平臺(PaaS)變得極為重要。在Docker引領下的容器技術顛覆性發展的今天,PaaS平臺變得更為輕量又易用,將成為企業級用戶IT能力建設的一個關鍵性基礎平臺。銀行業由于面對嚴格的風控與監管要求,在創新信息技術引進落地方面格外謹慎,諸多銀行均在1~2年前即已開始著手基于容器的PaaS平臺建設方案調研,此次恒豐銀行PaaS項目的啟動則率先成為銀行業的第一單,堪稱金融行業容器技術應用項目的一個里程碑。...

    Read More

    長城人壽謀求核心系統架構改造,探索微服務治理解決方案

    2016年10月,睿云智合與長城人壽保險公司達成合作,為其提供系統架構改造與容器技術引進咨詢服務。   長城人壽隸屬北京金融街集團,已在專業壽險領域耕耘十余年,致力于從產品和客戶服務方向走差異化經營路線,樹立自身獨特的保險服務品牌。長城人壽根據細分客戶不斷創新,開發了包括母嬰險、自助養老險和全能健康險在內的一系列高保障保險產品,特別為鋼琴天才郎朗開發設計了十指保險,突顯了保險的保障本質。   進入日益激烈的數字化業務競爭階段后,長城人壽對自身業務系統的靈活、快速響應能力要求也日益提升,業務系統進行架構改造的需求也日益強烈。經過調研選擇,長城人壽選擇與睿云智合進行合作,引進專業IT咨詢服務,針對現行系統架構改造制訂規劃路線和實施方案,同時也對未來基于容器的微服務架構系統治理模式進行了探索與驗證。以這個項目作為起點,從此長城人壽的業務系統架構改造工程正式邁入實踐階段。...

    Read More

    民生人壽保險成為首家將基于容器的DevOps平臺在生產環境落地的金融企業

    2016年中,民生人壽保險有限公司經過技術選型,決定引進睿云智合基于容器的CI/CD產品WiseBuild作為其接下來在IT內部全面推動DevOps的核心平臺。該項目預計在半年內逐步替代原有的應用開發測試運維作業模式,使得民生保險的IT治理模式更加順應新一代分布式架構的核心業務系統的開發&運維要求,顯著提升業務系統軟件的交付效率。   作為民營壽險企業的杰出代表,民生人壽成立十余年來始終堅持貫徹“以用戶為中心”的經營理念,將不斷提升用戶體驗,豐富服務模式,嘗試通過多種渠道為客戶提供個性化、定制化的保險產品作為公司追求的經營目標。而這一業務經營方針對IT支持的要求也在日益提高,在經過反復的“打補丁”方式勉力維持原有核心系統運行多年之后,民生人壽IT團隊決心破舊立新,著手重構一套全新的微服務架構核心業務系統,并且采用容器技術來優化微服務架構系統的治理模式。民生人壽表示,新架構下的核心業務系統重建項目意義極為重大,它很可能帶領民生人壽在未來幾年保險市場風起云涌的激烈競爭格局中突破重圍,一舉超越同類型機構。...

    Read More

    富德生命人壽在保險行業率先啟動容器技術全面實踐應用

    2016年初,富德生命人壽經過大量調研與驗證性測試評估,結束了容器云集群管理平臺的技術選型,選擇睿云智合作為其接下來容器技術應用場景全面實踐項目的技術服務方。   富德生命人壽保險股份有限公司是一家全國性的專業壽險公司,成立于2002年3月4日,總部現位于深圳。在保險行業,富德生命人壽曾創造多個業務創新與高速發展的業績奇跡,其科技團隊技術實力雄厚,應用系統堅持走自研為主的道路,成為行業典范。本次項目旨在引進容器技術,幫助富德生命人壽IT在CI/CD,微服務治理,應用容器化后持續運維,混合云管理等各個場景全面踐行和檢驗容器技術的可用性、可靠性,為未來實現IT整體架構改造,加速IT對業務需求高效、靈活的響應支持奠定基礎。...

    Read More

    在Rancher 1.2中實現基于CNI的扁平網絡

      Rancher 1.2 網絡現狀Rancher 1.2之于之前的版本在很多地方都有顛覆性的更新,今天我著重來談網絡方面。在1.2中Rancher實現了對CNI的支持,通過network-plugin來實現對CNI的調用;另外,network-plugin還實現了如為暴露端口的容器配置DNAT,MASQUERADE等操作。但是,1.2版本也并非徹底的擁抱CNI,原因如下: 01?Network-plugin默認為必選項,其內部自動檢測容器是否expose端口到host,并為容器端口配置DNAT規則;另外,所有容器默認使用docker0經過三層轉發(通過Iptables規則控制)來訪問外網,即全部配置MASQERADE;這一點限制了網絡模型(二層廣播域只能在host內部),將影響到希望使用另一張網卡來實現扁平網絡的用戶;02Network-plugin的啟動依賴于Metadata,而Metadata和DNS server均使用docker0的bridge網絡(IP為169.254.169.250)。即,用戶私有化的CNI網絡必須要能夠訪問到docker0網絡,否則Rancher提供的服務發現與注冊以及其它為業務層提供的服務將不可用。03不支持多個網絡,官方宣稱只能選擇一個CNI網絡,在UI中對所添加的各類型的CNI網絡均顯示為托管網絡。其中系統基礎服務比如scheduler、health check以及load balance默認均只能在托管網絡內工作。如若手工添加了其它CNI網絡,將導致第二個CNI網絡內,scheduler、health check以及load balance異常??蛻粜枨?一??在很多場景中用戶對于容器網絡的使用,還是希望業務與管理隔離,即通過一張獨立的網卡來運行業務流量。二???在混合組網的場景中,用戶一部分業務運行在裸機中,另一部分業務運行在Rancher容器內,將這兩張網絡統一為一張扁平化網絡的呼聲也較大。 解決方案基于Rancher 1.2中CNI的諸多限制,有沒有辦法去實現扁平網絡呢?答案是肯定的!網絡整體拓撲先看一張網絡部署圖,下圖可分為兩個區域,Rancher區域與裸機區域。Rancher區域HOST-1和HOST-2分別為Rancher的agent節點(每個節點有兩張網卡),按業務劃分,該區域內部可以通過容器部署一些變動大、常啟?;虺U縮容的業務。 裸機區域 Host-3以及其它主機為物理服務器(即裸機),按照業務劃分,host-3上可運行一些相對業務對硬件資源要求較高,且不常變動的業務組件。 這兩個區域通過業務交換機二層互聯,如果網絡規模小,這樣的拓撲結果是沒有問題的。如若網絡規模大,需要考慮廣播域的問題,為了避免廣播風暴,一些客戶會使用一些支持SDN的設備來取代業務交換機,從而對二層廣播做限制。  扁平網絡內部(包括兩個區域的所有主機)統一使用外部的路由器做網關,比如圖中,Rancher內部的容器的子網范圍為10.43.0.0/24, IP地址池范圍為10.43.1.2-10.43.1.254。同理,裸機域內,子網范圍為10.43.0.0/24, IP地址池范圍為10.43.2.2-10.43.2.254。   之所以要將管理網絡和業務網路經過同一個路由器(或者防火墻)是因為scheduler需要訪問cattle,即管理網;另一方面,scheduler又需要由CNI網絡中的health check 做健康檢查和故障恢復。若考慮安全問題,可以在防火墻上配置規則,對業務網對管理網的訪問做限制。 Rancher內部CNI網絡內部CNI網絡主要需要解決兩個問題:?一??如何訪問Metadata和DNS server的地址169.254.169.250;二 ?采用獨立的網卡來轉發業務流量后,二層廣播域跨主機了,若每臺主機上還通過同一個IP 169.254.169.250訪問DNS和Metadata服務,如何解決地址沖突的問題; 下圖是宿主機內部CNI網絡的拓撲圖以及流量轉發規則: 由于扁平網絡需要使用自定義的bridge,與docker0無關。同一個network內部的所有容器屬同一個二層網絡,且都不可見169.254.169.250地址。為了讓容器可以訪問該地址,我們采用將br0(CNI bridge)與docker0連通,然后再該鏈路上的流量做限制來實現。具體如下:1、container-1內部有到達169.254.169.250的一條主機路由,即要訪問169.254.169.250需要先訪問10.43.0.2;2、 通過veth-cni與veth-doc的鏈接,CNI bridge下的container-1可以將ARP請求發送到docker0的10.43.0.2地址上。由于10.1.0.2的ARP response報文是被veth-cni放行的,于是container-1能夠收到來自10.43.0.2的ARP response報文。 3、然后container-1開始發送到169.254.169.250的IP請求,報文首先被送到docker0的veth-doc上,docker0查詢路由表,將報文轉到DNS/metadata對應的容器。然后IP報文原路返回,被docker0路由到veth1上往br0發送,由于來自169.254.169.250的IP報文都是被放行的,因此container-1最終能夠收到IP。 4、由于屬于該network的所有的宿主機的docker0上都需要綁定IP地址10.43.0.2;因此,該IP地址必須被預留,即,在catalog中填寫CNI的netconf配置時,不能將其放入IP地址池。 5、 同時,為了保障該地址對應的ARP請求報文不被發送出主機,從而收到其他主機上對應接口的ARP響應報文,需要對所有請求10.1.0.2地址的ARP REQUEST報文做限制,不允許其通過br0發送到宿主機網卡。 具體轉發規則對應的ebtables規則如下所示:Drop All traffic from veth-cni except:1、 IP response from 169.254.169.250 2、 ?ARP response from 10.43.0.2 ebtables -t broute -A...

    Read More