CxO 們的容器實踐指南

與互聯網領域的領導們關於"容器"的討論通常被總結如下：

作為一名 CxO，我面臨槓桿時間術的持續的壓力。IT 預算不斷減少，我只有有限的資源。然而，交付的工作量卻比以往更多。我花費太多的時間致力於解決預算的約束。另外，互聯網的格局正在經歷一個快速的改變，而且新的技術一直在被引進。我從我最信任的顧問那聽來的最新的話題是一個「容器策略」的實現。我想理解：

1. 什麼是容器？
2. 過渡到容器的企業價值是什麼？
3. 為什麼我現在應該轉移到容器？如果我不採納會有一些壞處嗎？
4. 容器是否已經足夠成熟用於企業消費？
5. 我如何讓我的企業因使用容器而快速地發展？

讓我們從最開頭開始。

容器

在過去的 10 年左右，企業已經從物理基礎設施轉向了虛擬機（VM）。轉向 VM 的關鍵優勢是可以減少數據中心的用量。通過在同一個物理機器上運行多個虛擬機，你可以在更少數量的物理機器上安裝更多的應用程序。使用容器是另一種更輕量地打包應用程序的方式，而且其交付模式更快。它們是一種在單一的機器里運行多個應用程序進程的奇特方式，無論那個機器是一個虛擬機還是一個物理機。另外，容器在 DevOps 、微服務和雲戰略場景方面也扮演了重要角色。

容器 vs 虛擬機

容器和虛擬機在一些方面並不相同。一台虛擬機儘管不是物理機，但是它表現地就像是一台物理機。虛擬機是一個包含所有東西的獨立的環境，是一個完整的（來賓）操作系統。在另一方面，容器是一個共享同一個物理機或虛擬機上資源的進程。容器顯然更加有趣，因為：

• 相比較而言，虛擬機要重一些，而容器更輕。因為容器只包括了它們所運行的程序所需要的庫。
• 虛擬機需要花費幾分鐘來啟動，而容器在幾秒鐘內就可以啟動。
• 通常，相比虛擬機，你的基礎設施中可以容納更多的容器。


技術已經發展到足以保持這些容器安全、彼此獨立，而且正確的設計選擇可以保證那些壞掉的容器不會影響運行在同一個機器里的其他容器的性能。實際上，操作系統天生就是被用來構建成優化和運行容器的。

然而，當你轉向容器時，你需要做出正確的選擇。你需要做足夠的盡職調查，以便你選擇合適的技術合作夥伴和能夠製作容器的製造商。開源技術起著很關鍵的作用。開源的 Docker 項目使得分層格式的容器很容易構建和使用。開放容器計劃（OCI）已經成為被所有主要技術供應商所支持的開源容器標準。如 Red Hat 這樣的開源技術提供商提供了為容器而準備的安全的操作系統。例如， Red Hat Enterprise Linux 7.x （包括 Red Hat Enterprise Linux 原子主機）進行了優化以原生地運行容器，同時也提供監控和管理容器的工具。其他的開源項目如來自 Tectonic 的 CoreOS 也正在進入市場。的確，容器正等著被企業所採用。

容器平台

容器平台讓容器成為企業消耗品。在過去這些年中，你可能在你的企業里處理過虛擬機散亂的問題，容器散亂比那要糟糕好幾倍。在你的數據中心橫跨不同主機運行不同規模的容器，儘管容器故障仍然保證你的應用程序的高可用性，自動化健康檢查和基於流入的工作載荷的自動化容器縮放等等，這些是你能期待容器平台應該有的一些關鍵特性。

當在一個被定位為容器即服務模型（CaaS）的平台上運行容器時，這些平台的一些其它特性如自動化生成和部署使這個平台成為平台即服務模型（PaaS）。雖然 CaaS 能讓你規模化運行容器，但是，PaaS 可以讓你利用你的源代碼編譯、創建容器，為你運行那些容器。另外，這些平台提供了完整操作管理特性，例如，集群的管理和監控、容器的安全缺陷檢測，以及安全地運行容器、跟蹤日誌和度量等等。

