<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號

    睿云新聞

    深圳睿云智合科技有限公司 > 睿云新聞 (Page 3)

    我們應該如何基于容器來進行軟件的持續交付

    在過去的一段時間里容器已經大量的使用到了IT軟件生產的各個環節當中:從軟件開發,持續集成,持續部署,測試環境到生產環境。   除了Docker官方的DockerSwarm,DockerMachine以及DockerCompose以外,開源軟件社區還涌現了一系列的與容器相關的工具,涵蓋了從容器編排,調度,監控,日志等等各個方面的需求。   本文將從軟件研發流程出發討論如何基于容器解決軟件的持續交付問題,以及團隊協作問題。并為大家展示睿云智合(Wise2C)的持續交付平臺是如何基于目前最先進的軟件開發流程思想設計出來的。   在持續集成中使用容器   構建環境統一管理   在傳統模式下使用持續集成工具諸如Jenkins,在部署企業持續持續集成平臺的第一個問題就是多樣化的構建構建環境需求,而通常的做法是將構建Agent(服務器或者虛擬機)分配給團隊由團隊自己管理構建服務器的環境配置信息,安裝相應的構建依賴等。   在持續集成中使用docker dockerrun--rm-v`pwd`:/workspace-v/tmp/.m2/repository:/root/.m2/repository--workdir/workspace?maven:3-jdk-8/bin/sh-c'mvncleanpackage'   如上所示,我們可以非常方便的通過容器來完成軟件包的構建,其中有幾個點需要注意的是: ?--rm命令可以確保當命令執行完成后能夠自動清理構建時產生的容器,我想你應該不太希望需要不定期清理構建服務器磁盤的問題吧。   ??-v除了將當前源碼掛載到容器當中以外,我們還可以通過掛載磁盤來緩存一些構建所需的依賴,比如maven下載的jar包,從而提高編譯效率。   ??--workerdir用以指定構建命令執行的工作路徑,當然需要和workspace保持一致。   如上,基于容器我們可以快速搭建適應多種構建需求的CI構建環境,所有需要的一起就是你的構建服務器上需要的只有Docker。   在持續集成中使用docker-compose   在某些情況下,在構建或者集成測試階段我們可能需要使用到一些真正的第三方依賴,比如數據庫或者緩存服務器。在傳統的持續集成實踐中,通常要么你直接使用已經部署的數據庫(記得清理測試數據,并發如何保證),直接使用內存數據庫來代替真實數據庫,要不使用mock或者stub來進行測試。   當然在理想情況下我們還是希望能夠使用與真實環境一直的真正的數據庫或者其他中間件服務?;赿ocker-compose我們可以非常方便的實現對于復雜構建環境的需求。   build:?command:sh-c'mvn--help'?image:maven:3-jdk8?links:[mysql]?volumes: -'.:/code' -'/tmp/.m2/repository:/root/.m2/repository'?working_dir:/codemysql:?environment:{MYSQL_DATABASE:test,MYSQL_PASSWORD:test,MYSQL_ROOT_PASSWORD:test,MYSQL_USER:test}?image:mysql:5.5   同樣我們以maven為例,假設我們需要在構建中使用到mysql以支持集成測試的需求   docker-composerun--rmbuildsh-c'mvncleanpackage'&&docker-composestop&&docker-composerm-f ?--rm確保在構建命令執行完成后自動清理build所產生的容器。 ?-docker-composestop&&docker-composerm-f確保依賴的其它服務如mysql能夠正常的退出并且清理所產生的容器。   建立持續交付解決方案 建立基于共同目標的具有跨職能協同的研發團隊,是DevOps運動的根本。而自動化則是提高效率的基石?;谝陨衔覀兪侨绾位谌萜鹘⑽覀兊某掷m交付解決方案?   基礎設施自動化   使用Rancher理由很簡單,Rancher是目前市面上唯一一個能滿足開箱即用的容器管理平臺,同時能夠支持多種編排引擎,如Rancher自己的Cattle,Google的K8S,以及Docker官方的Swarm作為容器編排引擎。同時Rancher提供的Catalog應用商店能夠幫助研發團隊自主創建所需要的服務實例。   創建持續交付流水線   建立持續交付流水線的核心問題是如何定義企業的軟件交付價值流動。   如下圖所示,我們總結了從開發,持續集成,持續交付各個階段所使用的一些典型工具的使用,以及在各個階段中的相關團隊的相關活動,典型的DevOps相關的活動。   在持續交付流水線下的團隊協作   正如上文所說,創建持續交付流水線的本質就是定義軟件的交付的價值流動,反應正式的軟件交付流程。價值的流動則涉及到團隊中各個職能的成員的高度協同。   開發流水線   開發人員:頻繁提交持續集成,通過持續的編譯,打包,測試,鏡像構建,自動化驗收測試等環節產生可測試的候選鏡像列表(如:0.1-dev)。   ?以源碼倉庫為起點,開發人員頻繁提交,每一次代碼變更都要立即在流水線中傳遞;睿云智合WiseBuild持續交付平臺支持定時周期觸發,代碼變更檢查以及Webhook等多種觸發方式。   ?提交測試階段從技術角度斷言整個系統是可運行的,該階段會進行編譯,運行一套單元測試,并進行代碼質量分析,WiseBuild持續交付平臺設計遵循“BuildInDocker,BuildWithDocker,RunWithDocker"基于容器技術全面減少對于異構構建環境的支持,并且默認提供了當前主流的編程語言的編譯,以及測試支持。同時用戶可以根據需要在持續交付流水線中集成Sonarqube進行代碼的質量跟蹤和管理。   ?自動化測試階段,從功能交付斷言整個系統是能夠滿足客戶規范和要求的,WiseBuild持續交付平臺支持基于Rancher或者RancherCompose在流水線中自動部署鏡像到Rancher平臺,同時內置了Selenium,Robotframework,Cucumber等主流自動化測試工具和框架。   ?手動測試階段,當新的代碼提交部署到rancher環境后,開發人員同時可以快速的進行手動測試,確保新提交的代碼在測試環境中是可用的,并且滿足相關的功能需求。   ?鏡像構建,當代碼提交通過了整個流水線的持續驗證后將會產生響應版本的鏡像文件。   基于流水線中的過程質量和代碼質量數據,團隊可以快速處理典型的代碼質量問題,避免技術債務的產生。 總而言之,開發流水線可以幫助團隊頻繁的進行代碼集成并且通過單元測試,代碼靜態分析,自動化驗收測試等技術實際幫助開發人員快速的發現和解決問題,并且產生可待測試的鏡像列表。   測試流水線   測試人員:從候選測試鏡像列表中,選擇需要測試的目標鏡像,標記為測試版本(將0.1-dev標記為0.1-test),并且將待測試鏡像自動部署到驗收測試環境,完成手動探索性測試,對于已測試完成的鏡像標記為預發布版本(0.1-test標記為0.1-beta)。   在待測試鏡像列表中選擇鏡像,發布到開發用DockerRegistry倉庫。 對于測試人員而言,流水線的起點則變為待測試的鏡像列表,基于WiseBuild創建Docker類型流水線,可以支持測試人員快速創建測試環境并且運行相關的自動化測試腳本,同時滿足手動探索性測試的需求。   支持使用自動化觸發方式,如‘1.0.*-beta’的形式,當監聽dockerregistry有符合規則的鏡像產生后自動觸發流水線。   支持手動觸發,測試猿人可以手動選擇服務該規則的鏡像進行手動觸發,一鍵準備測試環境,運行自動化驗收測試等。   自動化部署流水線   運維人員:從預發布鏡像列表中選擇鏡像部署到預發布環境,并且在驗證通過后標記為release版本(如將0.1-beta標記為0.1-release),并且發布到生產環境。   與自動化測試流水線相同,運維人員可以建立獨立的部署流水線,從待發布的鏡像列表中選擇鏡像發布到生產環境Registry中,并且設置流水線的自動或者手動觸發,實現對于預生產環境的一鍵部署。   小結 睿云智合的WiseBuild持續交付平臺支持對接基于DokcerRegistry標準的鏡像倉庫服務,包括DockerHub,DockerRegistry,Habor,阿里云等等。 在基于容器的持續交付實現方案當中,我們以鏡像為價值傳遞的單元,通過鏡像的持續測試以及驗證,完成鏡像從開發,測試到可發布的狀態轉變,完成軟件的交付流程。   ?開發人員頻繁提交,持續集成,持續反饋。 ?測試人員自服務部署一鍵準備測試環境。 ?運維人員執行一鍵式部署預生產環境。...

    Read More

    容器技術幫助傳統金融企業顯著提升IT能力的最佳實踐

    2015年曾沖刺入全行業保費發展規模前三的富德生命人壽,作為一家在業界連年刷新保費增速記錄的創新性金融機構,近幾年進入集團化經營發展戰略階段后,在更多的業務內容創新、業務渠道創新、業務結構優化改造方面始終走在行業尖端。   而這一切的業務發展成績離不開強大的IT技術支持與引領,尤其是在應對互聯網金融業務市場的激烈競爭時,IT能力的對決往往決定著業務發展的優劣。2015年下半年,富德生命人壽與中國平安科技——這兩家傳統金融機構科技創新力量的優秀代表,幾乎同時開始啟動了對容器技術的調研與引進,并在歷時大半年的選型與方案驗證測試后,各自完成了自己的容器技術應用項目。   作為領先并專注于金融行業容器技術與產品服務的合作伙伴,睿云智合(Wise2C)非常榮幸地參與了這兩個率先邁出行業探索和實踐步伐的項目實施過程,并且在其后為更多金融企業用戶提供了我們的專業產品與技術服務,積累了目前遙遙領先市場同業的成功案例。   下面就讓我們來看看富德生命人壽容器技術應用案例的具體解析。   項目目標場景 富德生命人壽的容器技術應用場景可以說在傳統金融企業中是最為全面、最為豐富的案例之一,非常具有代表性。其項目需求具體包括:   ?在引進容器技術之前,富德生命人壽已經將核心業務系統解耦為六十多個業務模塊,正在嘗試系統架構的微服務化治理,而容器技術剛好可以在有限的基礎設施及人力資源條件下幫助實現高效部署和運維這些微服務模塊。 ?作為大部分業務模塊自研為主的IT團隊,業務軟件的生產過程大幅提升自動化管理水平也迫在眉睫,CI/CD平臺建設很早就已在富德生命人壽進行實施,容器技術的助力使得這一平臺的使用將變得更加高效、流暢。 ?作為大力開展互聯網創新業務的金融企業,混合云架構支持下的諸多互聯網應用需要在安全可靠的前提下解決高并發計算資源的彈性伸縮和業務靈活遷移,容器管理平臺正是解決這一剛需的最佳利器。 ?支撐富德生命人壽核心系統運行的計算資源每天差不多有一半時間沒有任何業務流量,然而大數據團隊的計算資源卻非常緊張,富德生命人壽希望將大數據平臺部署在容器化環境中,可以有效提高計算資源在不同運行時段的合理利用,真正實現云計算資源的科學管理。   技術實現方案 整體技術方案: 富德生命人壽基于容器技術設計了兩個中心:軟件持續交付中心和系統持續運行中心,第一期方案將主要支撐壽險業務的核心系統從軟件開發測試,部署上線到持續運行全流程管理。   生命人壽IT平臺架構部經過近一年的廣泛調研,分析和驗證性測試,最終采用了如下整體技術方案: ?容器管理平臺采用Rancher,?為上層應用提供容器化的基礎設施和容器化應用的運行環境,以及基礎性容器服務。 ?持續交付中心,在睿云智合的WiseBuild基礎上,實現了針對目前研發,測試,運維流程的集成和定制開發。 ?在容器管理平臺之上,與睿云智合的產品WiseRun設計思路一致,雙方合作研發了持續運行中心,高效管理復雜業務系統的建模,部署過程,以及全面的系統應用監控,配置中心和日志中心。   應用容器化和持續運營中心 ?將應用容器化,實現業務系統在多環境的一鍵部署; ?引入容器管理和編排平臺(Rancher),實現開發,測試,生產環境的自動化和底層基礎設施的適配,以提供應用的運行環境,屏蔽底層基礎設施差異; ?實現應用的自動化部署及后續生命周期管理; ?結合持續交付中心,實現業務系統的持續部署。   構建基于容器的交付中心 ?將開發環境,測試環境和應用環境容器化,實現環境“一鍵部署”,及大規模構建環境的自動創建和復制,實現開發,測試和預生產環境的一致性和標準化交付; ?實現持續構建服務,代碼管理服務,并支持并行、彈性地自動構建服務。 混合云管理 項目中睿云智合(Wise2C)技術團隊為富德生命團隊完成了市場幾乎所有主流的公有云主機以及私有環境混合場景的基礎設施架構搭建測試及驗證,為富德生命人壽未來的IT資產投入規劃提供了有力的數據支持。   大數據平臺容器化及自動化部署 項目中睿云智合(Wise2C)技術團隊幫助完成了包括Hadoop以及HDFS、YARN、HBase、Hive、Kafka、Zookeeper等大數據組件的容器化集群部署,并全面實現了高可用特性以及平臺的彈性伸縮能力。   建立了在非忙時段使用業務計算資源快速啟動大數據集群進行自動化數據處理的科學機制。 項目中關鍵技術點 日志收集方案 項目中我們根據富德生命人壽的實際情況設計了一個低資源資源消耗,無應用侵入,可以清楚識別日志來源的統一日志收集方案。請參閱往期微信分享容器內應用日志收集方案   監控告警方案 富德生命人壽在監控方面的需求主要包含以下四個功能點,日志采集,告警,存儲以及展示。目前業界流行的方案中只有prometheus是作為一個整體的方案可以同時滿足這四個功能,但是prometheus的默認的存儲方式是本地存儲,對opentsdb這種分布式的時間序列數據庫支持不夠,在擴展性上不夠好。所以我們為富德生命人壽設計了一種組合式的方案采用cAdvisor+scollector+Bosun+OpenTSDB+Grafana實現監控告警需求功能。各個組件之間都有官方支持,所以兼容性有足夠的保證。...

    Read More

    將DevOps用到生產環境的民生保險容器應用云平臺

    作為傳統金融機構重要代表的保險行業,許多企業的關鍵業務運營幾乎毫無例外地依賴著一個笨重而陳舊的單體架構核心業務系統,其牽一發而動全身的復雜特性,使得諸多所屬企業IT團隊在面對企業“以客戶為中心”、“互聯網+”等發展戰略所帶來的排山倒海般的業務需求時,往往疲于奔命,甚至舉步維艱。   除了系統架構本身的問題,大部分中小型金融機構,在業務軟件的交付與運營管理方面,長期依賴核心業務系統供應商所提供的定制研發服務,缺乏對軟件生產過程的高效管理,也使得大家在面對新一代業務系統架構改造過程中要求的持續交付/持續運營這一艱巨挑戰時深感力不從心。   作為民營壽險企業的杰出代表,民生人壽成立十余年來始終堅持貫徹“以用戶為中心”的經營理念,將不斷提升用戶體驗,豐富服務模式,嘗試通過多種渠道為客戶提供個性化、定制化的保險產品作為公司追求的經營目標。而這一業務經營方針對IT支持的要求也在日益提高,在經過反復的“打補丁”方式勉力維持原有核心系統運行多年之后,民生人壽IT團隊決心破舊立新,向業內標桿企業看齊,著手進行新一代核心系統的規劃與建設。   重構一套全新的微服務架構核心業務系統,并且采用容器技術來優化微服務架構系統的治理模式,這樣的戰略規劃不可不謂大膽而創新,因為在業界至今仍未有完整的成功先例。民生人壽IT團隊上下都對這一項目寄予了極高的期望,大家一致認為,新架構下的核心業務系統重建項目意義極為重大,它很可能帶領民生人壽在未來幾年保險市場風起云涌的激烈競爭格局中突破重圍,一舉超越同類型機構!   睿云智合(Wise2C)承接了其中一項光榮而艱巨的任務:從2016年中開始,分階段為民生人壽建設基于容器的企業級PaaS平臺,包括開發者中心和運維中心,以幫助民生人壽在新架構核心系統搭建過程中實現高效的持續集成和持續部署自動化管理,并在未來進一步實現自動化運維管理。   項目目標場景 第一階段建設開發者中心,為民生人壽新一代核心系統的項目開發提供完整的基于容器的持續集成解決方案,實現從代碼提交到容器化部署的完善的DevOps工具鏈和工作流,促進微服務模塊開發和上線的標準化、自動化,提高新一代核心系統的開發迭代效率。   第二階段建設運維中心,為日后新一代民生人壽核心系統提供微服務運行框架以及自動化運維能力,實現持續部署服務、自動化彈性伸縮、自動故障恢復、靈活遷移、高級的服務編排以及高級的日志監控管理等能力,同時滿足業務以及平臺的高可用性要求。   技術實現方案 網絡方案 本項目中睿云智合(Wise2C)為民生人壽兩個數據中心四個業務網絡區搭建了生產災備兩套平臺環境。各業務網絡區域均有獨立的冗余接入交換機及網絡防火墻設備,通過連接核心交換機及可選的負載設備實現數據流的策略控制及業務分隔。各區域間業務流量不允許互相訪問。睿云智合根據民生現有網絡架構進行了容器平臺網絡的規劃設計,實現了業務、管理以及存儲的三網分離。 存儲方案 使用convoy組件連接NAS提供容器存儲。 平臺高可用(HA)方案 平臺的的高可用(HA)部署采用3臺主機節點,并且連接一個共用的外部的數據庫。同時采用Haproxy代理以實現對三臺HA節點的服務檢查及訪問切換策略。   MySql集群方案 容器管理平臺需要使用外部數據庫,以支持平臺高可用架構。我們設計采用PerconaMySQL數據庫集群方案,PerconaServer為MySQL數據庫服務器進行了改進,在功能和性能上較MySQL有著很顯著的提升。   高可用鏡像倉庫方案 高可用私有鏡像庫我們采用Harbor實現,使用Harbor提供的基于策略的Docker鏡像復制功能實現鏡像在兩個環境的同步共享.該方案的優點是利用本地存儲,成本低并且可以實現較快的故障轉換。 日志方案 使用睿云智合自研日志收集工具WiseLog對接ELK,實現每個應用容器掛載一個專屬的日志卷容器,不會存在應用寫日志路徑沖突的問題。同時,WiseLog容器內有logstash進程收集指定的日志文件,通過進程定時查詢獲取宿主機上新增的日志卷容器,并根據模板重新生成logstash的配置文件,將新增的日志文件加入收集列表。   WiseLog可以獲取新增日志卷容器在rancher平臺上所屬的Stack,Service和Index,即使一個應用容器被調度到另外的主機,仍然可以通過Stack_Service_Index作為標識,在邏輯上將日志拼接起來,對于復雜的日志收集邏輯,也可以可以通過logtype的標簽區分不同的應用,設置不同的日志收集路徑。   監控方案 采用Prometheus+Grafana監控方案部署。實現對容器宿主機以及容器本身的日志采集,告警,存儲以及展示。   持續交付平臺方案 睿云智合在民生人壽生產環境容器管理平臺上部署了持續交付平臺WiseBuild,用來支持核心系統架構改造項目中每一個微服務模塊的開發工作。 多個微服務模塊開發小組可以同時在統一的WiseBuild平臺上進行微服務模塊開發過程的全生命周期管理與協作,以流水線為中心,實現從代碼構建,測試到部署的端到端自動化能力。 同時,WiseBuild的流水線任務動態分配并容器化執行,構建環境可以動態,彈性擴張,可以支持民生人壽大規模的持續集成和部署活動。 通過WiseBuild提供的代碼質量分析,自動化測試和發布決策等質量控制體系,民生人壽將為開發外包人員設立質量門,減少外包開發人員技術能力差異以及人員流動所帶來的技術債積累風險。同時WiseBuild集成的各類自動化測試框架可以滿足民生人壽的提高自動化測試覆蓋率的需要。 通過WiseBuild,民生人壽將持續優化軟件開發過程的管理流程,逐步實現開發過程的自動化程度以及IT交付效率的提升。通過在項目中持續的流程優化與團隊交付能力的提升,逐步加速新一代核心系統架構改造項目的開發進程。   結語 眾所周知,重構核心業務系統,并且是用最新的架構與技術重構一套沒有多少先例可循的核心業務系統,這樣的挑戰并非是以傳統而保守著稱的金融機構敢于輕易嘗試的項目。相信民生人壽IT團隊的專業性、先進性都將在這一項目的實施過程中得到充分體現和鍛煉,這一項目也必將隨著實施成果的逐步顯現成為行業中的優秀典范。作為與民生人壽IT同仁們一起并肩戰斗的合作伙伴,睿云智合(Wise2C)將全力以赴,持之以恒地協助民生人壽共同迎接并贏得這場艱難的挑戰!...

    Read More

    中國第一家推出容器云服務的金融行業云:平安金融云

    作為國內綜合金融卓越典范的中國平安集團,IT引領業務發展是其多年踐行的企業科技發展戰略,憑借多年積累的技術與團隊經驗,平安科技強大的IT能力始終為行業所矚目。而平安的云計算戰略,不僅僅著眼于平安集團自身,更期望立足于整個金融行業(和國內其他一些金融巨頭的定位一樣?。?,在科技服務自身發展的前提下,逐步謀求將先進而豐富的IT能力與基礎設施資源對外進行輸出,以科技的力量推動行業整體發展。而對于行業中的中小機構同業來說,在符合信息安全要求的前提下,標桿企業的專業技術與強有力的IT基礎設施平臺,是他們非常樂于學習和借力的先進資源,可以更快、更便利地獲得專業的技術平臺解決方案,這有利于他們將有限的人力物力更專注地投向業務應用層面的需求響應。   平安科技正是在這一戰略前提下開始致力于打造金融行業領先的“平安金融云”,恰逢標志著Cloud2.0時代到來的容器技術傳入中國,其諸多革命性的技術優勢很快引起了平安技術先行者們的積極關注。及至2015年下半年,平安科技決定在新的平安云平臺建設項目中,正式啟動對容器技術的選型與引進。 項目目標場景 框架選型 在提供容器服務之前,平安云平臺已經在為用戶提供云主機、云存儲等一系列企業公有服務,為了實現快速對接平安云已有IaaS平臺并提供全面的容器云運營管理能力,平安科技在容器管理平臺框架選型方面提出了以下選型要求: 架構簡單,能夠快速部署,易維護。 開源,貼近主流社區和原生平臺。 支持多租戶,能夠嚴格的隔離和必要的互通。 支持VPC網絡降低對網絡的依賴。 符合容器服務規范的Stack、Service、Container領域模型。 完備、豐富的RestfulAPI。 跨平臺支持好,能夠適應混合云部署模式。 經過一系列的驗證與測試平安科技最終在K8S,Mesos+Marathon以及Rancher之間選擇了我們的Rancher平臺作為容器服務平臺基礎框架。 自助服務 過去,開發測試人員做應用的開發測試工作時往往需要通過繁雜的內部資源申請流程獲取開發測試環境。過程中常常需要與運維團隊中負責各個基礎設置資源管理以及數據庫、中間件管理的成員進行多次溝通。無形中增加了時間成本溝通成本,同時所申請的環境在使用之后沒有有效的資源回收機制造成了大量的資源浪費。 為了解決上述問題,平安科技通過容器服務平臺為租戶提供自助開發測試容器環境創建服務。租戶可以自助在平臺上快速部署所需服務與環境,并且在平臺所分配的資源池中使用或釋放開發測試容器環境作用資源。同時自助的在平臺上完成鏡像管理、應用編排、服務集群管理、容器管理等一系列工作。 持續交付 提供API對接平安已有的開發管理平臺Wizard,為CICD流水線提供容器運行環境,實現全流程部署自動化。 技術實現方案 服務架構 平安云統一管理區 容器服務門戶 門戶系統,提供容器服務操作。 基于lvs+keepalived部署架構,外接mysql集群。 統一管理節點 采用Ansible,用于部署多租戶容器環境,添加主機,初始化Registry等節點管理。 平安云公共服務區 Rancher服務 核心服務組件,主要用于容器調度與部署。 基于lvs+keepalived部署架構,外接mysql集群。 Docker節點 用于鏡像制作、上傳、下載,文件傳輸,執行Docker命令。 PublicRegistry 平安官方公共鏡像倉庫,同時是官方公共租戶的鏡像庫。 采取多節點掛載共享盤部署。 租戶VPC 租戶環境 每個租戶擁有完整容器部署和運行環境,包括RancherServer、Docker節點、PrivateRegistry。 隔離與其他租戶之間的影響,減少跨租戶的網絡訪問。 容器網絡 對外:ContainerBridge,采用端口映射。 對內:容器之間直接使用容器管理平臺框架Rancher自帶的IPsec隧道實現。 如果某個容器需要對外服務,則采用端口映射方式,連通所在vm,就可以暴露服務。 如果容器不需要對外提供服務,只需要在同個應用內提供服務,那么采用ipsec方式,這樣避免浪費過多端口。 容器與容器之間建立私有網絡,只有容器與容器之間可以訪問。每個容器都擁有一個私有網絡地址:10.42.網段。 容器存儲 根據Docker官方提供的所有存儲驅動的成熟度??梢钥吹侥壳癙roduction-Ready的是AUFS和DeviceMapper。 目前平安科技容器服務統一運行在CentOS,還沒使用其他操作系統。因此選擇DeviceMapper作為容器存儲驅動。DeviceMapper底層直接使用云磁盤作為pool,采用LVM管理。 除了容器和鏡像存儲外,應用數據存儲,包括配置文件采用了volume接口或者直接volume映射來解決應用容器漂移的數據問題。 日志 容器服務平臺日志:本地+云平臺ELK日志服務。 容器自身運行日志:本地云磁盤+云平臺ELK日志服務。 容器內應用(業務方)日志:業務自行規劃,已經提供目錄掛載。 容器監控 主要依賴Rancher平臺自帶的主機與容器的監控功能,同時,通過腳本,定時獲取容器本身的性能監控(cpu/mem/network/storage)數據,能夠在portal上查看。 1、主機監控 2、容器監控 3、特定的中間件監控 平安研發了基于zabbix/open-falcon的監控平臺用來提供常見中間件的性能監控(WebLogic/Tomcat/Nginx等),為中間件鏡像制作腳本,中間件監控程序整合到Docker鏡像中,容器一啟動,就能即時上報性能數據到監控平臺,無需任何外部干預。 鏡像管理 針對鏡像管理,平安科技進行了從單節點->雙節點->跨區域分布式架構的演進。 通過自行開發的服務組件實現對不同區域數據中心的跨區域分布式鏡像管理,每個區域都部署一套,對接本區域的私有鏡像庫。一方面監聽當前區域的鏡像倉庫事件,然后主動發起同步操作。另一方面:執行Dockcer命令,管理該區域的所有運行容器的機器。 項目成果 經過大半年的設計、驗證、實施,平安科技以全球領先的容器云開源技術框架(Rancher)為核心,自主研發為主,圓滿完成了平安云CaaS容器服務平臺的建設,實現了為平安集團旗下各個金融類別和擁有不同開發模式的子公司用戶,提供物理機、虛擬機、容器等滿足不同種類計算需求的計算資源服務的總體目標。并于2016年嘗試面對公眾市場發布推廣,成為金融行業走向容器云平臺公共服務的第一家機構! 結語 睿云智合(Wise2C)作為Rancher在金融保險行業的獨家總代理,有幸成為這一歷史性重大項目的合作伙伴,新的一年我們將一如既往地為平安金融云的不斷發展提供更多專業、高效的服務。 同時,我們也非常高興受邀參與到了更多不同運營方向的其他大型金融機構的容器云平臺建設項目,為此我們正不斷完善自身的系列容器技術平臺產品,希望將我們的項目經驗和技術能力,完整而快捷地交付給更多的企業用戶!...

    Read More

    熱烈祝賀睿云智合獲得高新技術企業認定

    經過嚴格的技術考察與業務評估,日前,深圳市高新技術產業協會致函深圳睿云智合科技有限公司,對睿云智合(Wise2C)的高新技術企業資質申請予以認定。   作為一家在云計算技術領域起步不足兩年的企業,獲得國家和深圳市相關產業協會的權威認定,充分證明了睿云智合技術團隊在產品研發和技術服務方面的專業性達到了行業先進水平。...

    Read More

    睿云智合(Wise2C)持續為容器技術開源社區貢獻力量

    Docker公司在Austin舉辦的DockerCon2017上宣布,Docker Hub的全球鏡像下載次數截至目前為止已超過120億次。而2016年的DockerCon上,這個數字是41億次。Docker 奇跡般的發展背后離不開全球開發者與技術公司對docker社區的貢獻。截止目前,Docker項目的社區貢獻者已經達到了3300多人。     睿云智合(Wise2C)容器技術團隊自組建以來已經與十余家金融保險企業簽訂了容器技術平臺相關項目合同。在企業落地實踐過程中睿云智合(Wise2C)積累了大量的容器技術落地實踐經驗并解決了諸多落地實施時面臨的技術障礙。如今睿云智合(Wise2C)除了繼續通過持續迭代的產品以及專業技術服務幫助企業實現容器技術落地之外,也參與到積極為docker社區貢獻力量的活動中去,致力于幫助推進docker技術的進一步成熟與完善。在STACKALYTICS最新的數據顯示,睿云智合(Wise2C)的社區commit貢獻數排名已經躋身全球企業貢獻者Top50。?未來睿云智合(Wise2C)將在容器技術社區中持續投入資源,為容器技術的發展貢獻力量。   隨著Docker的日趨成熟,容器技術在全球范圍內的應用越來越廣泛,國內的企業IT對于容器技術也從過去的試用調研轉向現在的真正落地。睿云智合(Wise2C)將密切追蹤這一領域的技術發展趨勢,憑借業界領先的產品以及豐富的落地經驗為國內企業提供專業的技術服務。...

    Read More

    軟件著作權

    睿云智合(Wise2C)研發團隊通過不斷的技術創新,目前已經自主研發出多款軟件產品,所有軟件產品均已獲得軟件著作權。目前睿云智合云計算系列軟件產品已被應用在各個企業級客戶項目中。   軟件產品包括:   WiseBuild軟件軟件持續集成平臺   WiseRun新?代容器?PaaS平臺   WiseCloud應用云平臺   WiseCMP云管平臺Vmware虛擬機管理工具軟件   Hadoop?大數據集群部署平臺   WebSphere應?用?自動部署和發布工具   睿云智合容器?鏡像管理理系統   睿云智合應?用堆棧管理理系統   WiseCloud通用云平臺快存儲服務SAN驅動軟件...

    Read More

    ISO9001認證

    隨著我公司業務的不斷擴大,為了適應發展的需要,盡快與國際接軌為客戶提供更優質的服務,引入ISO9001國際質量體系標準已成為迫切需要。   2017年3月23日,經授權公司認證專家的嚴格審核,國家質量體系委員會認可,我司管理體系符合ISO質量管理體系要求,獲得GB/T19001-2016/ISO9001:2015認證證書。本次通過認證的范圍如下:云計算的開發與銷售、云計算服務;網絡設備及軟硬件的開發、銷售與維護;計算機系統集成、網絡技術開發與銷售;經營電子商務;信息化平臺銷售及提供相關方案與技術服務;計算機鄰域內的技術開發、技術咨詢、技術服務、技術轉讓。   睿云智合(Wise2C)的質量管理本著“適應國際化大趨勢的環境,借助實施ISO9001質量管理體系提高企業的管理水平,更進一步滿足客戶要求以及不斷提高服務與產品的質量和技術含量”的質量方針,努力提升在企業客戶中的服務能力以及服務質量。目前睿云智合(Wise2C)已為多家金融保險行業企業提供了容器云平臺產品以及專業技術服務,在金融行業樹立了多個容器技術落地的標桿案例。   睿云智合(Wise2C)全體員工將再接再厲,按照質量管理體系的要求執行,使我公司的質量管理體系持續改進,不斷提高,更好的為客戶提供優質服務及產品。 ...

    Read More

    關于持續交付你準備好了嗎?

    分享人:鄭云龍 時間:2016-8-25 睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。   持續交付理論要解決的最重要的問題就是,如何以最快的方式將我們的軟件交付到客戶手上;如何實現可靠,迅速并且低風險的軟件發布。   在傳統的軟件開發方法中我們更多的關注軟件研發環節,而DevOps運動則將軟件研發活動的視角從傳統的需求,開發,測試等活動延伸到了部署,發布以及運維過程中。 軟件的核心價值是為軟件的使用者帶來收益,在過去我們經常聽到開發人員說這個功能已經開發完成了。?但是在持續交付中我們認為之后將特性真正的發布到用戶手上才以為則完成。 持續支付     而要想達到持續交付的目標即實現可靠,迅速并且低風險的軟件交付需要所有相關人員(需求,開發,測試,運維)的協同工作才能保證這一目標的實現。 在持續交付過程中我們希望一個團隊是能夠充分自治的,能夠完成從軟件的需求,設計,開發,部署以及運維的端到端所有工作。 全功能團隊         本文將以持續交付的8個原則來闡述在持續交付過程中的那些方法和實踐:   原則一:為軟件的發布創建一個可重復且可靠的過程 在傳統的軟件研發模式中瀑布式的工作方式深入到軟件研發的各個環境。 在軟件的發布過程中充滿了各種等待: 構建和運維人員在等待說明文檔或者缺陷修復 測試人員等待“好的”版本構建出來 研發團隊可能在新功能發布幾周后才收到缺陷報告 最終的結果就是軟件產品遲遲不能發布甚至延期,同時由于開發與測試,開發和運維之間的過長的反饋周期直接導致軟件產品的質量低下,同時可能并不能真正的為使用者帶來價值 同時如果管理者想要對整個軟件交付過程進行改善將會很容易陷入到局部優化的惡性循環當中,很難真正了解交付的問題瓶頸 而持續部署流水線則是解決這一問題的最佳方式,建立持續部署流水線即建立了一套端到端的軟件交付流程,同時在持續部署流水線的流程當中參與到軟件交付的各個角色都能各司其職,形成一套高效的“拉動系統” 開發人員持續的查看代碼度量數據以及測試失敗等問題,測試人員自助部署測試環境,同時運維人員也可以通過一鍵方式將軟件部署到預生產環境以及生產環境。同時對于管理人員也可以通過度量持續部署流水線的各個環境來分析交付問題,通過合理的方式優化軟件交付流程當中存在的問題。 而將持續部署流水線中的各個環節可以劃分為如下幾個不同的階段 提交階段 該階段主要從技術層面證明軟件系統是可以工作的,該階段會進行軟件的編譯,以及以單元測試為主的自動化測試,以及代碼分析 自動化驗收測試階段 該階段主要從功能和非功能需求角度正面軟件是能夠滿足用戶的需求以及相關的需求驗收條件 手動測試階段 該階段主要試圖發現那些自動化驗收測試不能覆蓋的缺陷,同時證明系統是否能夠真正的為用戶提供價值,所以在該階段中通常需要由測試人員完成相關的探索性測試,集成測試以及用戶驗收測試 發布階段 發布階段則旨在將軟件產品發布到用戶手中包括軟件包發布或者是直接將軟件部署到生產環境   原則二:將幾乎所有事情自動化   為了搞笑的支持持續部署流水線,我們需要將除了探索性測試以外幾乎所有的事情都自動化。 在軟件交付過程中對于自動化我們可以分為兩個方面,一方面是指在產生軟件包過程中的如:編譯,打包,單元測試,集成測試,自動化驗收測試等活動。 自動化構建 在這個過程中我們使用例如maven,gradle這樣的構建工具可以幫助自動化的完成軟件的構建以及解決軟件依賴問題 自動化測試 同時借助諸如robotframework,以及cucumber這樣的自動化測試工具,以及采用BDD或者ATDD的開發實踐能夠幫助我們產生高質量的自動化驗收測試集 基礎設施及代碼 在虛擬化技術和容器化技術盛行的今天,通過諸如AWS的CloudFormation以及Docker的Dockerfile等我們可以將我們的基礎設施也變成自動化的 另一方面則涉及到與軟件運行相關的自動化如包括基礎設施的自動化管理,運行環境的自動化配置,軟件本身的安裝與配置等等 自動化配置管理 自動化配置管理工具如ansible,puppet,chef等相比傳統的腳本。通過dsl環境描述的過程將服務器環境的準備過程變成自動化的,可重復的,并且能夠支持大規模的集群管理   原則三:把所有東西納入版本控制   在過去通常而言我們的svn或者git當中只存在我們源代碼本身,而在持續交付過程當中我們認為任何會對軟件的行為,質量產生影響的部分都應該要做版本化的,并且這些任何部分的每一次變更都應該通過持續部署流水線的形式來進行自動化的驗證。確保任何的變更,如代碼變更,測試用例變更,環境配置變更都能得到快速的驗證,以及反饋 這些相關的“變更集”包括:基礎設施描述文件,源代碼,測試腳本,自動化測試用例,環境配置腳本,部署腳本,以及數據庫的創建,升級,以及回滾腳本等。 從上面的“變更集”也可以看出,持續交付是一個團隊所有人員和角色都應該參與的事情,并且每一個人都對軟件交付富有責任   原則四:提前并頻繁的做讓你感到痛苦的事情   “如果集成是讓你感到痛苦的,那么每一次代碼提交都應該進行集成,而且應該從項目一開始就開始這么做;如果發布軟件過程前測試是一件痛苦的事情,那么就應該從項目一開始就不斷的進行測試;如果軟件發布是一件痛苦的事情,那么每一次代碼提交在完成自動化驗收測試之后都應該進行發布,或者至少發布到類生產環境”   原則五:內建質量   在持續交付過程中持續交付流水線定義了一套標準的,可重復的軟件交付流程;同時借助大量的工具我們可以將這個流程中的機會所有事情都進行自動化。但是另外一個點就是軟件質量。 根據原則四,其實我們也可以推斷出如果對代碼進行測試是一件痛苦的事情,那么在編寫實現代碼之前我們就應該寫測試,TDD,ATDD,BDD等軟件研發實踐正是體現了這一基本原則。 內建質量是戴明提出的名言之一。越早的發現缺陷,修復它們的成本越低。 根據內建質量的原則我們可以知道在軟件交付過程中,測試并不是一個階段,所以并不應該在開發介紹之后才開始。同時測試也不應該主要是測試人員的職責,參與交付的所有人都應該對軟件的質量負責 其中測試四象限很好的闡述了為了確保軟件質量而應該做的各種類型的測試建模   原則六:“Done”意味著“已發布” 在持續交付過程中認為一個特性的交付在理想狀態下應該是已經發布到用戶手中,或者至少已經向用戶進行了演示。 相應的在敏捷開發中,我們每一個迭代結束后都應該想"用戶代表"進行演示,并且在“用戶代表”試用認為是完成了之后才意味則“Done” 其中“用戶代表”可以是正在的用戶,也可以是相關的業務人員   原則七:交付過程是每個成員的責任   在現實情況下,測試部門總是抱怨研發交付的軟件質量差,運維總是抱怨軟件不夠穩定,開發總是抱怨缺陷反饋周期太長,解決問題的成本過高。 而在持續交付當中我們知道,對于交付團隊而言最終目標是確保軟件能夠交付到用戶手中,并且產生相應的價值。 而通過持續部署流水線,我們將所有參與到軟件交付中的角色都聯合成了一個整體,并且各個部分之間是能夠快速的產生反饋,促成各個成員和角色之間的交流,并且快速的解決問題   原則八:持續改進   在任何一個充滿生機的組織當中持續改進是這個組織保持活力的基本要素之一。 參與軟件交付的成員需要定期對過去一段時間內的交付工作進行回顧,去發現在這個流程當中的做的好的方面,以及做的不好的方面,并且提出解決方案。     為了持續交付組織應該做好哪些準備?     交付團隊而非部門   根據康威定律“設計系統的組織,其產生的設計和架構等價于組織間的溝通結構” 由于存在部門墻的存在,導致開發,測試,運維之間的大量溝通成本,嚴重影響效率。甚至嚴重時部門和部門之間甚至會非常容易起沖突。 開發人員只管完成既定的功能缺乏系統整體性思考;測試人員根據需求文檔完成測試用例,但是卻不思考需求本身的合理性;運維人員則缺少對軟件架構本身的理解。各個部門看似各司其職進井有條,但是卻很難對軟件交付的效率和質量做出太多實質性的貢獻。正如開篇所述, 而通過“交付團隊”從項目一開始讓所有項目成員能夠參與到軟件的交付過程中,確保各個角色的人員能夠頻繁的進行交流,并且為了一致的目標而共同努力,這也是DevOps運動核心價值 而相同角色之間的溝通交流通過社團COP的形式來進行領域知識的交流和提升是一個不錯的方式     充分授權團隊   確保持續交付實踐的成功,賦能團隊,授權團隊也是整個組織應該思考的問題。在持續交付中我們知道一個團隊是一個應該是以做產品而非做項目為目標,需要充分授權團隊,使得團隊能夠完成從需求,開發,測試,上線的端到端過程。   當然在實際情況中,組織會有更多的因素需要考慮,比如最典型的場景比如由于落后的基礎設施管理方式導致運維團隊往往是被動的響應研發團隊的需求,并且存在大量手動的操作環節導致時間和資源的浪費     平臺化,服務化   公有云,私有云,容器云 通過組織級別引入虛擬化或者容器化技術以及相應的管理平臺如OpenStack,Rancher,Ks8等工具可以大大減少Ops團隊的運維團隊,在過去需要大量手工操作的過程都可以通過虛擬化平臺或者容器化平臺完成,研發團隊或者資源的周期從之前的幾天縮短到幾分鐘。 基礎設施自服務 同時對于Ops團隊則專注于提供底層的基礎設施資源,包括網絡,安全等相關管理。并將相關的資源以服務的形式暴露給團隊,各個產品團隊管理自己的基礎設施環境,維護持續部署流水線,以及軟件運行環境的變更 平臺化服務 同時對于企業和組織而言通過引入統一的平臺化服務,可以完成對所有產品團隊的統一管理,和監控。這些關鍵的平臺化服務可能包括:統一的日志管理平臺,持續交付平臺,以及監控和運營平臺等。 ...

    Read More

    Build MicroService With Spring Cloud And Rancher

    分享人:鄭云龍 時間:2016-7-20   睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。 ?   1, Aganda ? 今天給大家分享的內容是:《Build MicroService With Spring Cloud And Rancher》主要內容:我們將演示如何通過Spring Cloud和Rancher構建一個具有彈性的微服務應用。并且在這個過程中當中我們主要遇到的問題,以及最后如何解決。 對于一個最簡單的微服務應用而言,一個最基本的結構如上所示: 我們需要一個服務發現和注冊服務幫助我們管理和發現新的服務; 當我們從一個單體應用到幾個,幾十個微服務時,服務的配置也成了一個非常棘手的問題,統一的配置管理必不可少; 為了簡化我們的客戶端調用我們可能需要一個輕量級API Gateway來統一代理我們的所有請求,同時可以做統一的安全控制; 同時在微服務下我們應該遵循Build For Failure的原則,當服務發生失敗時我們能夠隔離這些失敗的服務,從而需要引入Circuit Breaker熔斷器; 除此之外,同一個服務可能有一個到多個實例,當我們訪問服務時,我們還需要一個負載均衡器,幫助我們合理的分發我們的API請求。   2, Build MicroService With Spring Cloud   而Spring Cloud項目正是幫助我們解決以上問題的利器,讓我們可以更加專注于我們服務本身業務邏輯的開發,而將服務治理所需的工作都統統交給框架來完成。 Eureka提供了統一的服務發現和注冊能力; Ribbon和Hystrix則在服務和服務之間引入了負載均衡以及熔斷的能力; Zuul則作為一個輕量級的路由和代碼服務讓我們可以快速建立一個API Gateway的能力。 3, Service Discovery With Spring Cloud Netflix: Eureka   以Eureka提供的服務注冊和發現能力為例,作為一個微服務實例,在啟動時我們將會主動向Eureka Server進行注冊。Eureka Server服務維護當前服務的實例列表以及狀態健康檢查。????????而作為服務的使用者,我們首先需要向eureka server請求當前的服務實例,之后再將請求發送給API的真正提供者。   4, Client Side...

    Read More