熟悉云計算和虛擬化的同學應該知道，容器的歷史由來已久。從90年代的Java和J2EE開始，這種通過底層平臺為應用程序創建單獨使用環境實例的方式就為人所知。隨著企業上云成為趨勢，如何在本地數據中心與公有云之間為應用遷移構建橋梁，讓大家再次想到了容器。事實上，容器引擎在混合云編排中的貢獻著實不小。
跨云離不開容器（圖片來自Yahoo）
容器為應用創建了隔離邊界，使得多個程序在單一操作平臺上可以獨立運行。對于使用者來說，不需要為每個應用都創建虛擬化，相應的也可以有效利用硬件資源，這種針對容器執行和規模的管理在容器編排引擎上同樣適用。常見的編排工具包括Kubernetes（谷歌開源工具）、Docker Swarm、Apache Mesos、Rancher等，它們能夠處理復雜任務，例如查找最優運行位置、處理失敗任務、分享儲存卷或創建負載均衡與容器間通訊的覆蓋網絡。
通常，企業內部對數據在本地和云端之間的遷移要求是無縫即時的，而容器要做的就是基于底層提供一個抽象層讓應用“隨意交互”。Kubernetes使用了計算集群部署并管理容器，通過均衡工作負載來維護性能。在集群中運行時，Kubernetes的自復制性可以從橫向或縱向擴展容器數量，以滿足多應用遷移的需求。
再舉個例子，微博的架構在三年前容器化，之后打通私有云和公有云部署了初始化環境（包括Docker、Swarm），在編排向調度層下發任務時會根據資源進行分配。也就是說，有資源的調度，沒資源的時候向主機層申請。成功申請后，會自行創建機器環境，而初始化起到的作用就是帶來了可運行的Docker編排環境。有了容器編排引擎，開發人員可以自行創建本地數據中心與公有云之間的應用移植架構。
拿紅帽來說，Red Hat OpenShift提供了高度模塊化特性，用戶可以有多種選項進行定制，而且不會丟失任何功能。當然，企業也不用在Docker或Kubernetes之間做二選一，Red Hat OpenShift ContainerPlatform 3.4允許使用者跨云分配上述兩個編排工具的資源，組件集成、上線測試等流程均交給服務商，讓用戶實現了自動化。另一個開源編排系統Cloudify，甚至能夠讓應用自動化在不同云平臺上部署，支持容器應用在非容器化環境同時運行，只需通過一個控制器。
對于任何一家企業而言，打包交付的方式都是首選，但遺憾的是現有工具無法在用戶使用容器時提供完全自動化的方案。也就是說，工作負責耦合分離等問題的存在，讓開發者即使用了容器引擎或管理平臺，依然難以避免花費大量時間在傳統的業務流程。但不管怎樣，專注于核心業務，善用容器編排引擎仍是跨云遷移的好辦法。
京公網安備 11010502049343號