麥克萊恩發(fā)明集裝箱的時(shí)候，或許不會(huì)想到這種運(yùn)輸方式會(huì)推動(dòng)經(jīng)濟(jì)的全球化發(fā)展。當(dāng)一批批貨物被打包搬上火車、輪船、飛機(jī)，集裝箱不僅解決了裝貨慢、載量小的窘境，還將原來(lái)數(shù)月的運(yùn)輸時(shí)間從數(shù)月縮短至數(shù)天。當(dāng)然，考慮到貨物的多樣性，以及具體使用情況，集裝箱并非***藥。這就像是容器，將開發(fā)者的應(yīng)用打包發(fā)布到Linux平臺(tái)上不是一本萬(wàn)利，還要涉及部署成本、操作環(huán)境、安全性等問(wèn)題。

圖片來(lái)自mediaagility

2013年3月，PaaS服務(wù)商dotCloud(后來(lái)的Docker)將應(yīng)用容器引擎Docker開源，代碼托管在Github上。在此之前，容器技術(shù)已經(jīng)在Linux和UNIX領(lǐng)域經(jīng)歷了十多年的變遷。從技術(shù)的角度來(lái)看，Docker基于沙箱機(jī)制可將任何應(yīng)用集成在一個(gè)輕量化、可移植、標(biāo)準(zhǔn)化的容器中，核心問(wèn)題就是利用Linux容器技術(shù)實(shí)現(xiàn)類似虛擬機(jī)的功能。然而，在一片為容器叫好的聲音中，人們也要注意到這種技術(shù)的弱點(diǎn)。

用容器有代價(jià)

容器不是一刀切的解決方案，意味著使用者要具有相對(duì)應(yīng)的專業(yè)知識(shí)，并且要確?；A(chǔ)設(shè)施的完整性，有了好地基才好蓋房子。將容器集成部署到持續(xù)交付管道，使其自動(dòng)化運(yùn)轉(zhuǎn)起來(lái)，需要在每次提交代碼時(shí)執(zhí)行一系列步驟，其中包括一次手動(dòng)遷入代碼庫(kù)的操作。簡(jiǎn)單來(lái)說(shuō)，管道的作用就是讓容器在內(nèi)部經(jīng)過(guò)功能性測(cè)試，合格“上崗”。期間如果有一次執(zhí)行延誤，就會(huì)打破持續(xù)性，并且會(huì)錯(cuò)過(guò)發(fā)現(xiàn)問(wèn)題的時(shí)機(jī)，導(dǎo)致后期投入更多精力來(lái)修補(bǔ)。要知道，在代碼提交的幾分鐘內(nèi)bug報(bào)錯(cuò)與數(shù)周后再察覺(jué)相比，前者的修復(fù)成本要小很多。

需要注意的是，Docker并不會(huì)重寫代碼，只是讓跨平臺(tái)部署變得容易了，想具有擴(kuò)展性還是要由開發(fā)者親自動(dòng)手。Docker不是橫跨所有系統(tǒng)，畢竟系統(tǒng)層的軟件泊接不是停船裝貨那么簡(jiǎn)單。跨系統(tǒng)的時(shí)候，要先保證Docker自身的新版內(nèi)核，并且底層是通用的，再小的差錯(cuò)率放大到成千上萬(wàn)臺(tái)服務(wù)器上都是大風(fēng)險(xiǎn)。同時(shí)，規(guī)?；\(yùn)行容器離不開管理和編排的支持，又是一筆投資開支。

容器不等于虛擬機(jī)

切勿以虛擬機(jī)的視角看待容器，其不是可以隨意編輯或者刪除的對(duì)象，遇到問(wèn)題只能丟棄重建出一個(gè)新的?；蛟S有開發(fā)者遇到這樣的問(wèn)題：容器執(zhí)行過(guò)程中，修改了容器的內(nèi)容(如配置文件信息)，但因?yàn)樾薷某隽藛?wèn)題，導(dǎo)致容器關(guān)閉后無(wú)法啟動(dòng)。為此，開發(fā)者只能創(chuàng)建新鏡像，或者直接修改文件。

