圖片來源: 

Mesosphere

掀起容器技術風潮的Docker問世不過才3年,不只掀起了Container應用風潮,帶動了微服務新興IT架構崛起,更讓開發維運一體化的DevOps模式更容易實現。

Docker執行長Ben Golub今年6月在DockerCon年度大會上揭露了最新的Docker使用者調查,有6成Docker使用者,開始在正式環境中使用Container,而不像過去大多用於測試、開發階段。大型企業擁抱Container的腳步也開始改變,他更引用另一個2016年中調查,在超過500人規模的大型企業中,更有73%的企業在正式環境中採用。

而且不只有新創或大型網路公司擁抱Container,電商(如ebay、樂天),媒體(如Netflix、紐約時報、BBC),醫療(如Merck、Abbott)、金融服務(如VISA、ADP、PayPal)、製造業(奇異、空中巴士等),科技公司(如Amadeus、IBM、思科)、電信(例如瑞士電信)等,越來越多的產業都開始導入。

應用情境也不再以開發、測試、DevOps、CI/CD為主,Ben Golub透露,儘管DevOps驅動的CD需求仍是大宗,超過5成應用案例都屬這類,但也有43%的Docker案例用來將老舊系統微服務化進而搬上雲端,另外也有37%的Docker使用案例是將老舊應用容器化。目前Docker容器運用上有43%的容器是用來執行傳統的資料庫系統。

Container成為企業雙頭IT的另一列火車頭

Container不只是科技新創或網路公司愛用的技術,開始成為企業雙頭IT的另一列火車頭,專攻雲端原生應用和App。企業面臨的新架構不只是混合雲的架構,還是雲端原生應用的微服務架構,要和傳統應用程式架構的整合。

舉例來說,IT團隊多達1,300人規模的Airbus,不只希望能在企業內部實現快速開發和部署應用程式,還想要進一步將這個速度力延伸到雲端,並且希望擴充應用程式規模時,可以兼顧資源利用率優化來控管成本,更關鍵是,還要簡化舊有非雲端應用系統的汰換過程。「擁抱DevOps和Container的PaaS平臺,是唯一的選擇。」Airbus公司IT工具服務新創部門首席Nicolas Fanjeau在紅帽大會上透露。

也因此,Airbus採用Docker Container技術,並使用Kubernetes來作為Container叢集的管理平臺。不只在新專案上用Container,「內部採用PHP開發的150套應用系統,超過40套已經準備好要改部署到Container上。」他說。

奇異家電靠800容器執行350個App

美國奇異集團旗下的奇異家電,則是靠800個容器撐起了350個App的後端架構,甚至還能將61年老系統所用的後端資料庫Docker化後,方便搬進私有雲中調度管理。

營收超過50億美元的奇異家電,早在2012年中時開始導入私有雲和敏捷流程,花了一年時間打造了一套自助式IaaS平臺。但是奇異家電後來發現,負責維運IaaS平臺的團隊,成了最大的瓶頸。因為不同應用程式所需的執行環境配置差異太大,而且非常複雜,即使已提供了通用配置的IaaS平臺,連資料庫都建立了DBaaS服務,但奇異家電的IT團隊,仍舊得花很多時間來進行手動微調,才足以滿足業務部門需要的應用環境特殊需求。

直到2014年8月,奇異家電在當年Dockercon上看到了Docker和Mesosphere後決定導入,一方面用Docker建立高彈性的AP可移植性,降低部署到多種環境時的配置門檻,另一方面則利用Mesosphere來管理容器、建立自動化排程、擴充等需求,來簡化資料中心維運和管理。

奇異家電還自己打造了一個自助式Web版管理平臺,稱為Voyager,作為應用系統管理者的管理之用,避免直接連線到容器內應用提高安全性和政策控管。經過一年,奇異家電至少已將350個內部應用App轉移到Docker環境上正式提供服務,使用了超過800個容器。可以說奇異家電大多數的關鍵應用系統都已經Docker化了,甚至連用了61年老系統後端搭配的資料庫也容器化放到IaaS上管理。原本奇異家電評估,得花上好幾年才能轉移老舊系統到雲端環境,但後來只用了4個月,就將45%的應用系統轉移到新架構上。

下一步,奇異家電給自己設定的新挑戰是,要盡可能提高容器執行密度,希望能做到在單一刀鋒伺服器上能跑1,000個容器,也希望能將核心的Oracle ERP搬上Docker環境。但這些挑戰都不只是Docker技術本身的考驗,更是大規模容器叢集的維運難題。

容器正式應用越多,Orchestration機制越顯得重要

越來越多企業擁抱容器技術後,新挑戰也接踵而來,不只是數個或數十個容器,企業要面對的是成千上百個容器的維運,如何管理超大規模容器叢集,正是Container平臺的下一個新挑戰。Docker叢集專案Swarmkit負責人陳東洛表示,越來越多人想在生產環境上使用Container,Orchestration(調度)機制更顯得重要。

