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

[[259224]]

1. 性能

開發(fā)人員通常不從性能的角度考慮潛在問題，但就因?yàn)槟闶褂肳eb瀏覽器訪問應(yīng)用程序并不意味著它可處理大量并發(fā)事務(wù)。真正測(cè)試后，你才知道其處理能力。

Kubernetes可擴(kuò)展規(guī)模，但也會(huì)占用大量資源。容器可幫助解決架構(gòu)問題，并確保所有必需的依賴項(xiàng)都到位，但它在推出后并不自動(dòng)確保性能。

底層語言運(yùn)行時(shí)環(huán)境、Web服務(wù)器和openssl等庫(kù)的質(zhì)量都會(huì)對(duì)性能產(chǎn)生影響。確保你的Linux發(fā)行版有一批積極主動(dòng)的性能工程師進(jìn)行回歸測(cè)試，更重要的是優(yōu)化整個(gè)架構(gòu)的性能。

2. 兼容性

在Linux界，不同的程序在內(nèi)核上運(yùn)行。大多數(shù)程序使用與內(nèi)核對(duì)接的API：syscall層。如果你堅(jiān)持使用Linux中的syscall層，向前兼容性就很重要。

Linux之父Linus Torvalds有條嚴(yán)格的規(guī)定：內(nèi)核不應(yīng)破壞向后兼容性。容器始終向前兼容，因?yàn)閟yscall層盡量不破壞該功能。

在舊的內(nèi)核上運(yùn)行新的容器映像會(huì)發(fā)生什么?或者你從syscall層進(jìn)入到ioctl、/dev、/proc之類的API會(huì)發(fā)生什么?

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

另一個(gè)問題是，如果只使用與C庫(kù)有關(guān)的syscall函數(shù)，你可能沒問題。但應(yīng)用程序更有可能調(diào)入一款不是應(yīng)用程序一部分的輔助軟件，比如故障排查或監(jiān)控組件，它們使用ioctl /proc或/dev之類的其他內(nèi)核API，這可能會(huì)導(dǎo)致問題。

如果升級(jí)容器主機(jī)，它可能再無法運(yùn)行容器。在虛擬機(jī)領(lǐng)域，你通常不必?fù)?dān)心(然而就算使用虛擬化，一些架構(gòu)或芯片組可能會(huì)導(dǎo)致問題)，但在物理服務(wù)器領(lǐng)域，一些架構(gòu)或芯片組可能導(dǎo)致問題。

3. 與現(xiàn)有基礎(chǔ)設(shè)施整合

受支持的軟硬件生態(tài)系統(tǒng)對(duì)應(yīng)于底層的Linux發(fā)行版。如果你需要ARM支持，它必須要有?？紤]可支持性――這適用于面向硬件的容器主機(jī)和面向軟件的容器映像。

選擇容器映像和容器主機(jī)時(shí)，這個(gè)“購(gòu)買標(biāo)準(zhǔn)”常被遺忘。但記住，Linux發(fā)行版的生態(tài)系統(tǒng)(硬件和軟件)是可供容器主機(jī)(硬件)和容器映像(軟件)使用的生態(tài)系統(tǒng)。如果你的Linux發(fā)行版支持某個(gè)特定的硬件或云提供商，那么你的容器主機(jī)就能夠順暢運(yùn)行。

如果你的應(yīng)用程序是為特定的Linux發(fā)行版設(shè)計(jì)和構(gòu)建的，將那些應(yīng)用程序放入基于該Linux發(fā)行版的容器映像中會(huì)容易得多。

4. 安全

一旦容器映像部署到生產(chǎn)環(huán)境，它將使你的應(yīng)用程序及其所有依賴項(xiàng)暴露在危險(xiǎn)重重的互聯(lián)網(wǎng)面前。這包括數(shù)據(jù)泄露、特洛伊木馬圖片等。為容器環(huán)境選擇容器映像和容器主機(jī)時(shí)要考慮所有這些方面。

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

從安全角度來看，了解組件的質(zhì)量至關(guān)重要;始終使用信得過的來源。記?。喝萜髟谀阆螺d那天可能是好的，但幾年后可能變壞了。

5. 大小

容器執(zhí)行大量構(gòu)建操作，每當(dāng)重建容器都會(huì)重新編譯應(yīng)用程序。

現(xiàn)在，開發(fā)人員負(fù)責(zé)映像中的一切。一年后，如果某個(gè)庫(kù)中的代碼破壞向后兼容性，容器出故障，誰來修復(fù)?他要有開發(fā)人員的技能，而不只是執(zhí)行“yum update”之類的操作?？赡苄枰匦戮幾g應(yīng)用程序。

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

一旦添加軟件，基本映像的大小無關(guān)緊要，現(xiàn)在它是400 Mb或500 Mb。

正在開發(fā)兩種主要的容器化應(yīng)用程序。一種是基于Linux基本映像構(gòu)建的，另一種是從頭開始構(gòu)建的。

在這兩種應(yīng)用程序中，用戶常常對(duì)容器映像的大小敏感，因?yàn)樗鼤?huì)影響將容器映像提取到容器主機(jī)所需的時(shí)間。如果從頭開始構(gòu)建，并部署靜態(tài)編譯的二進(jìn)制文件，選擇小巧的基本映像或從頭開始構(gòu)建很重要。

為用于企業(yè)內(nèi)部的軟件構(gòu)建整個(gè)生態(tài)系統(tǒng)時(shí)，考慮整條供應(yīng)鏈的大小(所有RPM程序包及依賴項(xiàng))更重要，因?yàn)榛A(chǔ)層常?？梢怨蚕砗途彺妗p小遭受威脅的面積的關(guān)鍵是減少庫(kù)和語言運(yùn)行時(shí)環(huán)境的重復(fù)副本，從而減小在整個(gè)環(huán)境中的占用空間。

6. 支持

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

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

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

兩者都非常重要，具體取決于你支持容器化應(yīng)用程序的時(shí)間。

生命周期支持的上下文很重要，因?yàn)閼?yīng)用程序的運(yùn)行時(shí)間比你所想的要長(zhǎng)?？赡苋迥?，或者更久。應(yīng)用程序/系統(tǒng)有眾多實(shí)例，運(yùn)行了多年。你要考慮支持該基本映像多長(zhǎng)時(shí)間來運(yùn)行yum update。然后你要回到第一個(gè)模式來更改代碼、實(shí)現(xiàn)不同版本的庫(kù)，并將其放回到開發(fā)人員的手中，這可能代價(jià)高昂。

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

原文標(biāo)題：6 critical factors to consider when deploying containers，作者：Scott Matteson

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】