風險與回報：理解軟件容器的指南

我們這些年紀足夠大的人會記得軟件主要通過物理媒體交付的一天。 寬帶互聯網和智能手機的普及將我們帶入了網絡服務時代——託管在雲中的軟件，可由瀏覽器和應用程序等用戶客戶端訪問。

不久前，Web 應用程序直接在私有數據中心的物理機上運行。 為了便於管理，這些應用程序通常是單片的——單個大型服務器將包含所有後端代碼和數據庫。 現在，像亞馬遜這樣的網絡託管服務和管理程序技術的普及已經改變了這一切。 多虧了 Amazon Web Services (AWS) 和 VirtualBox 等工具，將整個操作系統打包到一個文件中變得很容易。

使用 EC2 之類的服務，打包機器映像和將多組虛擬服務器串在一起變得很容易。 隨之而來的是微服務範式——一種軟件架構方法，其中大型單體應用程序被分解成更小的專注於做一件事的服務。 一般來說，這種方法可以更輕鬆地進行擴展和功能開發，因為可以更快地找到瓶頸並且更容易隔離系統更改。

寵物到牲畜

在這種趨勢的高峰期，我成為了一名基礎設施工程師。 我記得使用一系列 bash 腳本在 Amazon 中構建了我的第一個生產環境。 服務器對我來說就像寵物。 我給他們每個人起了可愛的名字。 我仔細觀察他們。 我迅速響應警報並保持它們健康。 我用愛和感情對待這些實例，因為試圖替換它們是痛苦的——就像一隻心愛的寵物。

隨之而來的是 Chef，一個配置管理工具，我的生活幾乎立刻變得輕鬆了。 使用 Chef 和 Puppet 等工具，您可以消除與管理雲系統相關的大部分手動痛苦。 您可以使用它的“環境”構造來分離開發、登台和生產服務器。 您可以使用其“數據包”和“角色”來定義配置參數並推送更改集。 現在，我所有的“寵物”服務器都從服從學校畢業。

然後在 2013 年，Docker 出現了，一個新時代開始了：軟件作為牲畜的時代（向觀眾中的任何素食主義者道歉）。 容器範式是一種編排，而不是配置管理。 Kubernetes、Docker Compose 和 Marathon 等工具專注於移動預定義的圖像，而不是調整正在運行的實例上的配置值。 基礎設施是不可變的； 當一個容器壞了時，我們不會試圖修復它——我們會朝它的頭部開槍並更換它。 我們更關心畜群的健康，而不是個體動物。 我們不再給我們的服務器起可愛的名字了。

獎勵

容器使很多事情變得更容易。 他們讓企業更專注於他們自己的特殊醬汁。 技術團隊可以少擔心基礎設施和配置管理，而主要擔心應用程序代碼。 公司可以更進一步，將託管服務用於 MySQL、Cassandra、Kafka 或 Redis 之類的東西，這樣根本就不必處理數據層。 有幾家初創公司也提供“即插即用”機器學習服務，讓公司無需擔心基礎設施就可以進行複雜的分析。 這些趨勢在無服務器模型中達到了頂峰——一種軟件架構方法，允許團隊在不管理單個 VM 或容器的情況下發佈軟件。 S3、Lambda、Kinesis 和 Dynamo 等 AWS 服務使這成為可能。 因此，為了擴展類比，我們已經從寵物到牲畜，再到某種按需動物服務。

這一切都非常酷。 我們生活在這樣一個時代，一個 12 歲的孩子只需點擊幾下就可以啟動一個複雜的軟件系統，這真是太瘋狂了。 我們應該記住，不久前，這是不可能的。 就在幾位美國總統之前，物理媒體還是標準，只有大公司才有能力製造和分發軟件。 錯誤修復是一種奢侈。 現在，這個 12 歲的孩子可以創建一個 AWS 賬戶，並將他的軟件提供給全世界。 如果有錯誤，有人會在 Slack 上給他找錯誤，幾分鐘後，所有用戶都可以修復。

風險

非常非常酷，但並非沒有代價——依賴亞馬遜等雲服務提供商意味著依賴大公司和專有技術。 如果理查德·斯托曼（Richard Stallman）和愛德華·斯諾登（Edward Snowden）沒有讓你擔心這些事情，那麼最近與 Facebook 的慘敗當然應該有。

對硬件的更大抽像也帶來了透明度和控制力降低的風險。 當運行數百個容器的系統出現故障時，我們必須希望故障會出現在我們可以檢測到的地方。 如果問題出在主機操作系統或底層硬件上，則可能很難確定。 如果您沒有正確的工具，使用 VM 可以在 20 分鐘內解決的中斷可能需要數小時或數天才能使用容器解決。

當涉及到像 Docker 這樣的東西時，我們需要擔心的不僅僅是失敗。 還有安全問題。 無論我們使用什麼容器平台，我們都必須相信沒有後門或未公開的安全漏洞。 使用開源平台也不能保證安全。 如果我們在系統的某些部分依賴第三方容器鏡像，我們可能會受到攻擊。

包起來

由於多種原因，畜牧業範式具有吸引力，但並非沒有缺點。 在急於將整個堆棧容器化之前，技術團隊需要考慮這是否是正確的選擇，並確保他們可以減輕負面影響。

就個人而言，我喜歡使用容器。 隨著新平台和範式的出現，我很高興看到未來十年的發展方向。 然而，作為一名前安全顧問，我足夠謹慎，知道一切都是有代價的。 工程師有責任保持警惕，以確保我們不會放棄作為用戶和開發人員的自主權。 即使是世界上最簡單的 CD/CI 工作流程也不值得。