Docker叢集專案Swarmkit負責人陳東洛表示:「企業要回到調度需求本身來看,而不只是看應用規模就決定導入Orchestration工具,要找出調度需求的痛點,而不是容器需求的痛點。」

過去企業建置大規模叢集時,最常用來管理叢集內伺服器調度的做法,前Mesosphere分散式系統首席工程師Timothy Chen打趣的說,其實是靠Excel。在Excel表單上列出每一臺伺服器的IP和用途,每有異動就更新這張Excel表單,來建立一份叢集節點調度清單,但隨著微服務(Microservices)架構開始盛行、容器技術走向正式環境,單靠Excel已經很難管理複雜的大規模容器調度問題。

容器叢集的考驗是得管理上千個生命周期

CoreOS分布式項目主管李響更直指,容器叢集的挑戰是,企業不僅要管理一個應用程式的生命周期,而是要管理成百上千個容器的生命周期。

尤其在大規模容器叢集的管理上,有三大問題,李響解釋,第一是如何部署容器叢集、其次是如何從中找到特定一個容器,以及如何連結或存取到這個特定的容器。

管理容器叢集常見工具之一就是排程工具(Scheduler),作用就像是過去管理叢集常用的Excel檔,但更自動化也能更聰明。李響表示,Scheduler的作用時將實體資源都抽象成一個資源池,讓開發者只需要向Scheduler提出應用程式需要的資源,再由Scheduler來安排如何提供。換句話說,「對應用程式開發者而言,細節都被Scheduler 抽象化了。」其他可用來管理大規模容器叢集的關鍵的是,李響表示,最新作法是開始採用「服務」(Service)的概念來管理容器叢集,透過「服務」概念來抽象化,多個容器之間的溝通。例如透過服務概念來部署應用程式,做到如滾動升級、自動擴充、副本控制的效果,也比直接調度容器更簡單。

李響提到的Scheduler,只是調度層工具的其中一環,Timothy Chen補充,虛擬化時代,是在一個基礎架構上,管理多個VM內的單一應用,但是使用容器和微服務架構之後,往往得在基礎架構上,提供多個VM,執行多個Container,來提供不同的微服務,組合成各式各樣的應用系統。

因為每一個微服務都得像過去一個應用程式那樣來管理生命周期,「導致開發者在正式環境中運作應用程式所花的時間,比思考程式業務邏輯的時間還要多得多。」Timothy Chen說。

也因此,許多大型網路公司都各使用了不同的Orchestration工具來管理大規模的叢集,如Facebook的Tupperware、Google則有Borg和Omega、Yahoo則利用了Hadoop專案中的YARN,Twitter則是使用了Mesos和Aurora。

CoreOS分布式項目主管李響直言:「容器叢集的挑戰是,企業不僅要管理一個應用程式的生命周期,而是要管理成百上千個(容器)的生命周期。」

Orchestration工具三大功能

Timothy Chen歸納Orchestration工具一般涵蓋了三大類功能,包括了服務管理機制、排程機制和資源管理機制,Orchestration工具可以將Web應用和各類服務和Container Runtime層隔離,來簡化複雜的容器叢集管理難題。

更進一步的功能細節,排程工具要做到置換、擴充/複製、重新排程、升級、降級、資源蒐集等。而資源管理機制則要能管CPU、記憶體、GPU、儲存(Volumes)、網路埠、IP位址等資源,而服務管理機制則要做到如標記(Labels)、命名空間或群組(Groups/Namespaces)、相依性(Dependencies)、負載平衡(Load Balancing)、可讀性檢查(Readiness Checking)等。另外,Orchestration工具最好還要能實作出非功能性的能力,例如擴充性、可用性、彈性、使用友善、移植性、安全性等。「最終就是要用Orchestration工具來建立一個高度可程式化的基礎架構(Programmable Infrastructure)。」Timothy Chen說。

