laravel后端项目的Docker镜像打包

对读者的要求

• 后端开发基础知识
• 掌握Docker基础用法以及docker-compose用法(有laradock使用经验为佳)
• Laravel基础

简介

在第一篇文章《纯前端项目的Docker镜像打包》中，提到后端项目的镜像打包方面比较复杂，需要独立一篇。我们的目标仍然是执行一条命令就要能完成应用的启动。纯前端项目使用的是docker run，后端项目需要用到镜像编排(docker-comopse)，启动命令变成：

docker-compose up -d --renew-anon-volumes

docker-compose使用最新版本，否则--renew-anon-volumes参数可能不支持

docker-compose的内部结构如下图的“应用”部分所示，里面编排了4个任务；而后端需要的数据库、缓存、队列、对象存储以及安全配置则由外部提供，docker-compose不关心它们的来源：

下面我们一步步了解，为什么会形成这样的图，以及怎么打包以满足图中所示的架构。

概念

在谈论后端的镜像打包和镜像测试之前，首先要认识到Docker要用得好，需要满足两大特征：

1. 无状态
2. 单一职责

无状态是指容器不会保存任何东西，不论往容器里面写入任何东西，再次执行docker-compose up -d，启动后的容器是找不到原来写入的东西的。有些场景如果需要保存数据，比如数据库和存储，它们需要通过挂载保证写入的数据不因为重启而丢失，这类容器称为有状态容器。

要保证应用的水平扩展和快速迁移，所有的应用在启动时必须是无状态的。试想一下，你的应用原本在A机器上执行一句docker-comopse up -d就行了，现在要改到B机器上运行，就在B机器上执行一句docker-compose up -d。
如果它是有状态的（比如A在启动应用的时候，将存储挂载到主机，以便用户上传的图片和应用产生的日志可以永久保留），那么迁移到B机器时，它的日志和图片仍然在A机器上，快速迁移受到了限制。
另一个更常见的场景是，A，B两台机器同时启动以便负载均衡，如果A和B是有状态的，就会出现跟迁移一样的问题，A和B都会遗漏用户上传的图片，这就限制了水平扩展。因此，应用必须是无状态的。

单一职责简单说就是只干一件事，反映到Docker上，就是最好只启动一个进程（取决于对职责的解释，也可能启动多个进程）。比如php-fpm镜像只启动php-fpm，nginx镜像只启动nginx。要做到将nginx，php-fpm都在同一个里容器里启动当然是可以的，但是它带来的代价往往比比好处更大。越多不同职责的功能塞到同一个容器里，代价就越大。
以Laravel工程为例，有4个不同职责的进程：nginx，php-fpm，php队列，cron定时任务。混在一起以后，第一个问题是：任何一块有更新，都要重新打包这个镜像，而通常这个镜像里面的内容比较多，通常会很大；第二个问题是职责的混合导致它很难与已有的系统结合，典型的是我们只需要php-fpm，nginx由外部提供，如果打包到一起，nginx会产生干扰；另一个典型的场景是暂时不需要用到php队列和cron定时任务，它们也必须开着；第三个则是日志信息的混乱，nginx和php-fpm的日志混在一起无法有效地提取。

后端应用要满足这2个特征，就带来2个直接的问题：

• 后端访问的数据库、队列和存储放哪里？
• nginx、php-fpm、php队列、定时任务怎么编排？

所有后端应用的配置都是比较敏感，比如数据库密码，是不能打包到镜像中的，于是就有了第3个问题：

• 敏感信息怎么保护？

关键问题的分析

后端镜像的打包，重点在于思考清楚这3个问题。下面我们一个个问题的分析。

Q：后端要访问的数据库、缓存、队列和存储放哪里？
A：这三个需要与应用分开单独考虑，在生产环境下，一般使用一台独立的机器，或者直接使用云服务商提供的数据库、缓存等服务。这样不论应用迁移到哪里，都能使用同一份数据库、缓存和存储。

Q：nginx、php-fpm、php队列、php定时任务怎么编排？
A：单一职责在实践上是有争议的。如果是要求容器只启动一个进程的角度，将nginx、laravel php-fpm和laravel队列和laravel定时任务独立成4个任务，如果要检查nginx证书是否过期，还得有certbot，共5个任务。一个简单的后台应用要有5个任务，听起来头就很大。

