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

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

用容器有代價

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

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

容器不等于虛擬機

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

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

生產環境缺陷

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

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

容器離不開安全

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

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

結語

未來，前沿技術、社區生態、企業支持將成為容器發展的三大基礎，上云容器化已經成為趨勢，但實際應用過程中還要根據自身業務特性做出判斷，避開容器初期部署時的不穩定因素，這樣才能將商業價值***化。