使用docker作为可复用运行环境跑任意php web应用

对于前端领域的小伙伴,使用node去跑一个应用非常容易,简单一条命令就可以马上运行js脚本,然而对于其它语言(我这里仅指php)就没那么容易,虽然用php可以去执行php脚本,而且php7还提供了一个非常小型的服务器,但是我们大部分情况下,还是使用apache去作为web服务器来跑web应用。所以,有没有一种方法,向node那么简单,一条命令,就可以把自己的php网站跑起来?答案当然是可以,即利用docker这个神奇的魔术箱。

创建apache2+php镜像

在安装完docker,调整完镜像等等之后,我们打算创建一个container,这个container不包含任何php代码,只有运行环境,把任何php代码放进去都可以跑。

docker pull ubuntu:16.04docker run -it ubuntu:16.04 bash

我们基于ubuntu去搭建一个apache的web环境。ubuntu中,我们大部分采用apache2这个package,它和我们在centos里面的apache稍有不同,主要体现在它的配置文件更零散,但是更合理。下面默认你对apache2有所了解。

运行完上面两条命令之后,我们进入到一个新启用的container里面的bash,由于docker的ubuntu镜像是一个非常小的核心级系统,所以很多桌面版ubuntu有的软件它都没有。所以我们要在里面自己安装一些软件。下面是在container里面的操作

apt updateapt install apache2apt install phpapt install libapache2-mod-php php-mcrypt php-mysql

Ok了,我们的环境搭好了,本文结束。

……当然没有结束。web应用还没跑起来呢。通过上面几行命令,我们已经有一个正在运行的container,它具备apache2+php(现在默认是php7了,这可能和ubuntu的源配置相关,你可能得根据你的docker镜像的实际情况进行调整来安装对应的版本)。

下面,我们把这个container提交为一个镜像(先退出container,container的ID为container_id),以后我们所有行动都靠这个镜像来完成:

docker commit -m "create a apache2+php server" container_id apache2_php:0.0.1

这样我们基于刚才运行的container创建来一个image,这个image就是我们想要的。

运行一段代码

接下来,我们要尝试写一段php代码,然后通过这个image跑起一个web,可以在浏览器里面访问这个应用。下面就是我们的代码了:

<?php

phpinfo();

如此简单!吓死人!关键在于演示嘛。接下来,我们要用我们前面创建的docker镜像去运行这段脚本。我们把这段脚本保存在文件~/wwwroot/目录下,命名为index.php,接下来就是见证奇迹的时刻:

docker run -d -p 80:80 -v ~/wwwroot:/var/www/html --name my_first_app apache2_php:0.0.1 /usr/sbin/apache2ctl -D FOREGROUND

上面命令里面,标红的部分是让这个container可以在后台自动运行。这条命令为我们run了一个container,基于apache2_php:0.0.1这个镜像,端口映射是80:80,把当前主机的~/wwwroot目录映射为container内部虚机的/var/www/html目录,启动之后在container里面运行apache2ctl,也就是启动apache服务。

接下来在自己电脑上打开浏览器,输入localhost回车,当当当当!是不是看到页面了。

没错了,你可以修改wwwroot下面的文件,刷新浏览器,得到想要的内容。而由于image是可以分享的,所以别人也可以用你刚才创建的image,然后配上上面这条看上去好复杂的命令,在他的电脑上运行他自己的php代码。如果再配合shell编程和alias,不就可以创建一条超简单启动服务的命令了么,写php预览变得这么简单。

外联服务

上面安装的php-mysql什么意思?你又没安装mysql-server。没错,我是没在image里面安装mysql,但是我外面有mysql啊!!!目前我的mysql是阿里云的RDS,提供了公网url可以连接,所以我以后写博客,可以在自己的电脑上运行自己的博客代码,写完提交,数据被保存到RDS的数据库里,我跑去其它地方也可以。

这就给了我们更多的想象,从前我们写代码开网站,需要搭建开发环境,一整套搞下来眼睛都瞎了。如果你运气差,需要随时随地换电脑编程,那就哭吧。但现在不同了,有了docker,你只需第一步,把docker安装好,第二步把上面的image拉下来,第三步从你自己的git仓库把代码拉下来,第四步运行上面那句神奇的命令,然后就可以开始玩耍了。