另外一种对单一职责的解释则是从就应用的范围去解释。nginx和php-fpm管的东西八竿子打不着，所以肯定是独立的两个镜像容器。但是上面的nginx和certbot要合在一起，而laravel php-fpm和laravel 队列和laravel 定时任务也要合在一起，镜像编排时只启动2个容器。

这两种解释目前我们都接受，应用小的时候可以采用后一种方式，应用变大时要过度到第一种方式。

Q：敏感信息怎么保护？
A：通过环境变量的方式注入。云容器有提供配置环境变量的地方。如果自己启动docker-compose，环境变量可以通过直接读取独立的环境变量文件，或者从vault等管理密钥的平台读取。

解决这3个问题以后，最后形成的镜像结构就如“简介”中的图所示。

目录结构

脚本文件比较多，并不适合直接放到后端代码里面。要么将后端与脚本独立成2个项目，要么按如下调整项目的总体目录结构：

backend/
- Dockerfile 
- scripts/
    - start.sh
    - crontab
    - worker.conf
    - build.sh
    - push.sh
- ...其他Laravel文件直接忽略
scripts/
- nginx/ # nginx 镜像制作 
    - Dockerfile
    - app.conf
    - nginx.conf
    - build.sh
    - push.sh
- prod/ # 生产环境的镜像编排测试
    - docker-compose.yml
    - update.sh
    - app-backend.env # 不能放git仓库
- prod-local/ # 本地镜像编排测试
    - docker-compose.yml
    - update.sh
    - app-backend.env # 不能放git仓库

步骤

制作php-fpm镜像配置

先直接看Dockerfile，然后对这个文件做详细解释：

FROM pheye/php-fpm:latest

MAINTAINER LIUWENCAN <phenye@gmail.com>

# 将源码拷到镜像中
COPY . /var/www/backend
# 确保没有将.env打包进去
RUN if [ -e .env ] ; then rm .env; fi

# 启动脚本，除了php-fpm还有一些额外的配置
COPY scripts/start.sh /start.sh
RUN chmod +x /start.sh
# 用于任务调度的任务
COPY scripts/crontab /etc/cron.d/www
# 用于支持worker的启动
ADD ./scripts/worker.conf /etc/supervisor/conf.d/worker.conf

# 修改属主，确保与php-fpm的用户一致
RUN chown -R www /var/www/backend

VOLUME /var/www/backend

CMD ["/start.sh"]

关于这个文件，首先要了解php-fpm的基础镜像，官方有提供，不过php-fpm的许多扩展需要自己配置，很容易出现遗漏，性能调优也需要自己配置，cron和supervisord等用于支持任务调度和队列的包也需要自己安装，整个配置过程是非常繁琐的，因此这里我使用自己在生产环境验证过的php-fpm作为基础镜像，有做调整时就更新该包即可

其次是VOLUME /var/www/backend这一句，非常重要，它会开放一个匿名挂载供nginx使用，否则nginx容器里面将会是空的，没有任何应用源码。

最后是，Dockerfile中出现了start.sh，worker.conf、crontab这3个文件，下面要针对这3个文件做个详细解释。

start.sh是启动脚本，正常来讲，只需要启动php-fpm就能工作，但是默认情况没有考虑到迁移文件的需求，该脚本可以做更多必要的工作。

#!/bin/sh

# 用于启动性能采集
# nohup tideways-daemon &

# 执行migration
cd /var/www/backend
php artisan migrate --force
if [ ! -f "public/storage" ] ; then php artisan storage:link; fi

# 下面这2个被注释的命令有助于提高性能，但是可能导致应用不可用，根据需要自己启动
# php artisan optimize 
# php artisan api:cache 
if [ $? -eq 0 ] ; then
    # 启动php-fpm
    php-fpm
else
   exit 1
fi

worker.conf是supersivord的配置文件，用于确保php队列的可靠启动和对队列的进程数量做精确控制

