berlingskemedia/docker.php

PHP7.4 Docker镜像

镜像概述和主要用途

该Docker镜像用于运行PHP7.4环境，支持php-fpm和php cli两种模式。默认情况下启动php-fpm并监听9000端口，适用于Web服务；同时也可作为消费者/worker运行，处理后台任务。

核心功能和特性

• 支持php-fpm和php cli两种运行模式
• 默认启动php-fpm，监听9000端口
• 可运行消费者/worker进程，需在独立容器中启动且保持前台运行（不后台化）

使用场景和适用范围

• Web服务：通过php-fpm处理HTTP请求
• 后台任务：运行消费者/worker处理队列任务（如SQS消息消费）

使用方法和配置说明

默认启动php-fpm

无需额外配置，默认启动php-fpm并监听9000端口：

bash
docker run -d berlingskemedia/docker.php

运行消费者/worker

如需运行消费者/worker，需指定php cli命令，示例：

bash
docker run --restart=always -d berlingskemedia/docker.php php bin/console sqs:multiple-consumer --env=prod -q <consumername>

注意：每个worker/消费者必须在独立容器中运行，且进程必须保持前台运行（即不应后台化）。

可变Git标签

当前情况

由于生产环境部署由Puppet处理，所有Docker镜像名称在Puppet仓库中硬编码。若仅使用不可变Git标签，每次变更都需创建新镜像标签，进而需要更新Puppet代码，这将导致每次发布都需DevOps（CO）团队参与。通过Git分支模拟“可变标签”，可避免DevOps团队参与每次发布。

未来计划

我们认为Git标签是理想方案，但目前无法实现——需先替换Puppet为其他解决方案，之后将调整工作流并更新本文档。

工作流

由于当前无法使用不可变Git标签进行部署，必须使用分支名称进行版本控制。Dockerhub构建使用的分支包括：

• testing
• staging
• production

当这些分支中有新代码时，Webhook会触发Dockerhub（https://hub.docker.com/repository/docker/berlingskemedia/docker.php/builds%EF%BC%89%E7%9A%84%E6%96%B0%E6%9E%84%E5%BB%BA%EF%BC%8C%E7%94%9F%E6%88%90%E5%AF%B9%E5%BA%94%E5%88%86%E6%94%AF%E5%90%8D%E7%A7%B0%E7%9A%84%E9%95%9C%E5%83%8F%E6%A0%87%E7%AD%BE%EF%BC%9A

• berlingskemedia/docker.php:testing：用于https://github.com/BerlingskeMedia/bm.env.symfony%E4%BB%93%E5%BA%93%E6%9E%84%E5%BB%BA%E5%BC%80%E5%8F%91%E5%92%8CQA%E7%8E%AF%E5%A2%83
• berlingskemedia/docker.php:staging：用于https://github.com/BerlingskeMedia/puppet%E4%BB%93%E5%BA%93%E6%9E%84%E5%BB%BA%E9%A2%84%E5%8F%91%E7%8E%AF%E5%A2%83
• berlingskemedia/docker.php:production：用于https://github.com/BerlingskeMedia/puppet%E4%BB%93%E5%BA%93%E6%9E%84%E5%BB%BA%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83

注意：这些标签是可变的，即新版本会覆盖旧版本。

发布流程

1. 提交新Pull Request时，指定master为父分支。
2. PR合并到master后，删除现有testing分支并重新创建同名分支，以触发Dockerhub上berlingskemedia/docker.php:testing的构建。
3. 新镜像在QA环境测试通过后，部署到预发和生产环境：
   • 从master分支创建Git标签，命名格式为release-${YYYYmmddHHii}（表示日期和时间），并推送到远程，例如：git tag release-202109251330，然后git push origin release-202109251330。这将触发Dockerhub构建，便于未来回滚。
   • 删除现有staging和production分支，从master重新创建同名分支，以触发Dockerhub上staging和production镜像标签的构建。
   • 通过ssh登录预发实例，运行docker pull berlingskemedia/docker.php:staging，然后sudo reboot。
   • 验证预发环境正常后，对生产环境执行相同步骤（使用:production标签）。

回滚场景

若新镜像在生产环境出现问题，按以下步骤回滚：

1. 获取之前的版本镜像，标签格式为release-${YYYYmmddHHii}，例如release-202109011045。
2. 为该版本打production标签：docker tag berlingskemedia/docker.php:release-202109011045 berlingskemedia/docker.php:production。
3. 登录Dockerhub：docker login，输入凭据。
4. 推送新的生产标签到Dockerhub：docker push berlingskemedia/docker.php:production。
5. 按照新镜像部署步骤执行部署。

注意：若预发环境出现问题，操作相同，只需使用:staging标签。

为何删除并重新创建分支而非合并master到分支？

为保持构建Docker镜像时使用的提交哈希一致，相同的哈希可加快构建过程。

错误部署风险

注意：当QA环境有新版本但尚未部署到预发和生产时，存在错误部署风险。这是因为应用包在QA服务器构建，若使用一个镜像构建的包在另一个不同的PHP镜像上运行，可能导致意外副作用。因此，在QA测试新镜像时，应进行代码冻结，或在代码冻结期间（或周五）进行测试。