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

搭建輕量化運行環境 為原生雲端服務奠定基礎

微服務架構於容器環境 實踐持續整合與部署

洪羿漣
根據IDC預測,在新科技推動各行業轉型的浪潮下,微服務(Microservices)架構將成為台灣產業應用主流,驅動企業對容器(Container)技術與應用程式介面管理(APIM)等服務的需求。從國際大型雲端服務供應商陸續加入雲端原生運算基金會(CNCF),紛紛推出基於Docker與Kubernetes(以下簡稱K8s)建構容器環境的雲端服務,亦可窺見市場發展風向。
甲骨文大中華區台灣技術諮詢處技術總監余銘信指出,微服務架構主要來自雲端應用模式所推動,著眼點在於可提供較虛擬主機更加輕量化的服務。虛擬化技術在自建資料中心應用環境中較具優勢,可達到快速建置與部署,但是在雲端應用場景中,雖仍可借助虛擬化技術實作,整體運行效能卻可能因此受限。

過去IT應用環境相當仰賴虛擬化技術快速地供裝(Provisioning)新環境,當市場上開始出現Docker實作可達到更快的部署,用戶自然會逐漸向新技術靠攏。余銘信觀察, 2017年開始,本土大型客戶確實愈來愈關注應用程式微服務化的議題,但是更在意內部眾多核心系統,該如何遷移到新型態的環境。因此就現階段來看,微服務架構主要會被採用於新的開發專案,至於內部既有的核心系統則更傾向於維持穩定運行。

開源軟體將主導新世代IT架構

其實近年來國際間企業IT環境已普遍發展為雙速IT(Two-Speed IT)模式,若營運業務追求創新,勢必得快速地跟進瞬息萬變的市場需求,即相當適用雲端原生的建置模式;至於以穩定性為主要考量的應用,例如財務等後勤系統,則毋須採用最新的技術來實作,仍維持既有運行環境。

容器技術可說是當前雲端應用領域炙手可熱的議題,但余銘信認為,虛擬化技術從出現到廣泛被採用,至今大約十年,若斷言未來十年將改由Docker技術主導,卻也未必如此,畢竟IT領域不乏技術菁英,勢必會找到應用服務的缺點並且提出改善方法,屆時可能又成就另一番態勢。

「但是有個趨勢確實不可逆,那就是開放原始碼將主導IT底層技術的發展,較以往IT領域新技術大多由國際大廠所研發的模式完全不同。例如甲骨文、微軟、IBM等國際軟體大廠皆各自研發企業端所需的整套系統架構,如今也納入整合開放社群所推動的技術,我認為會是持續發展的方向。」余銘信說。

過去開源軟體之所以無法被廣泛採用,較大的障礙在於成熟度不足,版本更新速度又相當快,難以符合商業應用要求的穩定性。即便是現階段企業若採用純開放原始碼的應用系統,同樣會遭遇到諸如此類的問題,除非企業IT部門擁有龐大開發團隊,可自主研發與維運全新的系統架構。


▲甲骨文新發布的容器原生應用程式開發平台,包含Pipelines、Registry、Engine等組成元件,其中Engine即是基於Kubernetes所設計的持續部署管理。(資料來源:Oracle)


如今本土企業的態度之所以逐漸開放,通常是為了避免被單一廠商綁定,或者是試圖整合不同領域的技術,開創出新興商業模式。如此一來,企業內部技術人員就必須得投入研究,自行解決開放原始碼可能帶來的問題,以滿足業務方面需求。

甲骨文本身就是國際軟體大廠,內部自然擁有龐大開發團隊,持續發展雲端平台服務的創新應用,近年來也逐步擁抱開源,已先行評估各個社群發展的方案,選擇合適的元件,再加以整合相關技術的堆疊(Stack),並且在社群版本更新,或是市場驅動特定組成元件變更時,得以隨之調整演進。日前甲骨文新發布的容器原生應用程式開發平台(Oracle Container Native Application Development Platform),即是基於Docker與K8s技術所建構,以協助IT技術能量有限的企業,解決開源軟體的整合性問題。

容器原生雲服務實作持續整合與部署

在尚未宣布支援K8s專案之前,甲骨文本就已提供Developer Cloud服務,不論底層是否為容器環境,皆可採用來自GitHub所發布的開放原始碼,運用Maven執行建構,基於Developer Cloud的中央控管環境,讓開發人員實作持續整合、持續部署(CI/CD)。 余銘信進一步說明,Developer Cloud服務所提供的管理開發週期,可基於Docker環境開發,支援發布Java、Python、Node.js等開放原始碼所撰寫的App,並且在部署環境中亦提供應用程式容器管理,為甲骨文自主研發設計的技術,並非專為K8s所搭建。

隨著K8s在容器技術領域日漸盛行後,甲骨文也開始納入支援,也就是最新發布的容器原生應用程式開發平台,以K8s為基礎設計新的堆疊架構,提供端到端容器生命週期管理平台實作持續整合、持續部署。其中,K8s主要負責持續部署,至於持續整合則是由2017年收購取得的Wercker技術來提供。

「甲骨文容器原生應用程式開發平台包含容器Pipelines、Registry、Engine等組成元件。Pipelines是基於併購Wercker取得技術,提供持續整合機制;Registry用於存放與分享容器映像檔;Engine用於新增與管理K8s叢集,採用Terraform建構安裝工具,提供可確保安全性、效能、高可用性的容器部署模式。」余銘信說。

當持續整合完成後,必須先行註冊容器映像檔,最後再部署到具備容器Engine的執行環境。Engine的底層架構,為甲骨文設計虛擬雲端網路(VCN),會自動新增三個可用性網域(Availability Domain),對外提供服務的網域可建置負載平衡機制,以確保運作效能、高可用性、安全存取控管。

容器技術搭配K8s已是顯學,應用服務採用甲骨文設計的封裝技術執行後,除了可部署在甲骨文雲端平台,亦可支援符合符合此架構的AWS、Google Cloud Platform、Azure等第三方雲端平台。這也是K8s之所以受歡迎的原因之一,企業採用此技術可實現彈性搬遷,免於被單一雲端平台供應商綁定。

余銘信觀察現階段採用K8s實作的客戶,主要看重的是微服務架構,目的是為了把服務快速推向市場。甲骨文所發展的容器技術,可支援微服務與Serverless(無伺服器)架構運行,讓開發人員只要專注在程式碼功能的撰寫,完成後發布到GitHub,之後透過容器原生應用程開發平台提供的自動化建置、測試、推送、部署,實作持續整合、持續部署的流程。

「大型企業營運業務需求關注的焦點在於微服務架構,但是實作的方式並非僅有Docker,在成熟的WebLogic應用程式系統環境也可達到相同目的。」余銘信強調。微服務架構關鍵在於透過API串接,採用輕量化的RESTful來取代SOAP,但是API環境必須建立APIM框架,對於維運團隊而言,需要掌握的新技術相當多,若採用WebLogic實作,管理方式即可延用既有工具,降低日後維運的負擔。

這篇文章讓你覺得滿意不滿意
送出
相關文章
秒速容器服務 挺應用轉型
Hyper-V隔離容器 支援.NET程式獨立運行
拆解龐大核心系統 微服務仍保障既有投資
數位商業模式箭在弦上 關鍵應用系統轉型助攻
多雲複雜微服務 管理須自動化
留言
顯示暱稱:
留言內容:
送出