【51CTO.com快譯】容器功能強大，易于提供應用程序或服務。雖然容器的目的是為了減少可變因素，從而簡化和提高效率，但有許多復雜因素要考慮。在企業界，考慮這六個因素很重要：

[[259224]]

1. 性能

開發人員通常不從性能的角度考慮潛在問題，但就因為你使用Web瀏覽器訪問應用程序并不意味著它可處理大量并發事務。真正測試后，你才知道其處理能力。

Kubernetes可擴展規模，但也會占用大量資源。容器可幫助解決架構問題，并確保所有必需的依賴項都到位，但它在推出后并不自動確保性能。

底層語言運行時環境、Web服務器和openssl等庫的質量都會對性能產生影響。確保你的Linux發行版有一批積極主動的性能工程師進行回歸測試，更重要的是優化整個架構的性能。

2. 兼容性

在Linux界，不同的程序在內核上運行。大多數程序使用與內核對接的API：syscall層。如果你堅持使用Linux中的syscall層，向前兼容性就很重要。

Linux之父Linus Torvalds有條嚴格的規定：內核不應破壞向后兼容性。容器始終向前兼容，因為syscall層盡量不破壞該功能。

在舊的內核上運行新的容器映像會發生什么?或者你從syscall層進入到ioctl、/dev、/proc之類的API會發生什么?

兼容性存在時間和空間方面的限制，良好的設計和測試有所幫助。面向容器映像和主機的Linux發行版要深入考慮這些問題，否則用戶會陷入糟糕狀態。在內核層、編譯器層(gcc)和庫層(glibc)以及syscall接口之外的API都是如此。

另一個問題是，如果只使用與C庫有關的syscall函數，你可能沒問題。但應用程序更有可能調入一款不是應用程序一部分的輔助軟件，比如故障排查或監控組件，它們使用ioctl /proc或/dev之類的其他內核API，這可能會導致問題。

如果升級容器主機，它可能再無法運行容器。在虛擬機領域，你通常不必擔心(然而就算使用虛擬化，一些架構或芯片組可能會導致問題)，但在物理服務器領域，一些架構或芯片組可能導致問題。

3. 與現有基礎設施整合

受支持的軟硬件生態系統對應于底層的Linux發行版。如果你需要ARM支持，它必須要有。考慮可支持性――這適用于面向硬件的容器主機和面向軟件的容器映像。

選擇容器映像和容器主機時，這個“購買標準”常被遺忘。但記住，Linux發行版的生態系統(硬件和軟件)是可供容器主機(硬件)和容器映像(軟件)使用的生態系統。如果你的Linux發行版支持某個特定的硬件或云提供商，那么你的容器主機就能夠順暢運行。

如果你的應用程序是為特定的Linux發行版設計和構建的，將那些應用程序放入基于該Linux發行版的容器映像中會容易得多。

4. 安全

一旦容器映像部署到生產環境，它將使你的應用程序及其所有依賴項暴露在危險重重的互聯網面前。這包括數據泄露、特洛伊木馬圖片等。為容器環境選擇容器映像和容器主機時要考慮所有這些方面。

可能你不是從Red Hat容器目錄下載該容器映像，而是選擇從某個可疑網站下載。這是個壞主意。如果不從已知好的容器入手，有人會注入惡意代碼，而你渾然不知。

從安全角度來看，了解組件的質量至關重要;始終使用信得過的來源。記住：容器在你下載那天可能是好的，但幾年后可能變壞了。

5. 大小

容器執行大量構建操作，每當重建容器都會重新編譯應用程序。

現在，開發人員負責映像中的一切。一年后，如果某個庫中的代碼破壞向后兼容性，容器出故障，誰來修復?他要有開發人員的技能，而不只是執行“yum update”之類的操作。可能需要重新編譯應用程序。

另一種方法是構建基本映像，它有程序包，比如用openssl動態編譯的Web服務器軟件，性能問題可通過yum update來修復以獲取新的程序包。這比更改代碼容易得多，不過最終映像更龐大。

一旦添加軟件，基本映像的大小無關緊要，現在它是400 Mb或500 Mb。

正在開發兩種主要的容器化應用程序。一種是基于Linux基本映像構建的，另一種是從頭開始構建的。

在這兩種應用程序中，用戶常常對容器映像的大小敏感，因為它會影響將容器映像提取到容器主機所需的時間。如果從頭開始構建，并部署靜態編譯的二進制文件，選擇小巧的基本映像或從頭開始構建很重要。

為用于企業內部的軟件構建整個生態系統時，考慮整條供應鏈的大小(所有RPM程序包及依賴項)更重要，因為基礎層常常可以共享和緩存。減小遭受威脅的面積的關鍵是減少庫和語言運行時環境的重復副本，從而減小在整個環境中的占用空間。

6. 支持

支持主要有兩種：生命周期支持和白手套支持。

生命周期決定了支持時間以及為容器映像中的任何特定程序(RPM或Debs)發布哪些補丁。

白手套支持讓你可以提交工單、獲得熱修補程序以及主張上游更改。

兩者都非常重要，具體取決于你支持容器化應用程序的時間。

生命周期支持的上下文很重要，因為應用程序的運行時間比你所想的要長。可能三五年，或者更久。應用程序/系統有眾多實例，運行了多年。你要考慮支持該基本映像多長時間來運行yum update。然后你要回到第一個模式來更改代碼、實現不同版本的庫，并將其放回到開發人員的手中，這可能代價高昂。

問問自己：我的容器映像是否有更新?要是出了問題，可以打電話給某人，獲得修復程序嗎?如果我有獨特的問題，可以要求開發補丁嗎?能夠提交工單、要求補丁與僅僅運行yum update是不一樣的支持級別。

原文標題：6 critical factors to consider when deploying containers，作者：Scott Matteson

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】