本文做者:francisk84安全
百度雲原生應用解決方案亮相百度雲智峯會服務器
傳統企業近年來數字化轉型的趨勢相信各位讀者已經有了很是清晰感知。在這個過程,企業在數字化路徑選擇上的不一樣也會影響企業數字化轉型的最終成果與實施成本。根據市場調查和預測,企業近些年來愈來愈多的採用雲原生的手段來讓自身業務經過新一輪的數字化轉型實現快速發展。架構
在本次2019百度雲智峯會上,由百度效率雲聯合智能雲微服務推出了雲原生應用解決方案,並推出了基於百度效率雲和CNAP平臺的雲原生DevOps實戰workshop。運維
看到這裏,您可能會好奇,什麼是雲原生?百度設計的雲原生解決方案有什麼特點?Workshop上又實操了哪些實踐?下面我來爲讀者一一道來:函數
什麼是雲原生應用微服務
雲原生是一種方法,用於構建和運行充分利用雲計算模型優點的應用。雲計算再也不將重點放在資本投資和員工上來運行企業數據中心,而是提供無限制的按需計算能力和根據使用狀況付費的功能,從而從新定義了幾乎全部行業的競爭格局。IT 開銷減小意味着入行的壁壘更低,這一競爭優點使得各團隊能夠快速將新想法推向市場,這就是軟件正在佔據世界,而且初創公司正在使用雲原生方法來顛覆傳統行業的緣由。工具
---摘選自pivotal.io學習
雲原生應用平臺測試
企業爲了實現雲原生應用的開發,就離不開一個用於構建和運行雲原生應用和服務的平臺,來自動執行並集成 DevOps、持續交付、微服務和容器等概念:大數據
基於雲的雲原平生臺和自建平臺對比
根據CNCF(CLOUD NATIVE COMPUTING FOUNDATION)所提供的landscape,咱們看到雲原生已經發展爲一個領域細分明確,工具豐富的龐大生態:
對於想搭建一套雲原生應用開發平臺的企業來講,就面臨着幾種不一樣的方案,要麼採購現成的,基於成熟的雲的PAAS,SAAS方案;要麼本身在上述的開源產品中進行選型,自主搭建一套雲原生的開發,運維解決方案。咱們從如下幾個方面對兩種方案的成本結構進行了比較:
方案一 |
方案二 |
基於開源自建方案 |
採納成熟的雲上方案 |
技術選型成本 資源虛擬化改形成本 技術人員招聘成本 平臺運維成本 定製化改形成本 學習使用成本 |
採購成本 學習使用成本 |
固然,不少人會說,採納雲上方案,咱們在採購成本里就已經支付了技術選型,虛擬化等方面的成本;可是對企業來說,整個方案的搭建,還包括了團隊的組建,人員的招聘和維護。筆者和不少企業的IT部門溝經過,企業反饋的是: 咱們都知道有哪些開源的產品和方案,可是咱們沒有辦法長期維護一支熟悉相應技術的運維團隊。從而致使不少企業很難開始雲原生的嘗試。
而採納雲上方案,必定程度上將基礎設施的運維工做和方案的設計工做託管出去,企業能夠更加專一在自身業務。更不用說雲上多種有針對企業業務特點的PAAS服務,可以進一步的爲企業賦能。
百度內部研發和IT技術基礎架構的變遷
IT技術設施的變遷
百度內部也經歷了從12年機器管理和變動管理的初步自動化,逐漸發展到15年左右開始基於CI/CD的持續集成和PaaS平臺部署交付,再到如今公司內部大規模的容器化,實現存儲底層系統到大數據、AI與在離線業務場景全覆蓋。
在運維團隊的目標上也從提高迭代效率、服務穩定性以外,更加的關注資源利用率與成本管理。
內部軟件研發模式的變遷
百度內部的軟件研發模式也從傳統的瀑布式,逐漸發展到以迭代爲主的敏捷研發模式,最後發展到如今的全面擁抱基於最前言IT技術設施的DevOps模式。
百度內部對於軟件研發的關注點也在不斷擴展,在瀑布研發模式時代,咱們更加關注軟件研發的合規性;在敏捷開發時代,咱們提倡基於穩定的質量不斷縮短髮布週期;在現下,咱們對於軟件研發的關注點除了速度和質量以外,也一樣關心技術的複用,開源,以及每一個工程師自身能力的成長
百度雲原生應用解決方案介紹
百度的雲原生解決方案凝結了百度多年的開發,運維經驗,本次大會上發佈的全套解決方案以下:
架構特點
從架構上, 以 Kubernetes爲基石,咱們實現了微服務應用平臺、容器引擎的同構私有化交付,這也使得咱們的混合雲納管能力更加完備。同時在邊緣計算上,咱們也實現了函數引擎同構部署在CDN節點,使得在CDN節點運行雲端函數成爲可能;
與開源生態的結合
同時,秉承着開源開放的心態,總體解決方案支持多種開源技術棧:
徹底兼容開源 Kubernetes:
應用管理層面:
服務和容器監控:
日誌服務:
產品介紹
依託於百度雲穩定可靠的基礎服務,百度雲原生應用解決方案提供了從產品定義,協同開發,持續部署,到微服務治理,集羣管理,線上監控的完整DevOps生命週期服務,正好對應雲原生應用平臺中的四個方面,下面我就來爲你們介紹方案中的各個產品:
百度效率雲
百度效率雲(如下簡稱效率雲)是百度自主研發的一站式DevOps解決方案,凝聚了百度多年來在軟件工程領域的探索和實踐經驗。效率雲在百度內部服務10000+工程師的平常產品管理、開發、測試、發佈等研發工做,天天支持百度內部30000+次的雲端編譯、70000+次的構建、700+次的服務發佈(以下圖)
效率雲已經加入百度智能雲產品序列,於2019年5月正式對外提供服務。百度效率雲目前同時服務外部2000+企業及我的客戶的項目管理,研發,測試等研發工做。
效率雲的核心理念是: 用先進的軟件工程技術使複雜的開發工做更簡單!
百度效率雲的產品架構
整個效率雲包括三大平臺類工具和四大主要功能模塊,分別是產品和項目管理工具iCafe、代碼託管和協同開發平臺iCode、持續交付平臺iPipe;
依託於三個基礎工具平臺,五大主要功能模塊包括靜態代碼掃描工具iScan、容器化構建工具iBuild、構建產物管理工具iRepo,iPipe插件市場(私有化版本)和工程能力地圖(私有化版本)
百度效率雲的特點功能
和其餘同類DevOps解決方案對比,百度效率雲有以下產品特點:
與大多數基於pull request的流水線不一樣,效率雲提倡進一步將質量保證手段前置。工程師在提交代碼後、代碼入庫以前即通過一系列的自動化代碼檢查和Code Review環節;只有經過全部的質量保證手段,代碼方可合入到當前代碼庫中。
得益於百度內部多年對代碼分析技術的研究,效率iScan插件中植入的BCA系列掃描規則將漏洞的誤報率下降至5%,高於業界的10%。經過特徵識別等手段,iScan還能夠支持增量代碼的掃描,大大提高掃描速度
這是本次介紹的重點功能,百度效率雲在Maven和Gradle構建插件中增長了鏡像打包功能,研發人員能夠在完成構建的同時製做Docker鏡像,並存儲至本身項目專屬的鏡像倉庫:
完成構建後,研發團隊能夠在iRepo的鏡像倉庫中找到構建結果。
鏡像的發佈由iPipe上的另一個重要插件--CNAP插件來完成:
在使用CNAP插件以前,研發團隊須要在CNAP中配置相應的工做空間,應用和部署組。也就是說,實際對資源和部署的管理是在微服務應用平臺CNAP中完成的;效率雲中的CNAP插件調用了用戶已經配置好的資源。這樣,經過自動化的流水線,研發團隊就能夠徹底自動化的將服務的變動快速推上線;研發人員能夠在2-3分鐘內完成線上環境配置,資源配置到服務變動的全過程。並且整個過程不須要寫額外代碼,學習門檻極低
雲原生微服務應用平臺CNAP
雲原生微服務應用平臺(Cloud-Native Application Platform,簡稱CNAP)是一個爲企業提供應用託管和微服務管理能力的PaaS平臺,能夠幫助企業簡化部署、監控、運維等應用生命週期管理工做,同時提供服務註冊、服務治理、服務監控和調用鏈等微服務管理和運維能力。
CNAP的主要場景
CNAP平臺的主要場景之一: 基於容器的應用託管
CNAP爲企業的開發運維人員提供了穩定的應用部署環境,監控方式和靈活的彈性伸縮機制,方便企業高效的實施運維工做
CNAP平臺的主要場景之二: 微服務治理
容器引擎CCE
百度容器雲引擎(簡稱CCE)提供Docker容器的生命週期管理,大規模容器集羣的運維管理、業務應用的一鍵式發佈運行等功能,無縫連接百度智能雲其餘產品,提供彈性、高可用、高效便捷的平臺服務,助力系統架構微服務化、DevOps高效運維、AI應用深度學習容器化等業務場景。
容器雲的主要特點
本次大會的workshop
本次雲智峯會上的雲原生DevOps workshop,就是圍繞上述三個核心產品,讓參與的學員體會將一個基礎服務經過效率雲的自動化流水線,發佈到本身配置好的容器環境中,並在CNAP平臺中配置外部訪問接口,最終在線上觀察系統的變動。
整個workshop的操做,對於有必定研發及運維經驗的人員來講,能夠在30-40分鐘內完成所有的配置和操做。相比基於傳統IDC實體服務器的配置和操做過程,能夠說是數量級上的效率提高。
對於Workshop感興趣的朋友,能夠關注」百度效率雲官方公衆號」,後續咱們會在公衆號上放出整個workshop的視頻版。