多雲環境實作容器效益最大化

與虛拟機相比，容器技術具有大量的優勢。我們不僅要了解容器是如何實作多雲應用程式可移植性的承諾，而且也要知道其不足之處。

對于那些希望跨雲平台實作應用程式可移植性的企業來說，容器技術可以是一個可行的選項。通過精心規劃和使用合适的工具，IT團隊是可以直面挑戰并在多雲環境中實作容器技術優勢的。

為了了解在多雲環境下實作應用程式可移植性的潛在好處和風險，我們可将它與它的替代解決方案虛拟機進行比較。容器與虛拟機的不同之處在于：應用程式鏡像與這些鏡像中所包含的内容，以及生命周期管理等方面。

虛拟機部署要求應用程式鏡像具有作業系統、中間件和應用軟體的完整軟體包。是以，這些鏡像可以在符合應用程需求的硬體功能和資源容量(例如CPU和記憶體)的任何虛拟機上正常運作。隻要主機伺服器的虛拟機管理程式與虛拟機相容，并且應用鏡像所使用的任何都可以在雲平台上使用，那麼使用者也就沒有什麼重大的執行方面問題。

另一方面，容器應用鏡像并不包含作業系統或所有的中間件元件。是以，它們的正常運作主要依賴于容器主機和容器軟體本身。這意味着，如果容器需要跨雲供應商的不同應用程式鏡像，那麼它們可能會在多雲環境中造成挑戰。

但是，大多數容器軟體都将應用打包在一個标準容器中間件集合中，然後那個容器就可以跨容器軟體将要運作的任意主機上實作可移植性。隻要使用者能夠確定每一台基礎設施即服務(IaaS)主機上都部署了相同可用的作業系統和容器軟體，那麼這種可移植性一般來說就會正常發揮作用。但如果使用者無法確定上述要求，那麼容器就根本無法保持可移植性。

對于涉及容器技術的多雲規劃來說，可選擇都基于相同容器主機作業系統和架構的公共雲資源和私有雲資源。如果使用者所使用的作業系統或中間件功能并未在所有的作業系統釋出版本中得到支援，那麼就必須特别謹慎了。通過使用标準基，使用者可能可以對其容器化的應用實作跨雲平台的遷移而不會出現執行問題。否則，使用者則需要避免多雲環境部署或需要遷移至虛拟機。

多雲環境容器的運作效益

盡管存在着一些規劃方面的挑戰，使用者還是能夠在多雲部署中實作容器的一些優勢。

例如在運作方面，Docker和其他容器系統會包括一個配置和參數架構，這個架構會将所有工作負載運作所需的元件都打包在一個單一的軟體包中，進而更便于針對特定環境調試容器鏡像。在虛拟機系統中，配置和參數都是根本不在管理範圍内的——虛拟機的作業系統、驅動程式和應用程式都是完全與管理和底層主機隔離的。

是以，運作人員必須為每一家雲供應商準備一個不同的鏡像，進而帶來了更多的工作量和導緻錯誤的機會。這一點不同可以實作不同雲供應商之間的容器可移植性。但是，使用者将需要確定所有特定供應商元件與應用程式配置之間的無關性，以便最大限度利用這個功能。換而言之，容器對特定供應商API或其他功能的依賴程度越高，遷移的難度也越大。

網絡與多元件應用

網絡是容器技術發揮其優越性的另一個領域。多元件應用(例如那些基于微伺服器的應用)都是多雲計算環境中常見的應用，而那些應用元件都必須處于聯通狀态。虛拟機沒有特定的網絡模式;應用在作業系統和中間件的支援下能夠完成相當多的工作 。這就要求運作人員為應用元件建立一個網絡以便能夠在多雲環境中實作應用程式元件在每一個IaaS平台上的可用性。不同的是，容器設定了一個通用的子網模型來實作連接配接，這種做法更易于管理。

管理人員可以更容易地擴充容器系統并通過容器叢集提高其彈性。一個叢集為應用元件定義了一系列的托管點，并且它們都是便攜的。但是，在多雲環境中還是需要花一點功夫提高容器元件的可擴充性和和彈性，因為一般情況下叢集會共享一個子網。當他們需要跨越雲平台邊界時，這就可能會帶來挑戰，因為不同的供應商會使用不同的子網劃分規則或限制(例如不同節點之間的負載平衡)，而這些規則或限制會影響叢集的功能。

對于擴充規模和提高跨多雲部署中多元件彈性來說，虛拟機通常是更好的選擇。這是因為虛拟機需要更精細的網絡詳細資訊，進而降低遷移至另一家供應商時出現錯誤的風險。

諸如Docker之類的單個容器平台并不适用于多雲環境中的可移植性，至少不适用于實際的IT營運環境。但是，諸如Kubernetes之類的開發營運工具可以解決這一問題，而且這些工具有可能會發展成為支援虛拟雲的概念，或者是可以跨越私有雲和多雲的一個單一模式。 

原文釋出時間為：2017-10-18

本文作者：滕曉龍編譯

本文來自雲栖社群合作夥伴“51CTO”，了解相關資訊可以關注。