就像mysql你需要云端支持一样,除了代码以外的其它资源你也需要云端支持。这种开发模式在前端随处可见,我找不到好词,姑且称这种云端支持叫外联服务好了。对于开发php而言,我们只需要知道外联服务的基础接口,在我们的全局配置文件里面写好接口信息,通过sdk实现外联资源的操作。比如使用oss存储文件,使用session外联服务,日志、监控等等。这些与代码本身无关的资源,要占用磁盘存储空间的,统统丢给第三方外联服务。一旦做到这样,你的web应用就变得可独立测试了,外联服务全部可以通过mock在测试被支持。

但凡不依赖本地的存储,你的代码就可以直接打包进container,通过image来控制应用版本。同样的道理,其实外联服务也是可以用docker来封装。一旦一个应用的所有部分都是docker启动起来的,那么整个应用的版本控制也变得异常简单。对于应用上线而言变得极为轻松,直接将测试好的image发布到正式服务器上,通过脚本的方式运行起来,产品就上线来。

第一个深坑:宿主机共享目录的写入权限

上面那条神奇的命令行里面我们使用了-v参数把宿主机,也就是自己的电脑,上的一个目录挂载映射为container内虚机的一个目录,因此,当container运行时,container内的程序可以读取到实际为宿主机的文件。但是当你在php代码里面使用file_put_contents时,会发现,并没有写入权限。这就比较尴尬了!这也是为什么我提出“外联服务”的原因,图片上传不要保存到container内在系统里,而是通过一个图片服务的api把图片或其它文件资源上传到oss这样的服务去。

但是作为wordpress党,这很不实际啊,就是要保存在本地怎么办?

我们要简单分析一下为什么apache不能帮你把文件写入。php本身仅执行写入操作,而调用php的“人”是什么角色,拥有什么权限,决定了能不能在对应的目录里面创建文件。apache2通过libapache2-mod-php这个模块调用php执行php脚本,所以apache2的执行者同时也是php的执行者。按上面的安装方式安装的时候,apache2的执行者是www-data这个用户。因此,你通过-v参数挂载的目录,在container里面,是否对www-data用户和所在组有开放写入权限,决定了图片上传能否成功。很不幸,没有!

因为docker在使用-v挂载映射一个目录到container内时,被挂载的目录仍然属于宿主机内对应的那位用户。这个可能有点难理解。在我的电脑上,该目录在宿主机内的所属是uid=1000,gid=1000,当container起来的时候,这个指向完全不会改变,即使container内根本不存在uid=1000的用户,所以你登录container内去看的时候,发现这个目录的所有者和组不是一个名称,而是数字1000。由于不在同一个组里(其实这个组根本不存在于container内),www-data当然没有权利在这个目录里面胡作非为。既然如此,那就提权咯。把apache的执行者改为root……明确告诉你,该方案行不通,试过了,apache无法启动。把挂载的目录重新通过chown把权限下放给www-data。恩,看上去ok,问题是,这个操作要放在什么地方?必须你通过docker exec进入正在运行的container内部,执行这个操作才行。这就违背了“见证奇迹的时刻”这个idea。

解决的方案是,在启动container之前,修改宿主机目录的所属用户和组。我查看过container内www-data的uid和gid,都是33,所以,我在我的电脑上,首先要创建一个uid,gid都是33的用户。很凑巧,已经有了,也叫www-data,因为我用的也是ubuntu……于是把要挂载的目录修改所属:

sudo chown -R www-data:www-data ~/wwwroot

再运行上面那段“神奇的命令”,于是,可以写入文件了,上传一张图片试试,再进入到对应的图片保存目录,是不是可以看到被上传的图片了。

总结

这篇文章是我是实操,因此不是什么知识点,只是实操的分享。简单的说,docker给了我们写代码的另外一种可能,就是环境和逻辑代码完全分离。比如说前端,现在要做一个build还需要自己各种npm install,然后再用一个构建工具去build,如果操作系统不同,构建工具的编译可能还会出问题。而如果用docker封装构建工具,对于前端developer而言,它们只需要写和业务逻辑相关的代码,而不需要写构建相关的代码,不安装构建相关的package,而是用一个docker容器来进行构建,岂不是美哉!

2017-12-29 | ,