在Docker問世後，其打包應用程式、快速部署的能耐，受到開發者的廣大歡迎。在2015年，Docker進一步推出私有儲存庫功能Docker Registry，以及原生網路功能Docker Networking，讓企業更容易自行架構Docker叢集。這些都讓Docker逐漸成為正式環境的新選擇。
在Docker受到一片好評下，著有《Docker源碼分析》，大受到中國Docker社群好評的孫宏亮認為，Docker至少有3大缺點，還無法滿足各種環境的需求。深入研究Docker原始碼的他，也是中國Docker PaaS服務商DaoCloud參與第一線開發的軟體工程師。
別於多數Docker開發者從應用程式面切入談論Docker的角度，孫宏亮在2015 Container Summit上，則是選擇從Docker的程式碼設計架構，來剖析優缺點。
孫宏亮也指出，Container技術雖然已經發展許久，但是透過Docker獨特的映像檔設計，才使Container技術在近年發揚光大。
獨特映像檔設計讓Docker爆紅
Container技術最早可以追溯至1979年時推出的Unix V7，其中的chroot系統呼叫指令，透過更改程序的根目錄，達到系統程序隔離的效果。而發展已經超過30年的Container技術，為何遲至2013年才因為Docker橫掃全球IT業界，孫宏亮解釋，因為Docker映像檔的設計，使得Docker得以打破過去「程式碼即應用」的觀念。
傳統上認為，軟體開發結束後，所產出的成果即是程式碼，或是能夠編譯執行的二元執行檔。
而為了讓這些程式碼可以順利執行，開發團隊也得準備完整的部署文件，讓維運團隊得以部署應用程式，不過，即便如此，仍然常常發生部署失敗的狀況。孫宏亮表示，Docker透過映像檔，將作業系統核心外，運作應用程式所需要的系統環境，由下而上打包，達到應用程式跨平臺間的無縫接軌運作。
而微軟已經宣布，將在下一代的Windows Server 2016中內建Docker Engine，使得Windows Sever可以原生支援Docker。但孫宏亮也解釋，目前Windows對Docker的支援，多數還是在API層。除了Windows作業系統與Linux在Kernel層差異很大外，Windows也有發展有自家的Container技術。
-600.png)
Docker映像檔的設計，使得Docker得以打破過去「程式碼即應用」的觀念。透過映像檔，將作業系統核心除外，運作應用程式所需要的系統環境，由下而上打包，達到應用程式跨平臺間的無縫接軌運作。（圖片來源／孫宏亮）
系統服務Docker化的障礙
雖然Docker透過了映像檔設計，解決傳統維運團隊在部署上的問題。但是，在將系統服務Docker化、應用程式Docker化時，使用者仍然會碰到實際面的問題。
孫宏亮表示，當應用程式必須調度系統的服務，例如利用cron服務，將工作設定為自動化執行，或是執行syslog服務收集系統日誌時，此時開發者就會碰到使用Docker的障礙。
例如，雖然可以使用Docker將cron服務打包，但是Docker化的cron服務，與傳統Linux中cron服務間有很大的區別。孫宏亮表示，一旦將cron服務容器化後，原始的環境變數設定都會失效。所以使用者必須分析軟體、Container的運行方式，才能滿足使用的需求。另外，Docker與Linux Kernel的溝通能力薄弱，行程間溝通（inter-process communication，IPC）會被進行隔離。像是NFS伺服器接受客戶端提出的請求後，會將需求再次傳遞給Linux Kernel，「使用者將這些功能容器化前，都必須再三考慮。」他表示。
並非任何應用程式都適合Docker化
而在應用程式Docker化的方面，雖然Docker的快速部署特性很吸引人，但是未必所有的應用程式都適合Docker化，像是MySQL，孫宏亮認為如果將其Docker化則存在一些弊端。例如，當使用者的資料需要進行額外備份，需要創造MySQL的資料庫Container，可以透過Docker run指令，創建一個MySQL的Database Container，或是使用docker run指令，修改MySQL的環境變數。而這些環境變數會透過Docker Daemon、Docker Engine，用json的檔案格式儲存在Docker Container中。
存在於Docker Container中的環境變數，對於Docker Engine並沒有意義，但是對於使用Docker的用戶則存在隱憂，如果被無關的第三方看見，使用者的Container可能會產生資安上疑慮。所以，孫宏亮認為，傳統開發者在使用MySQL的思維，並不能無縫轉移到Docker的世界中運作。
孫宏亮表示，在Docker問世後，Docker官方也宣稱Docker的設計是以應用程式為中心（application-centric），希望使用者將心力集中在開發應用程式，而Docker官方也不特別鼓勵使用者，將Docker視為取代VM，作為新一代運算單元的想法。他認為，當Docker用於打包網頁應用程式，或是比較單純的系統服務，可以達到很好的Docker化效果。不過，如果要將Docker的使用範圍擴大，開始涉及到作業系統的基礎運行層次，或是分散式系統在推動微服務時，使用Docker會產生一些問題。
共用Linux Kernel，讓Docker安全性先天不足
而從技術面的角度切入，孫宏亮表示，Docker就是分配硬體資源、實現資源隔離的Container技術。而談到資源隔離，他表示，一般人會聯想到Container技術中最基本的觀念，像是命名區域namespace及cgroup等技術。而Docker Container技術的火紅，以前無法透過VM執行的功能，現在也可以透過Container實現。許多使用者因此也開始議論，是否可以利用Container技術取代VM。
一般的實體伺服器，只要具備Linux Kernel就可以運行Container，或是透過Hypervisor層，使用Linux Kernel上運作的虛擬機，運行Container。孫宏亮認為，以這樣的角度看待，Linux Kernel是運作Container，所需滿足的最重要條件，而無論是實體伺服器或是VM，都能達到上述的條件。不過，Container在實體機上運作，可以達到媲美裸機的效能，而在VM中運作時，則會產生效能折損。
而談到Container的資源隔離，孫宏亮表示，一般使用者最直覺想到的不外乎是CPU、記憶體以及IO等運算資源。而他認為，「資源」的範疇應該不只如此。雖然Container可以透過cgroup、namespace做到運算資源的隔離，但是，「如果沒有Linux Kernel，使用者也不可能運作Container。」他表示，如果將Linux Kernel也納入資源的範疇，因為Container與作業系統同時共用Kernel，所以其實並沒有實現資源隔離。但是，VM與VM之間，並不會共用作業系統核心。因此，VM的資源隔離性一定會比Container來得更好。
雖然Docker Container也會受到資源的隔離、控制，以及權限控制，但是由於跟Linux共用作業系統核心，進而會產生安全上的漏洞。為了解決這樣的問題，孫宏亮表示，可以透過Linux的capability機制，加強權限的控管，使Container內部的root跟外部的root權限產生差異外，同時也讓Container在系統管理的能力，與宿主主機進行區隔，藉此解決Container的安全問題。
在去年推出的Docker 1.9.0當中，Docker也加入了username space機制，孫宏亮表示，在安全性方面，這是Docker所達成的一個里程碑。只要透過namespace，讓Container運作的時候，使用者可以擁有更多權限，同時也不會影響到宿主主機。