儘管一些技術供應商正在使用他們的專有技術來構建容器平台，但總的來說，企業們正在圍繞建立在 Kubernetes（K8S）的基礎上的開源技術而進行標準化。K8S 是一項由 Google 發起的開源項目，現在很多大平台的供應商也支持它。K8S 也是雲端原生計算基金會（CNCF）的一部分，CNCF 正在發展成以云為中心技術的標準體。當你在容器平台上做出選擇時，圍繞開源流程編排技術的標準化是非常重要的。它基本上允許你移植到不同的容器平台，如果你不喜歡你第一次做的選擇的話。K8S 還允許你的容器工作載荷可跨越不同的公有雲進行遷移。這些就是為什麼我們會看到越來越多的技術公司正在使用 Kubernetes 的原因。

一些企業正在試圖通過拼接幾個包括 K8S 在內開源項目來打造他們自己 DIY 的容器平台。這確實是比繼續跟隨專有技術要更好的一種解決方案，但是要完成這項工作也仍然包含很多需要探討的地方。然而，一個企業的維護和保持這樣的 DIY 平台的能力應該被認真評估。許多企業並不是想做創建 IT 平台的工作，而是他們希望運行自己的主流業務。有很多可行的基於 K8S 的解決方案，比如紅帽 OpenShift 平台容器、Apprenda、Deis 和 Rancher，它們提供一個企業級平台，這些解決方案中的每種都有不同完整程度的功能。

這些解決方案是由供應商認證和支持。有些方案是完全的開源 PaaS 解決方案，而另外一些可能是 CaaS。根據你的企業的需求，這些解決方案可能是比 DIY 容器平台更好的替代品。

企業的擔憂和它們與容器的關係

今天，幾乎每個企業都正在與數字時代轉型打交道，這些轉型影響包括 DevOps 戰略、微服務和雲等多個領域。容器在這些領域中的每一個中都起著相當重要的作用。

DevOps 策略

IT 組織被分成運維和應用開發，他們作為兩個獨立的團隊運作，每一隊都只有他們自己的一套目標。大多數企業為了將這兩個團隊聯合起來正在朝 DevOps 的方向前進。

容器在 DevOps 倡議的成功中發揮著重要的作用。在 DevOps 中成功的關鍵標準之一是增加開發人員在運營中的份額。開發人員不僅應該把代碼交給運維人員，而且他們還應該考慮他們的代碼是如何在生產環境中運行的。普遍的技術是採用「架構即代碼」，而不是提供幾頁容易出錯的安裝說明指示，開發團隊應該提供像編程時的環境配置。

這恰恰就是容器可以解決的問題。可以作為容器的模版的容器鏡像包括了從基本操作系統到應用程序代碼的整個環境堆棧。利用容器，開發人員將不再只是從 Dev 到 QA 再到 Prod 這樣生成應用程序；相反，他們將傳遞一個版本化的容器鏡像，這個鏡像包括生成的運行程序和它運行需要的環境。容器是包羅萬象的，從操作系統庫到中間件再到應用程序的所有東西都被整合進一個鏡像裡面。因此，容器在開發環境運行的方式和它在質量保證環境和生產環境下運行的方式完全一樣。容器是 DevOps 成功的重要因素。


另外，容器平台正在進一步發展。典型的持續集成和交付（CICD）工具，如 Jenkins，可以作為容器，這個容器能在容器平台本身運行整個 CICD 過程，而不需要額外的基礎設施。現在你可以使用 PaaS 平台來生成和運行你的 CICD 管道。

微服務策略

微服務是今天 IT 領域的另一個熱門話題。應用程序是這樣被設計的：把應用程序分解為離散化的小的服務，每個服務完成一個小任務。這些服務中的每一個都可以根據合適的技術用不同的編程語言進行編寫。它們可以由小團隊（雙比薩團隊）創建和管理，並且可以迅速地改變它們。所有這些要求再次需要用到容器。容器足夠小到成為微服務的基礎。容器能夠支持任何你選擇的技術和語言，容器易於創建和運行，並且可以快速地改變。微服務和容器現在已經不分彼此，如果有人說不使用容器來實現微服務，他們將會受到別人奇怪的表情。

