將此篇文章跟 Facebook 上的朋友分享將此篇文章跟 Plurk 上的朋友分享將此篇文章跟 Twitter 上的朋友分享列印轉寄
2018/12/4

容器環境推動DevOps團隊協作 助企業IT邁向多雲應用

拆解龐大核心系統 微服務仍保障既有投資

洪羿漣
近年來IT應用環境因應數位化時代掀起轉型聲浪,隨著容器(Container)、開放API、微服務等開放陣營發展的技術影響力日益強大,尤其是Google自2015年貢獻Kubernetes容器調度工具給雲端原生運算基金會之後,國際IT大廠IBM、VMware、Microsoft、Red Hat等,皆陸續整合納入自家平台,如IBM設計提供的ICP落地型解決方案,可建置容器即服務以承載微服務架構,其搭配的調度工具即是K8S。
近年來IT應用環境因應數位化時代掀起轉型聲浪,隨著容器(Container)、開放API、微服務(Microservices)等開放陣營發展的技術影響力日益強大,尤其是Google自2015年貢獻Kubernetes(K8S)容器調度工具給雲端原生運算基金會(CNCF)之後,國際IT大廠IBM、VMware、Microsoft、Red Hat等,皆陸續整合納入自家平台,如IBM設計提供的ICP(IBM Cloud Private)落地型解決方案,可建置容器即服務(CaaS)以承載微服務架構,其搭配的調度工具即是K8S。

IBM的公有雲服務針對IaaS提供的是SoftLayer,具備網路、儲存、運算以及Hypervisor;在PaaS平台方面是Bluemix,運行作業系統、中介軟體、Runtime環境;至於SaaS則是於IaaS與PaaS平台之上再增加資料、應用程式。從2018年起統稱為IBM Cloud。但是只靠公有雲無法完整滿足企業應用需求,畢竟過去投入大量資源建置的資料中心難以就此廢除,雲端服務未來亦可能須遷移回到地端,對此IBM即是提供ICP來協助建置CaaS,搭配基於K8S調度能力所設計的多雲管理(Multicloud Manager)操控平台,並設計以儀表板(Dashboard)方式呈現狀態分析資訊,輔助DevOps團隊協同工作。

運用多雲管理操控平台,負責維運CaaS入口網站的技術人員,便可依據工作流程配置優先執行順序與控管政策,IBM大中華區軟體研發中心應用及整合資深顧問陳怡良指出,甚至可針對不同時間點的雲端服務收費規則先行試算,例如開發單位申請容器環境的時間點,可能碰到自家平台資源吃緊,則必須轉向選用外部公有雲服務。

然而公有雲服務收費模式最小單位可為每小時,但在同樣時間點,選擇澳洲、東京、倫敦的資料中心,價格可能完全不同,企業自行搜尋網路標價進行估算往往不夠準確,因此主流的公有雲服務供應商皆有針對計價功能提供API,讓管理軟體呼叫擷取最新收費準則。企業只要事先跟IBM、AWS、Azure、Google等公有雲服務供應商簽訂協議,便可選擇以儲值方式,用多少扣多少,抑或是月結收費。只要簽訂協議後,供應商通常都願意提供定價模式資訊,或經由API擷取,如此一來,DevOps團隊即可藉此機制掌握開支。

容器技術的五大特性贏得企業青睞

就容器技術的特性來看,陳怡良說明,主要具備了Portable(可攜性)、Performance(效能性)、Visibility(可視性)、Immutable(不變性)、Composibility(組合性)等五大特性。Docker Engine實作Image程式為可攜性,呼叫原生平台的系統核心即可運行,較Hypervisor層建置Guest OS模式來得更輕量,效能自然更高,也因此可達到秒級的啟動速度。

「可視性方面是把以往系統安裝、操作程序、輸入的環境參數設定等工作流程,按照執行步驟撰寫為Dockerfile,只要檔案未經修改,皆可原封不動地重建程式運行環境。不可變性則指的是Image本身封裝的系統函式庫無法被修改,一旦Pull(下載)指令執行後,啟用的容器環境會回復到初始狀態,即使原本攻擊程式已成功滲透也因此失效。」陳怡良說。

組合性是透過Docker Compose技術,把多個Dockerfile組合繪製拓樸圖,例如依序指定配置為前端網頁、商業邏輯、資料庫運行環境,以建置完整的商業應用系統。當企業有多網站與資料庫應用需求,只要Pull所需的Image檔案,經由Docker Compose組合後即為可運行的應用系統。

當存取流量超過資源承載,可彈性執行橫向擴充(Scale-out)。以往實體伺服器的建置架構,面對資源吃緊必須進行垂直擴充(Scale-up),例如把記憶體提升到32G等級,伺服器勢必得先關機,也代表所有應用服務必須中斷;進展到Hypervisor環境時,便於橫向擴充的能力吸引企業青睞,問題是虛擬主機檔案從遷移到啟動上線運行,至少得花費五分鐘,且可能重新派發IP位址,網路控管政策亦須調整設定;如今到容器環境,不僅垂直擴充無須停機可立即生效,若需要橫向擴充,只要設定條件值,亦可自行延伸與縮回。

此外,容器環境並非採用IP位址溝通,而是透過Overlay架構,自成一套網路運行環境,藉由DNS服務解析,因此可掌握整個容器環境運行狀態,以便提供微服務使用。

應用系統先容器化再拆解轉成微服務

▲ IBM大中華區軟體研發中心應用及整合資深顧問陳怡良觀察,近十年來IT廠商獨家的技術陸續釋出到開放陣營,技術發展速度比自家研發更快,IT人員也開始參與學習到實用性高的技能,讓開放社群的力量日漸壯大。
K8S最小單位為Pod,可包含多個容器,較Docker以容器為單位不同。以技術來看,陳怡良說明,過去透過Docker Swarm來解決資源調度(Scheduler)與編排(Orchestration)的複雜度,可適用於大約100個容器數量的測試、研究等環境,問題是企業應用服務所須配置的容器,可能多達成千上萬,則必須採用Google釋出的K8S工具來實作控管。同類型的開源工具還有Apache Mesos,過去Hadoop分散式架構主要便是運用Mesos實作資源調度與編排工作,在容器技術興起後,Mesos也延伸提供支援,只是近年來採用者數量遞減,聲勢也較薄弱。

如今K8S雖已為主流,仍有小型的DevOps團隊偏好採用Docker Swarm,若不需要複雜的架構,安裝建置Docker Swarm只要五分鐘即可配置完成。相較於K8S,安裝可能需要超過一個小時,畢竟應用規模較大、複雜度較高,除了網路層配置,作業系統核心也須先行更新修補程式,再部署應用服務。所幸可自行撰寫安裝配置檔案,大約九成的設定操作可自動化執行,實際上需人力介入的時間大約只有一成。

就網路銀行應用服務來看,通常整合相當多的功能模組,在龐大的系統中提供個人銀行常用的餘額查詢、繳費、衍生性金融商品等服務項目。陳怡良指出,在微服務架構與容器環境導入之前,網路銀行主要是以單一應用系統來提供所有服務,並建置兩台大型伺服器以建立高可用性。

多數企業IT轉型的開始是先採以容器化方法,也就是直接把整個應用系統封裝在兩個容器環境中運行,藉由實機測試驗證技術後,才全面性地採用。「現階段我們已經開始基於方法論來協助拆解應用系統功能項目,依據功能項目轉化成微服務架構嵌入到容器環境,針對較多人使用的微服務,配置多個容器來支持運行。至於其他較少存取量的微服務,可能只須配置一個容器即可。」陳怡良說。

完成微服務的拆解之後並非就此結束,關鍵是得依據不同通道(Channel)盤點出共用模組,必須予以抽離統一集中存放。各行業核心的大型應用系統,或多或少有共用模組平台,經過拆解成微服務後,統一存放於特定區域,再開放給不同通道呼叫使用,讓開發人員只要維運共用模組程式即可支應各自獨立運行的微服務。

