在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技术。
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运作的时候，使用者可以拥有更多权限，同时也不会影响到宿主主机。
本文转自d1net（转载）
