Docker 在 PHP 项目开发环境中的应用

环境部署是所有团队都必须面对的问题,随着系统越来越大,依赖的服务也越来越多,比如我们目前的一个项目就会用到:

  • Web服务器:Nginx
  • Web程序:PHP + Node
  • 数据库:MySQL
  • 搜索引擎:ElasticSearch
  • 队列服务:Gearman
  • 缓存服务:Redis + Memcache
  • 前端构建工具:npm + bower + gulp
  • PHP CLI工具:Composer + PHPUnit

因此团队的开发环境部署随之暴露出若干问题:

  1. 依赖服务很多,本地搭建一套环境成本越来越高,初级人员很难解决环境部署中的一些问题
  2. 服务的版本差异及OS的差异都可能导致线上环境BUG
  3. 项目引入新的服务时所有人的环境需要重新配置

对于问题1,可以用Vagrant这样的基于虚拟机的项目来解决,团队成员共享一套开发环境镜像。对于问题2,可以引入类似PHPBrew这样的多版本PHP管理工具来解决。但两者都不能很好地解决问题3,因为虚拟机镜像没有版本管理的概念,当多人维护一个镜像时,很容易出现配置遗漏或者冲突,一个很大的镜像传输起来也不方便。

Docker的出现让上面的问题有了更好的解决方案,虽然个人对于Docker大规模应用到生产环境还持谨慎态度,但如果仅仅考虑测试及开发,私以为Docker的容器化理念已经是能真正解决环境部署问题的银弹了。

下面介绍Docker构建PHP项目开发环境过程中的演进,本文中假设你的操作系统为Linux,已经安装了Docker,并且已经了解Docker是什么,以及Docker命令行的基础使用,如果没有这些背景知识建议先自行了解。

Hello World

首先还是从一个PHP在Docker容器下的Hello World实例开始。我们准备这样一个PHP文件index.php


  1. <?php
  2. echo "PHP in Docker";

然后在同目录下创建文本文件并命名为Dockerfile,内容为:


  1. # 从官方PHP镜像构建
  2. FROM php
  3. # 将index.php复制到容器内的/var/www目录下
  4. ADD index.php /var/www
  5. # 对外暴露8080端口
  6. EXPOSE 8080
  7. # 设置容器默认工作目录为/var/www
  8. WORKDIR /var/www
  9. # 容器运行后默认执行的指令
  10. ENTRYPOINT ["php", "-S", "0.0.0.0:8080"]

构建这个容器:


  1. docker build -t allovince/php-helloworld .

运行这个容器


  1. docker run -d -p 8080:8080 allovince/php-helloworld

查看结果:


  1. curl localhost:8080
  2. PHP in Docker

这样我们就创建了一个用于演示PHP程序的Docker容器,任何安装过Docker的机器都可以运行这个容器获得同样的结果。而任何有上面的php文件和Dockerfile的人都可以构建出相同的容器,从而完全消除了不同环境,不同版本可能引起的各种问题。

想象一下程序进一步复杂,我们应该如何扩展呢,很直接的想法是继续在容器内安装其他用到的服务,并将所有服务运行起来,那么我们的Dockerfile很可能发展成这个样子:


  1. FROM php
  2. ADD index.php /var/www
  3. # 安装更多服务
  4. RUN apt-get install -y \
  5. mysql-server \
  6. nginx \
  7. php5-fpm \
  8. php5-mysql
  9. # 编写一个启动脚本启动所有服务
  10. 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镜像


  1. FROM ubuntu:14.04
  2. RUN apt-get update -y && apt-get install -y nginx

  1. FROM ubuntu:14.04
  2. RUN apt-get update -y && apt-get install -y mysql

这种方式的优点在于所有服务可以有一个统一的基础镜像,对镜像进行扩展和修改时可以使用同样的方式,比如选择了ubuntu,就可以使用apt-get指令安装服务。

问题在于大量的服务需要自己维护,特别是有时候需要某个服务的不同版本时,往往需要直接编译源码,调试维护成本都很高。

选项二、 直接从Docker Hub继承官方镜像,下面同样是Nginx和MySQL镜像


  1. FROM nginx:1.9.0

  1. FROM mysql:5.6

Docker Hub可以看做是Docker的Github,Docker官方已经准备好了大量常用服务的镜像,同时也有非常多第三方提交的镜像。甚至可以基于Docker-Registry项目在短时间内自己搭建一个私有的Docker Hub。