此外，Docker的資源隔離水平也比不上虛擬機(jī)，只能對(duì)一些資源共享，其他進(jìn)程需要排隊(duì)入列。容器在內(nèi)核層面也是共享的，在某些環(huán)境中換取了高效率，但可用性和冗余也會(huì)受到影響。與獨(dú)立內(nèi)核的虛擬機(jī)不同，如果有一個(gè)容器內(nèi)核損壞，其共享機(jī)制就會(huì)導(dǎo)致所有關(guān)聯(lián)的容器遭殃。

生產(chǎn)環(huán)境缺陷

成熟的企業(yè)會(huì)使用才出現(xiàn)兩年的數(shù)據(jù)庫(kù)技術(shù)嗎?更何況Docker只是一個(gè)工具，談不上架構(gòu)解決方案。前文提到，部署容器需要鏡像管理、日志、監(jiān)控、負(fù)載均衡等全流程的支持，并且升級(jí)后的向前兼容性較差，這也導(dǎo)致了容器在生產(chǎn)環(huán)境中的弱勢(shì)，更不要說(shuō)為大型應(yīng)用程序創(chuàng)建映像。一些自建生產(chǎn)環(huán)境的用戶會(huì)將Docker放在IaaS上，可能引發(fā)資源消耗超出容器實(shí)例所需的。而在網(wǎng)絡(luò)層，并非所有容器都能被公網(wǎng)訪問(wèn)，這就要在網(wǎng)絡(luò)設(shè)置時(shí)多多留意，為主機(jī)打補(bǔ)丁是常事兒。

部署過(guò)程中，Docker Compose與其他工具相比在生產(chǎn)環(huán)境配置時(shí)復(fù)雜度更高，volume綁定、端口對(duì)接、網(wǎng)絡(luò)參數(shù)都要修改，并且需要調(diào)用很多腳本，以及外部數(shù)據(jù)庫(kù)等工具。拿數(shù)據(jù)庫(kù)管理來(lái)說(shuō)，開發(fā)環(huán)境完全可以跨容器托管，但在生產(chǎn)環(huán)境就要考慮I/O性能等問(wèn)題，用于確保高可用性和可靠的備份及存儲(chǔ)。能力越大，需要注意的點(diǎn)就越多，容器可以將package直接從開發(fā)環(huán)境搬到生產(chǎn)環(huán)境，但在生產(chǎn)環(huán)境仍有要完善的地方。

容器離不開安全

圍繞容器的安全性爭(zhēng)議從未間斷，風(fēng)險(xiǎn)是由內(nèi)向外的，黑客可以通過(guò)破解容器來(lái)訪問(wèn)底層服務(wù)器，進(jìn)而影響到云服務(wù)商的數(shù)據(jù)中心。另一方面，不同的鏡像來(lái)源也讓威脅變得難以預(yù)測(cè)。曾有數(shù)據(jù)顯示，Docker Hub的容器鏡像有超過(guò)30%保護(hù)高風(fēng)險(xiǎn)漏洞，而且這些還經(jīng)常被下載的鏡像。此時(shí)，容器就像潘多拉的魔盒一樣，你永遠(yuǎn)不會(huì)知道里面到底有什么。

從規(guī)范性的角度來(lái)看，容器應(yīng)用商店或許是個(gè)好辦法。事實(shí)上，很多服務(wù)商甚至不知道自己的容器有問(wèn)題，直到漏洞爆發(fā)才發(fā)現(xiàn)。通常，使用者應(yīng)該選擇熟識(shí)的服務(wù)商、避開那些長(zhǎng)期沒(méi)有更新過(guò)的容器。至于提供方，只能把控好代碼質(zhì)量，定期“體檢”。

結(jié)語(yǔ)

未來(lái)，前沿技術(shù)、社區(qū)生態(tài)、企業(yè)支持將成為容器發(fā)展的三大基礎(chǔ),上云容器化已經(jīng)成為趨勢(shì)，但實(shí)際應(yīng)用過(guò)程中還要根據(jù)自身業(yè)務(wù)特性做出判斷，避開容器初期部署時(shí)的不穩(wěn)定因素，這樣才能將商業(yè)價(jià)值***化。