至於既有的EAI(企業應用整合)/ESB(企業服務匯流排),則是在共用模組後端,畢竟仍舊必須藉由EAI介接後端封閉的帳務主機系統,把資訊轉換成為開放格式,只不過以往是直接提供給各式存取管道,如今則是透過共用模組平台存放區來串接整體應用服務。

微服務本身特性是須透過API運行,API必須經過註冊後統一控管,主要是因為,共用模組平台運行環境可能由多個容器所組成,彼此間透過API溝通。問題是,該怎麼掌握企業內部所有的API服務?以前大多只透過Excel檔案記錄,相信現階段仍有企業沿用此方式,但是由於API數量過多,人工記錄效率低落且容易出錯,因此必須得透過API服務註冊中心,也就是企業所有微服務的API,必須上架到註冊中心。前端系統可先行查找所需的API服務,以便藉此拋送資料到後端處理回傳。「此機制就必須透過K8S才得以做到,解決資源與服務的控管、調度,所以當應用系統轉換到微服務後,多數會搭配K8S來執行控管。」

善用既有投資轉型到雲端原生應用

以往商業應用軟體少見納入整合開放社群的工具,但K8S卻是在短短兩年內,幾乎全數IT廠商皆發布整合運行的解決方案,即代表K8S確實可解決新興應用架構的問題。畢竟對於商業營運環境而言,穩定性可說是天條,僅仰賴Docker Swarm恐無法支應,K8S本身是由Google研發設計並且實際驗證過的工具,自然更具信心可大量採用於商業環境。

IBM ICP便是基於K8S發展補強功能性,使解決方案較完整並得以確保應用環境的穩定與安全。陳怡良舉例,ICP內建的Vulnerability Advisor(VA)功能是IBM所增添自家擅長的資安領域技術,以確保新興應用環境的安全性。IT人員可能自行封裝Image檔案啟用,也可選擇從外部GitHub等平台下載,但萬一埋有攻擊程式碼,未經過工具檢驗之前根本無從得知,恐將因此為企業帶來災害。藉由ICP VA則可掃描Image檔案與容器運行環境,補足原生K8S未具備的檢測能力。

「必須強調的是,IBM認為必須尊重或善用企業既有的投資,針對已經導入建置中介軟體的IT應用環境,設計提供Transformation Advisor工具,不論內部既有系統為IBM、Oracle、Red Hat等中介軟體皆可藉此工具進行轉換評估。若最終目標是轉型成雲端原生應用程式,亦可提出建議應該執行的工作項目。」陳怡良說。 畢竟企業IT即使組織DevOps團隊,恐怕也無力把既有應用系統的程式碼逐條予以容器化,並搬移到雲端原生環境。因此IBM設計Transformation Advisor工具,只要提供原始程式碼、原本運行的環境、移轉的目標,工具會自行評估計算出轉移所需的執行工作項目,甚至亦可藉由工具介面快速執行特定工作。

為了讓客戶善用既有投資,IBM提供移轉的路徑與工具讓企業得以參考,加快轉型到雲端原生應用環境的速度,另一方面,也設計提供IBM Microclimate開發環境,基於瀏覽器操作介面,即可運用支援微服務所須的IDE開發環境,廣泛地支援Java、Node.js等雲端原生應用程式碼,完成後亦可直接線上測試,無須額外準備測試環境立即可實作,之後Check-in到Git版本控管平台,經過持續整合(CI)之後,再把程式碼從Git平台Check-out,綁定在內含有應用伺服器版本的Image,之後執行持續測試,此時即是在容器環境中執行,確認問題都已排除後,最後予以整合發布到線上環境。

「這整條流水線(Pipeline),包含Check-in/Check-out、Build Image等工作流程,即可透過Microclimate來實作,讓開發與維運建立一致性工作程序。」陳怡良強調。

這篇文章讓你覺得滿意不滿意
送出
相關文章
秒速容器服務 挺應用轉型
Hyper-V隔離容器 支援.NET程式獨立運行
數位商業模式箭在弦上 關鍵應用系統轉型助攻
多雲複雜微服務 管理須自動化
潮流技術日新月異 資深講師解密駕馭要領
留言
顯示暱稱:
留言內容:
送出