[program:worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/backend/artisan queue:work --sleep=3 --tries=3 --daemon
user=www
autostart=true
autorestart=true
numprocs=2
stdout_logfile=/dev/fd/1
stdout_logfile_maxbytes=0
stderr_logfile=/dev/fd/2
stderr_logfile_maxbytes=0

crontab用于执行任务调度

* * * * * www php /var/www/backend/artisan schedule:run > /dev/null 2>&1

构建php-fpm镜像

docker build -t  app-backend:latest  .

制作nginx镜像配置

nginx的制作与《培训-纯前端项目的Docker镜像打包》几乎一样， 这里就不再赘述。只简单提下不同的几个小点：

1. Dockerfile不需要添加任何应用的源码;
2. app.conf与前端不一样，完整代码见下面；
3. app.conf中的fastcgi_pass backend:9000;需要特别注意，backend是实际启动的php-fpm的容器名。

Dockerfile

FROM nginx:alpine

MAINTAINER LIUWENCAN <phenye@gmail.com>

RUN adduser -D -H -u 5000 -s /bin/sh www
RUN rm /etc/nginx/conf.d/default.conf
ADD nginx.conf /etc/nginx/
ADD backend.conf /etc/nginx/sites-available/

VOLUME /var/www

CMD ["nginx"]             

区别只在于app.conf的内容不一样：

server {
    listen 80;
    listen [::]:80;

    server_tokens off;
    server_name demo-app.store.codefriend.top;
    root /var/www/backend/public;
    index index.php index.html index.htm;

    location ~* .*.(gif|jpg|jpeg|png|bmp|swf|js|css)$ {
        expires      30d;
        add_header Cache-Control "public";
    }

    location / {
         try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ .php$ {
        internal;
        try_files $uri /index.php =404;
        fastcgi_pass app-backend:9000; # 这个名字需要注意
        fastcgi_index index.php;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /.ht {
        deny all;
    }

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt/;
        log_not_found off;
    }

}

构建nginx镜像

docker build -t  app-nginx:latest .

本地镜像编排

本地镜像编排docker-comopse.yml

version: '2'
services:
  backend:
    image: app-backend:latest
    env_file: "./app-backend.env"
  cron:
    image: app-backend:latest
    env_file: "./app-backend.env"
    command: ['cron', '-f']
  worker:
    image: app-backend:latest
    env_file: "./app-backend.env"
    command: ['/usr/bin/supervisord', '-n', '-c', '/etc/supervisor/supervisord.conf']
  nginx:
    image: app-nginx:latest
    volumes_from:
      - backend
    depends_on:
      - backend
    ports:
      - "8888:80"

镜像编排中有两个重点：

1. 出现了app-backend.env这个文件，这个文件就是Laravel的.env，这些敏感一般放在保密的对象存储上，或者通过云容器的环境配置、或者放在vault这样的密钥管理里面。
2. nginx的volumes_from来自backend，这一句非常重要，它确保nginx可以直接读取静态文件，没有这一句的话，nginx没有任何应用的文件，读取静态文件时将直接报错。

测试镜像

docker-compose up -d --renew-anon-volumes

--renew-anon-volumes这个参数用于更新匿名挂载，非常重要。因为nginx里面本身没源码，源码是跟着php-fpm，如果没有这个参数，当php-fpm那边的代码更新以后，nginx这边仍然是旧代码。

docker-compose ps看下各个任务是否正常启动，如果已经正常启动。直接访问http://localhost:8888应该能够正常进入。

如果不能正常进入，结合docker-compose log，docker-compose top以及通过docker-compose exec进到容器内部排查。

进阶配置1-版本控制

前面制作的镜像，版本都是latest，这种玩法在生产环境是有问题的，要是制作的镜像不能用，一启动起来就是人间惨剧。因此制作的镜像都需要指定版本（一般通过CI/CD自动生成），布署出问题的时候就回滚。下面是怎么方便指定版本的脚本

php-fpm构建支持指定版本的生产镜像

php-fpm部分，增加backend/scripts/build.sh：

#!/bin/sh

if [ $# -gt 1 ] ; then
    docker build -t app-backend:$1 -t  app-backend:latest  .
else
    docker build -t  app-backend:latest  .
fi

要制作镜像时就进入backend目录，指定版本构建，如果不指定，就是latest版本:

./scripts/build.sh v1.0.0

nginx构建支持指定版本的生产镜像

nginx部分，与前面的类似，增加scripts/nginx/build.sh:

#!/bin/sh

if [ $# -gt 1 ] ; then
docker build -t app-nginx:$1 -t  app-nginx:latest  .
else
docker build -t  app-nginx:latest  .
fi

要制作镜像时就进入scripts/nginx目录，指定版本构建，如果不指定，就是latest版本:

./build.sh v1.0.0

进阶配置2-推送镜像与编排测试

本地构建的镜像在本地测试，只能说它没有问题。但是要实际使用，需要推送到公共的镜像仓库以供其他人获取。https://hub.docker.com/是官方提供的免费镜像仓库，放公开的镜像是极好的。

公司的应用，一般都要放在私有镜像仓库。私有镜像仓库，国内阿里云，国外AWS都有提供，自己要搭建的话，可以使用harbor。本文以阿里云作为例子，演示私有镜像仓库的推送和拉取。

php-fpm的推送镜像脚本

创建backend/scripts/push.sh:

#!/bin/bash

pwd=${ALIYUN_REGISTRY_PASSWORD}
docker login --username=phenye -p $pwd registry.cn-hangzhou.aliyuncs.com
docker tag app-backend:latest registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:latest
docker push registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:latest


if [ $# -gt 0 ] ; then
  tag=$1
  docker tag app-backend:latest registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:${tag}
  docker push registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:${tag}
fi

进入backend,推送指定版本，不指定则总是推成(latest):

./scripts/push.sh v1.0.0

nginx的推送镜像脚本

创建scripts/nginx/push.sh:

#!/bin/sh
pwd=${ALIYUN_REGISTRY_PASSWORD}
docker login --username=phenye -p $pwd registry.cn-hangzhou.aliyuncs.com
docker tag app-nginx:latest registry.cn-hangzhou.aliyuncs.com/phenye/app-nginx:latest
docker push registry.cn-hangzhou.aliyuncs.com/phenye/app-nginx:latest


if [ $# -gt 0 ] ; then
  tag=$1
  docker tag app-nginx:latest registry.cn-hangzhou.aliyuncs.com/phenye/app-nginx:${tag}
  docker push registry.cn-hangzhou.aliyuncs.com/phenye/app-nginx:${tag}
fi

进入scripts/nginx，推送指定脚本，不指定总是推送latest:

./push.sh v1.0.0

镜像编排测试

对推送的镜像做编排测试：

version: '2'
services:
  backend:
    image: registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:latest
    env_file: "./baas.env"
  cron:
    image: registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:latest
    env_file: "./baas.env"
    command: ['cron', '-f']
  worker:
    image: registry.cn-hangzhou.aliyuncs.com/phenye/app-backend:latest
    env_file: "./baas.env"
    command: ['/usr/bin/supervisord', '-n', '-c', '/etc/supervisor/supervisord.conf']
  nginx:
    image: registry.cn-hangzhou.aliyuncs.com/phenye/baas-nginx:latest
    volumes_from:
      - backend
    depends_on:
      - backend
    ports:
      - "8080:80"

docker-compose up -d --renew-anon-volumes

优化镜像编排的升级

前面的镜像编排都存在一个问题，都是使用latest版本，指定版本并不方便，因此创建update.sh脚本，方便快速升级：

#!/bin/bash

# ./update.sh <version>

if [ $# -gt 0 ] ; then
    hash=$1
else
    hash=latest
fi

echo "version: $hash"
sed -i.bak "/app-backend:/s/(app-backend:)([^"]*)/1${hash}/" docker-compose.yml
sed -i.bak "/app-nginx:/s/(app-nginx:)([^"]*)/1${hash}/" docker-compose.yml

docker-compose pull
# 暂不支持蓝绿布署
docker-compose up -d --renew-anon-volumes

要启动或者更换成某个版本(不指定版本就是latest)：

./udpate.sh v1.0.0

一般来说，通过蓝绿布署做到零秒停机的升级是必要的，但是我们这一节的目标主要是讲镜像打包，而不是讲布署；第二个我们的布署基本推荐在K8S或者云容器上，基于docker-compose的布署场景变得很少，没有专门写优化的脚本。

附录

Laravel自身的问题

本文谈的镜像打包的问题主要由Docker的特征导致，但是Laravel应用本身也有许多问题（其他语言的后台应用也有类似的问题）,会使镜像打包变得复杂：

• 升级版本时，数据库迁移怎么做？
• 日志放哪里？
• 性能数据的采集放哪里？

这些问题在这里抛出由读者思考，以后有机会我们专门讲讲，本文镜像打包对其中的一些问题做了处理。