像CoreOS想要實現的目標也類似,李響表示,CoreOS的目標是,開發者只需使用一套叢集管理平臺,就能執行任何自己的分散式應用,甚至可以具備有Google級架構的基礎架構資源池,也就是擁有了GIFEE架構(Google's Infrastructure for Everyone Else,任何人都可用的Google架構)可以使用。

不讓各家Orchestration平臺專美於前,Docker也在今年6月的DockerCon大會上宣布進軍Orchestration平臺的競爭,從Docker 1.12新版開始內建Swarm叢集管理工具,將Orchestration變成Docker引擎的核心機制之一。

陳東洛是Swarm叢集專案開發的負責人,他解釋,其實Docker一直在研究容器調度工具,在1.12版之前,Docker透過Swarm、Compose、Machine等部署工具來實現容器調度,Swarm功能內建後,Docker新的叢集與調度工具是Swarmkit。

前Mesosphere分散式系統首席工程師Timothy Chen認為:「不同企業需要的網路、儲存、資安的差異很大,Orchestration平臺想要設計一套符合所有需求的通用架構,目前還是一大挑戰。」

Docker內建叢集管理新架構

新版Docker 1.12將調度功能內建,提供了新的叢集與調度工具Swarmkit,使用了Docker的Service API來管理服務,要做到服務包含任務,而任務由容器來實現,並內建服務生命周期管理,還要將系統狀態保存在內建的raft store上,所有服務的負載平衡機制也內建,不需像過去得由外部工具提供。所有容器間的通訊皆預設加密。

Docker為何要內建叢集調度

陳東洛想要透過Swarmkit解決的容器Orchestration需求,包括了如何將任務分配到對應的運算、網路和儲存資源上來執行、如何管理系統資源和系統變化(如新增節點或離線)、如何調度任務島的節點、管理任務的生命周期、協助使用者使用調度工具、實現端到端到安全性確保、另外還要滿足公有雲、私有雲和混合雲部署的需求。

因此,新版Docker 1.12所新增Swarmkit,使用了Docker的Service API來管理服務,要做到服務包含任務,而任務由容器來實現,並將服務生命周期管理內建,另外還要能將系統狀態保存在內建的raft store上,所有服務的負載平衡機制也內建,不需像過去得由外部工具提供。整個容器叢集內建CA,所有容器間的通訊皆預設加密。

Orchestration才剛起步,導入得先評估需求

儘管用Orchestration來管理大規模容器叢集已經成了Container圈的熱門話題,但是,目前這類工具還處於發展初期。上海道客網路科技技術合夥人孫宏亮就坦言,儘管Orchestration確定是主流趨勢,但目前才剛在起步階段,企業類型差異很大,若沒有大型企業的人力資源,中小企業導入調度工具前,反而應先將基礎做的更踏實,例如改變資源管理方式、強化容器安全管理等。

上海道客網路科技技術合夥人孫宏亮坦言:「儘管Orchestration確定是主流趨勢,但目前才剛在起步階段,若沒有足夠人力,中小企業導入調度工具前,反而應先將容器管理做得更踏實。」

李響也認為,Orchestration是一個新的領域,目前還缺乏一個共同的抽象層,可供不同的Orchestration平臺來遵循。甚至,Timothy Chen認為,目前Orchestration平臺大多來自大型網路業者的經驗所發展出來的架構,Google的Kubernetes就是最典型的例子,但是每一家企業需要的網路架構、儲存需求、資安需求的差異很大,Orchestration平臺想要設計一套符合所有需求的通用架構,目前還是一大挑戰。

陳東洛表示,在不同應用框架中,各家調度工具的設計有其各自的目標情境,例如網路模式、儲存模式、鎖定機制上的作法仍有不同,儘管大家都希望能適用更多業務情境,但可能還要1-2年後,出現更常見的使用者模式後,才會出現主流的Orchestration設計模式。

這正意味著,如何選對合乎需求的調度平臺,以及上手這些調度工具的門檻成了企業得付出的代價。在Orchestration工具發展初期,企業到底應該等待技術更成熟再採用,還是現在就要一步到位擁抱Orchestration,這成了企業擁抱Container之後的新難題。

陳東洛則建議,企業要回到「調度」需求本身來看,而不只是看規模或數量來決定是否導入Orchestration,他就曾遇過Docker建置規模很大的企業,卻不需要使用調度工具,因為他們可能只在一臺VM上跑一個容器。調度可解決的需求例如複雜問題,有各種依賴關係,資源大小需求不統一,資源相互競爭時需要保障特定情境的使用等。「這些都是業務面的痛點,找出調度需求的痛點,而不是容器需求的痛點,」他建議,首先該做的是提高對自身業務的了解,妥善監測自家業務的使用情況,再從數據來決定,是不是真有調度需求。

李響則建議可以從Dev和Ops的角度來評估,對開發者而言,產品發布流程卡在維運因素,導致長達2、3個月才能發布一次改版,就可以導入調度,「因為調度工具可以將維運流程自動化,將維運時間縮短到2,3天,不只是讓開發者高興,更可以提高收益。」而對維運團隊而言,每次新服務上線後,監控新服務的資源利用率是不是一大難題,若這也是企業維運的痛點,也可以成為一股導入調度工具的動力。若開發或維運都沒有遇到這類困難,「第一步是先容器化,而不要一次就導入調度工具。」

打造過維運10萬容器PaaS平臺的百度資深工程師段兵建議,企業得評估容器化的目的,不一定所有應用都需要容器化,以無狀態服務或Web類應用比較適合。百度先從PHP應用開始,結合有迭代改版需求的大型服務,如百度貼吧來降低難度,直到最近才開始將複雜應用遷移到容器環境中,儘管遷移過程問題不少,但對比於未來幾年可預期的研發效率提升,還是值得投入。尤其需要深思的是,段兵認為:「擁抱容器和調度平臺,不只是技術問題,更是架構變革,連帶也會引起組織變革,這是一條長路,得從技術和管理雙管齊下。」

百度資深工程師段兵表示:「擁抱容器和調度平臺,不只是技術問題,更是架構變革,連帶也會引起組織變革,這是一條長路,得從技術和管理雙管齊下。」

 相關報導  Container平臺新挑戰:超大規模容器叢集怎麼管?


Advertisement

更多 iThome相關內容