优点总结(后面进行讨论)
更高效的利用系统资源
更快速的启动时间
一致的运行环境
持续交付和部署
更轻松的迁移
更轻松的维护和扩展
讨论 ===== 更高效？
docker是容器型虚拟化，不需要进行硬件虚拟、运行完整操作系统等额外的开销。所以提高了对系统资源的利用率 简单来说：可以在同样配置的机器上虚拟运行更多的应用。
更快速？
因为docker不需要运行完成的操作系统，而是直接运行宿主机的内核，因此可以做到秒级甚至毫秒级的启动关闭。 简单来说：加载1万个文件和100个文件的速度区别
一致的运行环境？ ※※※※※
主要针对：开发–测试–线上 几大环节。 对于phper来说，在本地开发一般是使用phpstudy或者其他的集成环境来开发，而在线上则一般则使用其他安装方式 一些php集成环境可能为了减小软件体积，阉割了一些组件，所以不太适合运营使用 这就造成了环境的不一致问题，可能是由于php、nginx版本不一致，或者某个配置参数本地有打开、线上无打开等情况的出现。 出现问题了那就需要phper进行调试、调整，无疑浪费了巨大的精力，只为了能正常运行。 假设有一天，公司决定更换服务器，那可能又要进行以上一系列的配置修改… 假设公司开发的项目是商业项目，源码可能对外出售，其他公司的部署又是一系列的问题… 如果使用了docker，可以将项目需要的环境打包成镜像，其他机器可以直接拉取镜像进行部署。 如thinkphp5等支持路由的框架在nginx上可能无法正常运行的问题（只能访问默认hello页，其他的页面出现404） 这是由于nginx没有配置PATH_INFO 导致框架无法解析路由 这个问题需要修改nginx.conf文件来解决，修改简单如下
location ~ .php { 这里可能出现 .php$ 需要把$去掉，否则无法获取index.php后的内容 try_files $uri =404; fastcgi\_split\_path_info ^(.+.php)(/.+)$; # 新增这一行 fastcgi_pass php:9000; fastcgi_index index.php; fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script_name; fastcgi\_param PATH\_INFO $fastcgi\_path\_info; # 新增这一行 include fastcgi_params; }
修改不算特别复杂，但如果每个机器都要这样子检查一次，调试修改 那不是很浪费时间吗？ ① 我们可以使用docker拉取一个官方的nginx镜像，然后修改配置后提交成新镜像作为项目的使用镜像。 ② 我们可以通过挂载文件将配置文件挂载到容器里保证配置最终的一致
持续交付和部署、更轻松迁移？ ※※※※※
对于开发和运维人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。 使用Docker可以通过定制应用镜像来实现持续集成，持续交付，部署。开发人员可以通过Dockerfile来进行镜像构建，并结合持续集成系统进行集成测试，而运维人员则可以在生产环境中快速部署该镜像，甚至结合持续部署系统进行自动部署 如果使用了docker-compose则可以更好的管理应用的容器关系，加快部署步骤 在上一章我们使用docker-compose搭建了一个php+nginx的应用，目录结构如下
work 总目录 ├──app 代码存放目录 │ └──index.php ├──config 配置存放目录 │ └──nginx │ └──site.conf └──docker-compose.yml
假设我们的一个商业应用是使用thinkphp5开发，则将我们的应用程序放入app目录中。 在docker-compose.yml 定义好各个容器的参数和关系，在config目录中定义好容器的配置参数。 于是在另一个机器部署该应用只需要把work压缩，放上去，解压，进入work目录 运行 $ dokcer-compose up -d 则可以在保证配置一致的情况下部署成功！而不会出现部分机器还需要修改nginx.conf来支持PATH_INFO的情况（我们已经在config/nginx/site.conf配置好了）
更轻松维护和扩展？
Docker使用的分层存数以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单，此外，Docker团队同各个开源项目团队一起维护了一大批高质量的官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。