實際情況是，雖然微服務有望讓情況變得簡單，但是它們的擴張也增加了複雜性。有幾個微服務的設計和開發模式將能使它們易於實現。這意味著開發人員現在急需這樣一個開發平台，在這個平台下，開發人員可以輕鬆地部署和組織微服務，而且還能：

• 以一種語言不可知的方式實現這些微服務設計模式。
• 不會因代碼侵入而增加代碼的複雜性，以便開發人員能將許多模式的代碼包括進他們的業務邏輯中。
• 足夠靈活以便部署在你所選擇的基礎設施上，並且不會把你捆綁在特定的雲上。

這就是選擇一個正確的容器平台所起作用的地方。在具體的基礎設施上按照某一特定供應商的方法來實現這些微服務將會把你的應用程序捆綁在那些供應商的平台上。使用類似兼容 OCI 的容器的容器化微服務將可以保證你的微服務能夠被運行在任何兼容 OCI 的平台上。

選擇正確的容器平台來運行你的微服務是需要做的另一個重要的決定。今天，有很少的選擇和許多的 FUD。如果你作出選擇時不足夠慎重，其中一些選擇會把你帶到非標準的、特定供應商的路線上。

雲策略

雲戰略是 IT 領域的又一個熱門話題。無論你是否喜歡，服務化模型都是不可避免的變化。如果你不將其作為 IT 服務進行提供，你的開發團隊將可能會找到創建「shadow IT」的方法來訪問雲。另外，儘管使用雲技術將會讓你從資本支出轉移到運營支出，但是，管理雲支出是一個不斷的挑戰。

雲可以提供虛擬機，在你添加額外的虛擬機之前，你要確認這個雲上的 CPU、內存和網路等資源都處於最佳使用狀態。容器在這個地方扮演著很重要的角色。因為容器比虛擬機要小得多。並且，如果你的應用程序正運行在容器中，你可以在虛擬機中安裝更多的容器，這比在每台虛擬機中運行一個應用程序組件要多很多。

公有雲供應商有很多，其中 Amazon Web Services（AWS）、Microsoft Azure 和 Google Cloud 最受歡迎。另外，你可能想在你的基於 OpenStack 的數據中心裡擁有你自己的私有雲。這些雲環境中的每一個都有它們自己的協議、API 和工具。當你想讓你的應用程序在雲上運行時，你不會想要讓您的應用編排被雲供應商所制約，也不會想要維護任何特定雲的代碼。在你的技術上與特定的雲供應商鎖定就像在未來幾年內向供應商簽署空白支票。

雲的可移植性對您的雲戰略至關重要。你可以編寫應用程序，而不用擔心它們在哪裡運行，容器平台可以將你和特定的雲供應商協議隔離開來，從而避免你與一個雲供應商鎖定。

傳統系統

微服務架構帶給開發的優勢很多，但並不是每個應用程序都可以重構它們自己，有些只能重構一部分。傳統的應用程序被普遍接受，它們需要維護和管理。雖然容器可以實現微服務，但容器不僅僅只是微服務。可以想像，你可以將大型應用程序和微服務作為容器來運行，因此只要你選擇正確的容器技術和正確的應用程序平台，就可以將許多（如果不是所有）的傳統的應用程序作為容器運行。

總結

我希望這篇對各種策略和容器的深入剖析有助於你的公司對下一步進行評估。讓我在評論裡面了解您公司學習到的經驗，或者說沒能大步向前跨越，他們還需要我再提供一些什麼信息。

（題圖來源：Maersk Line. CC SA-BY 4.0）

作者簡介：

Veer Muchandi -- 開源愛好者，容器和PaaS倡導者，喜歡學習和分享。

via: https://opensource.com/article/17/1/container-strategy-for-executives

作者：Veer Muchandi 譯者：zhousiyu325 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive