為何Orchestration是企業擁抱容器的關鍵？

掀起容器技術風潮的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平臺新挑戰：超大規模容器叢集怎麼管？