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

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

用容器有代價

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

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

容器不等于虛擬機

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

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

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

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

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

容器離不開安全

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

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

結(jié)語

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