web服务器：nginx
web程序：php + node
数据库：mysql
搜索引擎：elasticsearch
队列服务：gearman
缓存服务：redis + memcache
前端构建工具：npm + bower + gulp
php cli工具：composer + phpunit
因此团队的开发环境部署随之暴露出若干问题：
依赖服务很多，本地搭建一套环境成本越来越高，初级人员很难解决环境部署中的一些问题
服务的版本差异及os的差异都可能导致线上环境bug
项目引入新的服务时所有人的环境需要重新配置
怎样才算是好的开发环境
首先，我们得知道什么才是好的开发环境， 对于我而言，一个好的开发环境需要具备以下几个特点：
可随意使用。我必须可以随意删除和创建新的环境。
快速启动。我想要用它工作时候，它立马就能用。
易于更新。在我们行业中，事物发展变化非常快，必须能让我很容易将我的开发环境更新到新的软件版本。
什么是php开发环境
目前web应用错综复杂，php开发环境需要很多的东西，为了保证环境的简单性，需要做各种各样的限制。
我们这次使用nginx、php5-fpm、mysql来运行synmfony项目。由于在容器中运行命令行会更复杂，所以这方面的内容我会放到下一篇博客中再说。
pet 与 cattle
另一个我们要讨论的重点是：我们要把开发环境部署在多容器还是单容器中。 两种方式各有优点：
单容器易于分发、维护。因为它们是独立的，所有的东西都运行在同一个容器中，这点就像是一个虚拟机。但这也意味着，当你要升级其中的某样东西（比如php新版本）的时候， 需要重新构建整个容器。
多容器可以在添加组件时提供更好的模块化。因为每个容器包含了堆栈的一部分：web、php、mysql等，这样可以单独扩展每个服务或者添加服务，并且不需要重建所有的东西。
初始化工程
首先要做的是初始化一个新的symfony工程. 推荐的方法是用composer的create-project命令。本来可以在工作站上安装composer，但是那样太简单了。这次我们通过docker来使用它。
我之前发过一篇关于docker命令的文章：make docker commands（好吧，我说谎了，我本来把它写在这篇文章中了，然后觉得把它独立出来会比较好）。
不管怎么样，你可以读一下。接下来如果还没有composer命令的话，你可以创建一个属于自己的composer 别名。
$ alias composer="docker run -i -t -v \$pwd:/srv ubermuda/composer"
现在你可以初始化symfony工程了：
$ composer create-project symfony/framwork-standard-edition someproject
容器
构建一个运行标准symfony项目且自给自足的容器相当容易，只需要安装好常用的nginx、php5-fpm和mysql-server即可，然后把预先准备好的nginx的虚拟主机配置文件扔进去，再复制一些配置文件进去就完事了。
本容器的源代码在github上的 ubermuda/docker-symfony仓库中可以找到。 dockerfile 是docker构建镜像要用到的配置文件，我们来看一下:
from debian:wheezy env debian_frontend noninteractive run apt-get update -y run apt-get install -y nginx php5-fpm php5-mysqlnd php5-cli mysql-server supervisor run sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf run sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf run sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf run echo "\ndaemon off;" >> /etc/nginx/nginx.conf add vhost.conf /etc/nginx/sites-available/default add supervisor.conf /etc/supervisor/conf.d/supervisor.conf add init.sh /init.sh expose 80 3306 volume ["/srv"] workdir /srv cmd ["/usr/bin/supervisord"]
我们通过扩展 debian:wheezy 这个基础镜像开始，然后通过一系列的sed命令来配置nginx和php5-fpm。
run sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf run sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf run sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf run echo "\ndaemon off;" >> /etc/nginx/nginx.conf
这里我们要做两件事。 首先配置php5-fpm和nginx让他们在前台运行以便supervisord可以追踪到他们。
然后，配置php5-fpm以指定的用户运行web-server，并处理好文件权限。
接下来需要安装一组配置文件，首先是nginx的虚拟主机配置文件vhost.conf:
server { listen 80; server_name _; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; root /srv/web; index app_dev.php; location / { try_files $uri $uri/ /app_dev.php?$query_string; } location ~ [^/]\.php(/|$) { fastcgi_pass unix:/var/run/php5-fpm.sock; include fastcgi_params; } }
因为我们不需要域名，所以把server_name设成了_（有点像perl的$_占位符变量）， 并配置根目录（document root）为/svr/web， 我们会把应用程序部署在/srv下，剩下的就是标准的mginx + php5-fpm配置.
因为一个容器每次只能运行一个程序， 我们需要supervisord（或者任何别的进程管理器，不过我比较中意supervisord）。幸运的是， 这个进程管理器会产生我们需要的所有进程！下面是一小段supervisord的配置：
[supervisord] nodaemon=true [program:nginx] command=/usr/sbin/nginx [program:php5-fpm] command=/usr/sbin/php5-fpm [program:mysql] command=/usr/bin/mysqld_safe [program:init] command=/init.sh autorestart=false redirect_stderr=true redirect_stdout=/srv/app/logs/init.log
这里我们需要做的是定义所有的服务， 加上一个特殊的program:init进程，它不是一个实际的服务，而是一个独创的运行启动脚本的方式。
这个启动脚本的问题在于，它通常需要先启动某些服务。比如，你可能要初始化一些数据库表，但前提是你得先把mysql跑起来，一个可能的解决办法是，在启动脚本中启动mysql，然后初始化表，然后为了防止影响到supervisord的进程管理，需要停掉mysql，最后再启动supervisord。
这样的脚本看起来类似下面这样：
/etc/init.d/mysql start app/console doctrine:schema:update --force /etc/init.d/mysql stop exec /usr/bin/supervisord
看起来丑爆了有木有，咱换种方式，让supervisor来运行它并且永不重启。
实际的init.sh脚本如下：
#!/bin/bash ret=1 while [[ ret -ne 0 ]]; do sleep 1; mysql -e 'exit' > /dev/null 2>&1; ret=$? done db_name=${db_name:-symfony} mysqladmin -u root create $db_name if [ -n "$init" ]; then /srv/$init fi
脚本先等待mysql启动，然后根据环境变量db_name创建db，默认为symfony， 然后在init环境变量中查找要运行的脚本，并尝试运行它。本文的结尾有说明如何使用这些环境变量。
构建并运行镜像
万事俱备只欠东风。我们还要构建symfony docker镜像， 使用docker build命令:
$ cd docker-symfony $ docker build -t symfony .
现在，可以使用它来运行你的symfony工程了:
$ cd someproject $ docker run -i -t -p -v $pwd:/srv symfony
我们来看看这一连串的选项分别是干嘛的:
-i 启动交互（interactive）模式， 也就是说，stdio（标准输入输出）连接到了你当前的终端上。当你要接收日志或者给进程发送信号时，它很有用。
-t 为容器创建一个虚拟tty， 它跟-i是好基友，通常一起使用。
-p 告诉docker守护进程发布所有指定的端口， 本例中为80端口。
-v $pwd:/srv 把当前目录挂载到容器的/srv目录。挂载一个目录使得目录内容对目标挂载点可用。
现在你还记得之前提到的db_name和init环境变量了吧，干嘛用的呢：用于自定义你的环境。 基本上你可以通过 docker run的-e选项在容器中设置环境变量，启动脚本会拿到环境变量，因此，如果你的db名为some_project_dev， 你就可以这么运行容器：
$ docker run -i -t -p -v $pwd:/srv -e db_name=some_project_dev symfony
init 环境变量就更强大了，它允许你启动时运行指定的脚本。比如， 你有一个bin/setup脚本运行composer install命令并且设置数据库schema:
#!/bin/bash composer install app/console doctrine:schema:update --force
用-e来运行它：
$ docker run -i -t -p \ -v $pwd:/srv \ -e db_name=some_project_dev \ -e init=bin/setup
注意，-e选项可以在docer run中多次使用，看起来相当酷。另外，你的启动脚本需要可执行权限（chmod +x）。
现在我们通过curl发送请求到容器，来检查一下是否所有的东西都像预期一样工作。首先，我们需要取到docker映射到容器的80端口的公共端口，用docker port命令:
$ docker port $(docker ps -aql 1) 80 0.0.0.0:49153
docker ps -aql 1 是个好用的命令，可以方便的检索到最后一个容器的id， 在我们的例子中，docker 把容器的80端口映射到了49153端口。我们 curl 一下看看。
$ curl http://localhost:49153 you are not allowed to access this file. check app_dev.php for more information.
当我们不从localhost（译者注：容器的localhost）访问dev controller时，得到了symfony的默认错误消息，这再正常不过了， 因为我们不是从容器内部发送 curl 请求的， 所以，可以安全的从前端控制器web/app_dev.php中移除这些行。
// this check prevents access to debug front controllers that are deployed by accident to production servers. // feel free to remove this， extend it， or make something more sophisticated. if (isset($_server['http_client_ip']) || isset($_server['http_x_forwarded_for']) || !(in_array(@$_server['remote_addr']， array('127.0.0.1'， 'fe80::1'， '::1')) || php_sapi_name() === 'cli-server') ) { header('http/1.0 403 forbidden'); exit('you are not allowed to access this file. check '.basename(__file__).' for more information.'); }
这些行阻止了任何从localhost以外的地方访问dev controller。
现在再curl的时候就可以正常工作了，或者用浏览器访问 http://localhost:49153/：
下面介绍docker构建php项目开发环境过程中的演进，本文中假设你的操作系统为linux，已经安装了docker，并且已经了解docker是什么，以及docker命令行的基础使用，如果没有这些背景知识建议先自行了解。
首先还是从一个php在docker容器下的hello world实例开始。我们准备这样一个php文件index.php：
<?php echo "php in docker";
然后在同目录下创建文本文件并命名为dockerfile，内容为：
# 从官方php镜像构建 from php # 将index.php复制到容器内的/var/www目录下 add index.php /var/www/ # 对外暴露8080端口 expose 8080 # 设置容器默认工作目录为/var/www workdir /var/www/ # 容器运行后默认执行的指令 entrypoint ["php", "-s", "0.0.0.0:8080"]
构建这个容器：
docker build -t allovince/php-helloworld .
运行这个容器
docker run -d -p 8080:8080 allovince/php-helloworld
查看结果：
curl localhost:8080 php in docker
这样我们就创建了一个用于演示php程序的docker容器，任何安装过docker的机器都可以运行这个容器获得同样的结果。而任何有上面的php文件和dockerfile的人都可以构建出相同的容器，从而完全消除了不同环境，不同版本可能引起的各种问题。
想象一下程序进一步复杂，我们应该如何扩展呢，很直接的想法是继续在容器内安装其他用到的服务，并将所有服务运行起来，那么我们的dockerfile很可能发展成这个样子：
from php add index.php /var/www/ # 安装更多服务 run apt-get install -y \ mysql-server \ nginx \ php5-fpm \ php5-mysql # 编写一个启动脚本启动所有服务 entrypoint ["/opt/bin/php-nginx-mysql-start.sh"]
虽然我们通过docker构建了一个开发环境，但觉不觉得有些似曾相识呢。没错，其实这种做法和制作一个虚拟机镜像是差不多的，这种方式存在几个问题：
如果需要验证某个服务的不同版本，比如测试php5.3/5.4/5.5/5.6，就必须准备4个镜像，但其实每个镜像只有很小的差异。
如果开始新的项目，那么容器内安装的服务会不断膨胀，最终无法弄清楚哪个服务是属于哪个项目的。
使用单一进程容器
上面这种将所有服务放在一个容器内的模式有个形象的非官方称呼：fat container。与之相对的是将服务分拆到容器的模式。从docker的设计可以看到，构建镜像的过程中可以指定唯一一个容器启动的指令，因此docker天然适合一个容器只运行一种服务，而这也是官方更推崇的。
分拆服务遇到的第一个问题就是，我们每一个服务的基础镜像从哪里来？这里有两个选项：
选项一、 统一从标准的os镜像扩展，比如下面分别是nginx和mysql镜像
from ubuntu:14.04 run apt-get update -y && apt-get install -y nginx
from ubuntu:14.04 run apt-get update -y && apt-get install -y mysql
这种方式的优点在于所有服务可以有一个统一的基础镜像，对镜像进行扩展和修改时可以使用同样的方式，比如选择了ubuntu，就可以使用apt-get指令安装服务。
问题在于大量的服务需要自己维护，特别是有时候需要某个服务的不同版本时，往往需要直接编译源码，调试维护成本都很高。
选项二、 直接从docker hub继承官方镜像，下面同样是nginx和mysql镜像
from nginx:1.9.0
from mysql:5.6
docker hub可以看做是docker的github，docker官方已经准备好了大量常用服务的镜像，同时也有非常多第三方提交的镜像。甚至可以基于docker-registry项目在短时间内自己搭建一个私有的docker hub。
基于某个服务的官方镜像去构建镜像，有非常丰富的选择，并且可以以很小的代价切换服务的版本。这种方式的问题在于官方镜像的构建方式多种多样，进行扩展时需要先了解原镜像的dockerfile。
出于让服务搭建更灵活的考虑，我们选择后者构建镜像。
为了分拆服务，现在我们的目录变为如下所示结构：
~/dockerfiles ├── mysql │ └── dockerfile ├── nginx │ ├── dockerfile │ ├── nginx.conf │ └── sites-enabled │ ├── default.conf │ └── evaengine.conf ├── php │ ├── dockerfile │ ├── composer.phar │ ├── php-fpm.conf │ ├── php.ini │ ├── redis.tgz └── redis └── dockerfile
即为每个服务创建单独文件夹，并在每个服务文件夹下放一个dockerfile。
mysql容器
mysql继承自官方的mysql5.6镜像，dockerfile仅有一行，无需做任何额外处理，因为普通需求官方都已经在镜像中实现了，因此dockerfile的内容为：
from mysql:5.6
在项目根目录下运行
docker build -t eva/mysql ./mysql
会自动下载并构建镜像，这里我们将其命名为eva/mysql。
由于容器运行结束时会丢弃所有数据库数据，为了不用每次都要导入数据，我们将采用挂载的方式持久化mysql数据库，官方镜像默认将数据库存放在/var/lib/mysql，同时要求容器运行时必须通过环境变量设置一个管理员密码，因此可以使用以下指令运行容器：
docker run -p 3306:3306 -v ~/opt/data/mysql:/var/lib/mysql -e mysql_root_password=123456 -it eva/mysql
通过上面的指令，我们将本地的3306端口绑定到容器的3306端口，将容器内的数据库持久化到本地的~/opt/data/mysql，并且为mysql设置了一个root密码123456
nginx容器
nginx目录下提前准备了nginx配置文件nginx.conf以及项目的配置文件default.conf等。dockerfile内容为：
from nginx:1.9 add nginx.conf /etc/nginx/nginx.conf add sites-enabled/* /etc/nginx/conf.d/ run mkdir /opt/htdocs && mkdir /opt/log && mkdir /opt/log/nginx run chown -r www-data.www-data /opt/htdocs /opt/log
volume ["/opt"]
由于官方的nginx1.9是基于debian jessie的，因此首先将准备好的配置文件复制到指定位置，替换镜像内的配置，这里按照个人习惯，约定/opt/htdocs目录为web服务器根目录，/opt/log/nginx目录为nginx的log目录。
同样构建一下镜像
docker build -t eva/nginx ./nginx
并运行容器
docker run -p 80:80 -v ~/opt:/opt -it eva/nginx
注意我们将本地的80端口绑定到容器的80端口，并将本地的~/opt目录挂载到容器的/opt目录，这样就可以将项目源代码放在~/opt目录下并通过容器访问了。
php容器
php容器是最复杂的一个，因为在实际项目中，我们很可能需要单独安装一些php扩展，并用到一些命令行工具，这里我们以redis扩展以及composer来举例。首先将项目需要的扩展等文件提前下载到php目录下，这样构建时就可以从本地复制而无需每次通过网络下载，大大加快镜像构建的速度：
wget https://getcomposer.org/composer.phar -o php/composer.phar wget https://pecl.php.net/get/redis-2.2.7.tgz -o php/redis.tgz
php目录下还准备好了php配置文件php.ini以及php-fpm.conf，基础镜像我们选择的是php 5.6-fpm，这同样是一个debian jessie镜像。官方比较亲切的在镜像内部准备了一个docker-php-ext-install指令，可以快速安装如gd、pdo等常用扩展。所有支持的扩展名称可以通过在容器内运行docker-php-ext-install获得。
来看一下dockerfile
from php:5.6-fpm add php.ini /usr/local/etc/php/php.ini add php-fpm.conf /usr/local/etc/php-fpm.conf copy redis.tgz /home/redis.tgz run docker-php-ext-install gd \ && docker-php-ext-install pdo_mysql \ && pecl install /home/redis.tgz && echo "extension=redis.so" > /usr/local/etc/php/conf.d/redis.ini add composer.phar /usr/local/bin/composer run chmod 755 /usr/local/bin/composer workdir /opt run usermod -u 1000 www-data volume ["/opt"]
在构建过程中做了这样一些事情：
复制php和php-fpm配置文件到相应目录
复制redis扩展源代码到/home
通过docker-php-ext-install安装gd和pdo扩展
通过pecl安装redis扩展
复制composer到镜像作为全局指令
按照个人习惯，仍然设置/opt目录作为工作目录。
这里有一个细节，在复制tar包文件时，使用的docker指令是copy而不是add，这是由于add指令会自动解压tar文件。
现在终于可以构建+运行了：
docker build -t eva/php ./php docker run -p 9000:9000 -v ~/opt:/opt -it eva/php
在大多数情况下，nginx和php所读取的项目源代码都是同一份，因此这里同样挂载本地的~/opt目录，并且绑定9000端口。
php-cli的实现
php容器除了运行php-fpm外，还应该作为项目的php cli使用，这样才能保证php版本、扩展以及配置文件保持一致。
例如在容器内运行composer，可以通过下面的指令实现：
docker run -v $(pwd -p):/opt -it eva/php composer install --dev -vvv
这样在任意目录下运行这行指令，等于动态将当前目录挂载到容器的默认工作目录并运行，这也是php容器指定工作目录为/opt的原因。
同理还可以实现phpunit、npm、gulp等命令行工具在容器内运行。
redis容器
为了方便演示，redis仅仅作为缓存使用，没有持久化需求，因此dockerfile仅有一行
from redis:3.0
容器的连接
上面已经将原本在一个容器中运行的服务分拆到多个容器，每个容器只运行单一服务。这样一来容器之间需要能互相通信。docker容器间通讯的方法有两种，一种是像上文这样将容器端口绑定到一个本地端口，通过端口通讯。另一种则是通过docker提供的linking功能，在开发环境下，通过linking通信更加灵活，也能避免端口占用引起的一些问题，比如可以通过下面的方式将nginx和php链接起来：
docker run -p 9000:9000 -v ~/opt:/opt --name php -it eva/php docker run -p 80:80 -v ~/opt:/opt -it --link php:php eva/nginx
在一般的php项目中，nginx需要链接php，而php又需要链接mysql，redis等。为了让容器间互相链接更加容易管理，docker官方推荐使用docker-compose完成这些操作。
用一行指令完成安装
pip install -u docker-compose
然后在docker项目的根目录下准备一个docker-compose.yml文件，内容为：
nginx: build: ./nginx ports: - "80:80" links: - "php" volumes: - ~/opt:/opt php: build: ./php ports: - "9000:9000" links: - "mysql" - "redis" volumes: - ~/opt:/opt mysql: build: ./mysql ports: - "3306:3306" volumes: - ~/opt/data/mysql:/var/lib/mysql environment: mysql_root_password: 123456 redis: build: ./redis ports: - "6379:6379"
然后运行docker-compose up，就完成了所有的端口绑定、挂载、链接操作。
经过团队实践，原本大概需要1天时间的环境安装，切换到docker后只需要运行10余条指令，时间也大幅缩短到3小时以内（大部分时间是在等待下载），最重要的是docker所构建的环境都是100%一致的，不会有人为失误引起的问题。未来我们会进一步将docker应用到ci以及生产环境中。