基于某个服务的官方镜像去构建镜像,有非常丰富的选择,并且可以以很小的代价切换服务的版本。这种方式的问题在于官方镜像的构建方式多种多样,进行扩展时需要先了解原镜像的Dockerfile

出于让服务搭建更灵活的考虑,我们选择后者构建镜像。

为了分拆服务,现在我们的目录变为如下所示结构:


  1. ~/Dockerfiles
  2. ├── mysql
  3. │ └── Dockerfile
  4. ├── nginx
  5. │ ├── Dockerfile
  6. │ ├── nginx.conf
  7. │ └── sites-enabled
  8. │ ├── default.conf
  9. │ └── evaengine.conf
  10. ├── php
  11. │ ├── Dockerfile
  12. │ ├── composer.phar
  13. │ ├── php-fpm.conf
  14. │ ├── php.ini
  15. │ ├── redis.tgz
  16. └── redis
  17. └── Dockerfile

即为每个服务创建单独文件夹,并在每个服务文件夹下放一个Dockerfile。

MySQL容器

MySQL继承自官方的MySQL5.6镜像,Dockerfile仅有一行,无需做任何额外处理,因为普通需求官方都已经在镜像中实现了,因此Dockerfile的内容为:


  1. FROM mysql:5.6

在项目根目录下运行


  1. docker build -t eva/mysql ./mysql

会自动下载并构建镜像,这里我们将其命名为eva/mysql

