传统部署的坑：
1202 年了，如果你连 Docker 都不知道是什么，我建议买一本书看看——或者谷歌一下，博客已经写烂了。
为什么有这篇文章，是因为我在真正做容器化改造的时候，发现公司生产环境存在大量的坑：
- 传统虚拟机部署，基本依赖克隆或者手工编译。由于人力原因，SRE 历来单传，编译出来的 PHP、扩展等二进制版本不一致；
- 项目开发人员痛苦不堪——他没办法模拟出接近于线上一致的环境（碰不到摸不着，各种扩展版本都要自己去编译）；
- 新人入职都会灵魂拷问你一句——我怎么把线上的代码跑起来？
- ……
用什么 Linux 发行版？
Ubuntu 应该是全球用户量最多的发行版了，嗯我说的是桌面这一块，折腾过的人都知道，出问题的时候开机会有 “检测到系统错误” 的提示，另外，网上提供的配置或者各种疑难杂症，改了不一定能生效，而且你还不确定改了会不会影响到别的，反正我是不敢用的哈哈（Manjaro 真香）。
CentOS 应该是大家最熟悉的，也是我见过最多应用在生产环境中的。它给我的感觉就是非常稳定，并且网上的资料是一搜索就展现在你面前，而你对着资料改配置，重载就生效，不会搞出什么问题。
公司的生产环境清一色 CentOS 6，但 CentOS 6 已经被官方弃用，不再提供 yum 镜像源，这也意味着很多包你都安装不了，所以你只能升级到 CentOS 7。
问题来了，我能升级吗？
这不得不说到之前线上出现过一个故障：
公司有一台发布构建机器，用来做代码部署，机器上安装了 NodeJS、Go 编译器等，有一天前端的同事说向 SRE 同学提了一个需求：
升级 NodeJS 到 v10 版本，因为以前的 v6 版本太旧了，SRE 同学也没多想，发现 CentOS 6 机器要升级 glibc 才行，于是运维的同事就升级 glibc 之后，升级了 NodeJS；
过了段时间有人部署某服务，该服务使用了 结巴分词 ，部署完发现线上挂了……
嗯，线上环境的 glibc 版本比较低，编译机的 glibc 版本高，部署过去不兼容直接就是启动不了，还好当时回滚的够快 🙂
直接用 7 也不是不可以，统一就 OK，但要命的是，发现有些祖传的 PHP 扩展，已经失传了，能兼容但是你怎么保证不出问题对不对？
经历万般挫折，最终使用的是 CentOS 6.9，好在腾讯云有 yum 源，东拼西凑了生产环境的 PHP 扩展之后，开发环境已经完美投入使用。
就是因为这些事情，前前后后花了两三周的时间都在折腾镜像。
小而美 VS 大而全：
CentOS 是真的大！我自己也使用 7 重新打了一个镜像，发现不管怎么清理各种缓存，最终的镜像大小都接近 1G！
虽然说也不是不能用，但我就是有洁癖呀。最后还是选择了 alpine ，把体积减少到 100M 以内。
到这里可能有人问：我们生产环境用的 alpine 也就 60M 左右，没有那么大吧？
之前看过这个项目 Laradock ，它的特点是定制化非常强，基本都是打开一些环境变量就可以构建出你所要的镜像；
但我更倾向于，牺牲一些磁盘空间，制作一个统一的环境。为了方便，线上没必要按照项目复制扩展，维护自己的 Dockerfile，统一都放进去就好了，维护起来也比较方便。
生产环境使用什么版本？
公司目前大量使用 PHP 5.4 和 PHP 7.2，扩展版本比较混乱；
没有直接使用 nginx，而是使用 openresty 1.11.2（主要是传统 IDC 部署缺乏云上 WAF ，需要自行做好限流和 IP 防刷）；
我提供的 Dockerfile 是 PHP 5.6 和 PHP 7.2 的最新版本，理论上可以直接升级；而 openresty 使用最新奇数版本，保证生产环境的稳定和安全。
一些细节~~(坑)~~：
记录一下为什么要花这么长的时间整这个镜像，个人觉得下面列举出来的，都是非常宝贵的经验：
镜像：
- 尽量合并 RUN 指令，减少镜像层数，从而缩小镜像体积；
apk：
- 官方的镜像非常慢，所以使用了阿里云的镜像加速；
- apk --no-cache 的使用，也可以缩小镜像体积，对于自己安装的扩展不要忘记 rm 掉没用的文件夹；
- composer 安装私有仓库依赖 git 命令，所以它需要被安装；
- git clone 私有仓库需要 ssh-key，我的实现方式是 base64 编码文件内容，再 echo 到对应的位置上去，这样的好处就是一个 Dockerfile 就可以到处走了，不需要额外的文件和 COPY 指令，既方便又减少层数！
- 通过 apk 安装下来的扩展，需要手工 cp 到 /usr/local/lib/php/extensions/no-debug-non-zts-20131226/ 目录下；
文件权限：
- 私钥的文件权限是 600，只有文件的拥有者具有读写权限，组里其他用户或者其他用户连读都不行，不这样做的话代码拉不下来（ssh 会报错），切记；
线上排障：
- bind-tools 的作用在于方便线上定位问题——有时候你不得不进去容器，发现没办法测试 DNS 解析，你会特别痛苦；
环境标准化：
- 统一应用目录 /www 和日志目录 /wwwlog；
文件权限：
- 用户和用户组的 id，此处是 500（CentOS 6），CentOS 7 是 1000——如果你使用 NFS 共享文件系统，需要统一 www 的 uid，不然文件权限问题会令你抓狂；
- 公司使用 www 用户，官方提供的 fpm 镜像自带 www-data 用户，我代码重度洁癖，所以就把它删了；
- 定时任务建议使用 www 用户运行，原因是日志目录有可能是被运维的同事挂在到宿主机采集（一台宿主机一个 filebeat 进程，节省资源），而你使用 root 用户创建的某些文件夹，其他人可能写不进去，但还是留了后手——给 root 设置密码，遇到问题说不定可以 su 解决；
扩展：
- 公司重度使用 RabbitMQ 消息队列组件，所以安装了 amqp 扩展，rabbitmq-c-dev 等基础包必须加上，不然没办法编译通过；
- redis、bcmath、gettext、pdo_mysql、mysqli、mbstring、gd、zip、opcache 这几个扩展几乎都是必装的，其他的像 yaf、sysvmsg 等不需要的，大家可以自行删除；
php-fpm.conf：
- 非常驻模式启动，容器才不会刚启动就退出了；
- 修改子进程数量，还有超时等配置，这部分与线上环境是一致的；
php.ini：
- 打开 cli 模式的 opcache 扩展，加速 PHP 的运行，主要是一些定时任务；
- 关闭 PHP 的版本输出，这样别人访问我的网站就不知道我使用哪个 PHP 版本了，安全无小事！
适用于生产环境的 PHP 5 Dockerfile：
FROM php:5.6.40-fpm-alpine3.8
LABEL maintainer="???