由于容器运行结束时会丢弃所有数据库数据,为了不用每次都要导入数据,我们将采用挂载的方式持久化MySQL数据库,官方镜像默认将数据库存放在/var/lib/mysql,同时要求容器运行时必须通过环境变量设置一个管理员密码,因此可以使用以下指令运行容器:


  1. 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内容为:


  1. FROM nginx:1.9
  2. ADD nginx.conf /etc/nginx/nginx.conf
  3. ADD sites-enabled/* /etc/nginx/conf.d/
  4. RUN mkdir /opt/htdocs && mkdir /opt/log && mkdir /opt/log/nginx
  5. RUN chown -R www-data.www-data /opt/htdocs /opt/log
  6. VOLUME ["/opt"]

由于官方的Nginx1.9是基于Debian Jessie的,因此首先将准备好的配置文件复制到指定位置,替换镜像内的配置,这里按照个人习惯,约定/opt/htdocs目录为Web服务器根目录,/opt/log/nginx目录为Nginx的Log目录。

同样构建一下镜像


  1. docker build -t eva/nginx ./nginx

并运行容器


  1. docker run -p 80:80 -v ~/opt:/opt -it eva/nginx

注意我们将本地的80端口绑定到容器的80端口,并将本地的~/opt目录挂载到容器的/opt目录,这样就可以将项目源代码放在~/opt目录下并通过容器访问了。

PHP容器

PHP容器是最复杂的一个,因为在实际项目中,我们很可能需要单独安装一些PHP扩展,并用到一些命令行工具,这里我们以Redis扩展以及Composer来举例。首先将项目需要的扩展等文件提前下载到php目录下,这样构建时就可以从本地复制而无需每次通过网络下载,大大加快镜像构建的速度:


  1. wget https://getcomposer.org/composer.phar -O php/composer.phar
  2. 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


  1. FROM php:5.6-fpm
  2. ADD php.ini /usr/local/etc/php/php.ini
  3. ADD php-fpm.conf /usr/local/etc/php-fpm.conf
  4. COPY redis.tgz /home/redis.tgz
  5. RUN docker-php-ext-install gd \
  6. && docker-php-ext-install pdo_mysql \
  7. && pecl install /home/redis.tgz && echo "extension=redis.so" > /usr/local/etc/php/conf.d/redis.ini
  8. ADD composer.phar /usr/local/bin/composer
  9. RUN chmod 755 /usr/local/bin/composer
  10. WORKDIR /opt
  11. RUN usermod -u 1000 www-data
  12. VOLUME ["/opt"]

在构建过程中做了这样一些事情:

  1. 复制php和php-fpm配置文件到相应目录
  2. 复制redis扩展源代码到/home
  3. 通过docker-php-ext-install安装GD和PDO扩展
  4. 通过pecl安装Redis扩展
  5. 复制composer到镜像作为全局指令

按照个人习惯,仍然设置/opt目录作为工作目录。

这里有一个细节,在复制tar包文件时,使用的Docker指令是COPY而不是ADD,这是由于ADD指令会自动解压tar文件

现在终于可以构建+运行了:


  1. docker build -t eva/php ./php
  2. docker run -p 9000:9000 -v ~/opt:/opt -it eva/php

在大多数情况下,Nginx和PHP所读取的项目源代码都是同一份,因此这里同样挂载本地的~/opt目录,并且绑定9000端口。

PHP-CLI的实现

php容器除了运行php-fpm外,还应该作为项目的php cli使用,这样才能保证php版本、扩展以及配置文件保持一致。

例如在容器内运行Composer,可以通过下面的指令实现:


  1. docker run -v $(pwd -P):/opt -it eva/php composer install --dev -vvv

这样在任意目录下运行这行指令,等于动态将当前目录挂载到容器的默认工作目录并运行,这也是PHP容器指定工作目录为/opt的原因。

同理还可以实现phpunit、npm、gulp等命令行工具在容器内运行。

Redis容器

为了方便演示,Redis仅仅作为缓存使用,没有持久化需求,因此Dockerfile仅有一行


  1. FROM redis:3.0

容器的连接

上面已经将原本在一个容器中运行的服务分拆到多个容器,每个容器只运行单一服务。这样一来容器之间需要能互相通信。Docker容器间通讯的方法有两种,一种是像上文这样将容器端口绑定到一个本地端口,通过端口通讯。另一种则是通过Docker提供的Linking功能,在开发环境下,通过Linking通信更加灵活,也能避免端口占用引起的一些问题,比如可以通过下面的方式将Nginx和PHP链接起来:


  1. docker run -p 9000:9000 -v ~/opt:/opt --name php -it eva/php
  2. docker run -p 80:80 -v ~/opt:/opt -it --link php:php eva/nginx

在一般的PHP项目中,Nginx需要链接PHP,而PHP又需要链接MySQL,Redis等。为了让容器间互相链接更加容易管理,Docker官方推荐使用Docker-Compose完成这些操作。

用一行指令完成安装


  1. pip install -U docker-compose

然后在Docker项目的根目录下准备一个docker-compose.yml文件,内容为:


  1. nginx:
  2. build: ./nginx
  3. ports:
  4. - "80:80"
  5. links:
  6. - "php"
  7. volumes:
  8. - ~/opt:/opt
  9. php:
  10. build: ./php
  11. ports:
  12. - "9000:9000"
  13. links:
  14. - "mysql"
  15. - "redis"
  16. volumes:
  17. - ~/opt:/opt
  18. mysql:
  19. build: ./mysql
  20. ports:
  21. - "3306:3306"
  22. volumes:
  23. - ~/opt/data/mysql:/var/lib/mysql
  24. environment:
  25. MYSQL_ROOT_PASSWORD: 123456
  26. redis:
  27. build: ./redis
  28. ports:
  29. - "6379:6379"

然后运行docker-compose up,就完成了所有的端口绑定、挂载、链接操作。

更复杂的实例

上面是一个标准PHP项目在Docker环境下的演进过程,实际项目中一般会集成更多更复杂的服务,但上述基本步骤仍然可以通用。比如EvaEngine/Dockerfiles是为了运行我的开源项目EvaEngine准备的基于Docker的开发环境,EvaEngine依赖了队列服务Gearman,缓存服务Memcache、Redis,前端构建工具Gulp、Bower,后端Cli工具Composer、PHPUnit等。具体实现方式可以自行阅读代码。

经过团队实践,原本大概需要1天时间的环境安装,切换到Docker后只需要运行10余条指令,时间也大幅缩短到3小时以内(大部分时间是在等待下载),最重要的是Docker所构建的环境都是100%一致的,不会有人为失误引起的问题。未来我们会进一步将Docker应用到CI以及生产环境中。

原文发布时间为:2015-07-01


本文来自合作伙伴“Linux中国”

时间: 2024-09-01 12:07:57

Docker 在 PHP 项目开发环境中的应用的相关文章

IFTTT在开发环境中使用Docker的经验

本文讲的是IFTTT在开发环境中使用Docker的经验,[编者的话]IFTTT是"if this then that"的缩写,事实上是让你的网络行为能够引发连锁反应.让你使用更为方便,其宗旨是"Put the internet to work for you"(让互联网为你服务).Docker在IFTTT中也在开发实践,以下是Nicholas Silva的一些介绍. IFTTT是一款新兴的互联网工具型应用,正如他们给自己的介绍"If This Then T

用 Docker 快速配置前端开发环境

本文讲的是用 Docker 快速配置前端开发环境[编者的话]最近在公司实践了一下 Docker,记录成了一篇文章,发出来和大家交流下.我基本上是个 Docker 新手,如果有什么地方说得不对请大家指出~目前的方案还比较粗糙,大家有什么改进建议也请告诉我,我多和大家学习 今天是你入职第一天. 你起了个大早,洗漱干净带着材料去入职. 签了合同,领了机器,坐到工位,泡一杯袋装红茶,按下开机键,输入密码, 然后,下载 Chrome.Postman.Sublime.盗版 PS.NodeJS.配置 NODE

克服云计算开发环境中的容器难题

如今,企业寻求超越虚拟化,甚至许多企业在寻找一个理想的公共云应用策略,而容器都人气暴涨.因为容器比虚拟机的开销更低,往往是更快.更容易部署,而且通常让企业的每个服务器上运行更多的应用程序.容器似乎是完美的发展目标,但他们还存在安全性和法规遵从问题.另外,开发人员必须处理质量和可用性风险问题.而在探讨在云开发环境使用容器时,不能解除他们使用容器的这些痛点. 开发人员应查看容器中的多道程序.多用户分区,以及虚拟机之间的事情.所以他们必须管理容器隔离的应用程序的组件,了解容器管理工具,如Docker的

在VC++开发环境中整合Pro*C/C++

c++ 本文所讨论的内容基于以下环境:Microsoft Visual C++ 6.0ORACLE 8i (8.1.7) 当前版本:1.0 (041221) 声明:本文所述的某些操作可能对系统产生重大影响,请慎重操作!本人不对此产生的任何后果负责! 在VC++开发环境中整合Pro*C/C++Pro*C/C++为C/C++语言访问ORACLE数据库提供了极大的方便,但是,在编译的时候往往需要在命名行模式下编译pc文件,而目前多数开发都是在VC++这种整合开发环境中完成的,要在两者之间不停的切换,不

在团队开发环境中使用 Visual Studio .NET (二)

脱机时签入文件 不可能在脱机时签入文件:因为您未连接到网络,签入命令未启用.这是故意设置的,这样可以在项目重新联机时方便地查看哪些文件在脱机时被签出. 进入联机状态 这与进入脱机状态基本上相同.若要使解决方案及其项目联机,请在"File"菜单上,单击"Source Control",然后单击"Change Source Control...".显示的对话框与进入脱机状态时相同.选择"Connected"即可使解决方案和项目联机

让你提前认识软件开发(51):VC++集成开发环境中Linux下Pclint工程的配置方法及常见错误修改

第3部分 软件研发工作总结 VC++集成开发环境中Linux下Pclint工程的配置方法及常见错误修改   [文章摘要]         Pclint是一种C/C++软件代码静态分析工具.它是一种更加严格的编译器,能够发现普通编译器所不能发现的代码中的很多问题,因此被广泛应用于软件开发项目中.        本文介绍了如何在VC++集成开发环境中配置Linux下的Pclint工程,给出了C语言中pclint规则A检查的常见错误,并描述了对应的修改办法.   [关键词]          VC++

Linux集群和自动化维3.7.1 开发环境中的Fabric应用实例

3.7 Fabric应用实例 3.7.1 开发环境中的Fabric应用实例 笔者公司在开发环境下使用的都是Xen和KVM虚拟机器,有不少数据,因为是内网环境,所以直接用root和SSH密码连接.系统统一为CentOS 6.4 x86_64,内核版本为2.6.32-358.el6.x86_64,Python版本为2.6.6. 实例1,同步Fabric跳板机的/etc/hosts文件,脚本如下: #!/usr/bin/python # -*- coding: utf-8 -*- from fabri

Docker 实现在线集成开发环境实例详解_docker

Docker 实现在线集成开发环境 由于,学校有流量限制,每月10G,超流量后限速为50KB/s,作为一个正常人类,这点流量肯定是不够用的,所以我 需要一个几乎没有流量.网速限制的开发环境. 虽然ssh连接服务器,在服务器终端下开发几乎不限速.不限流,但是开发全靠vim显然有些"不亲民",大部分人对命令行界面并不熟悉. 终端下的开发环境搭建起来也是颇为麻烦,所以本文将用 三步 教你打造一个界面美观.功能强大的.菜鸟都可以轻松搭建的 在线集成开发环境 . 目标: 一键部署,一句命令完成在

如何在rails开发环境中取得上下文路径

问题描述 如何在rails开发环境中取得上下文路径下面是C#的写法string contextPath = Request.ApplicationPath;求教谢谢!先 解决方案 使用RAILS_ROOT常量解决方案二:查看一下environment.rb就知道了