使用 Laradock 将 PHP 应用部署到 Google Cloud Run一条命令从开发镜像到 Serverless 上线【免费下载链接】laradockFull PHP development environment for Docker. Run Laravel, Symfony, CodeIgniter, Phalcon, WordPress, Drupal, Magento, Moodle, or any PHP project with 70 pre-configured services: Nginx, Apache, PHP-FPM, MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch more.项目地址: https://gitcode.com/gh_mirrors/la/laradockLaradock 提供了一套栈、处处部署的生产镜像机制先用./laradock ship把任何 PHP 项目Laravel、Symfony、WordPress 等构建成一个内置 nginx php-fpm、监听$PORT的自包含镜像再推送到 Artifact Registry最后由 Cloud Run 直接运行空闲时自动缩容到零。读完本文你将掌握 Laradock 生产镜像的构建原理、Google Cloud Run 部署清单Knative Service的完整字段含义以及托管数据库、Secret Manager 与缩容策略的落地配置。背景为什么 Laradock 的镜像能在 Cloud Run 上开箱即用本地开发时Laradock 的docker-compose.yml面向开发调优代码 bind-mount 进容器、默认开启 Xdebug、opcache 每次请求都重新校验文件。生产环境恰恰相反——代码要固化进不可变镜像、去掉 Xdebug、冻结 opcache。Laradock 的 production/ 目录专门解决这个问题核心思路是一个 Docker 镜像就是通用部署适配器见 production/README.md 与 生产部署总指南。执行./laradock ship后得到的镜像与开发容器相比有几个关键差异依据 production/Dockerfile代码烤进镜像不再依赖 bind-mountcomposer install --no-dev --optimize-autoloader且项目没有composer.json时自动跳过WordPress、Moodle 这类项目也能直接构建opcache.validate_timestamps 0opcache 不再逐请求检查文件变更生产 php.inidisplay_errors Off、expose_php Off、memory_limit 256M、max_execution_time 60、upload_max_filesize 32M错误日志写入/proc/self/fd/2即容器 stdout/stderrCloud Run 可采集没有 Xdebugnginx 与 php-fpm 打进同一个容器通过 supervisord 一起托管对外只需暴露一个 HTTP 端口。正因如此这个镜像可以以单个容器形态运行在 Cloud Run、ECS、App Runner、Fly.io、Render 等任何能跑容器的平台上Laradock 不充当部署平台各云厂商也只当它是一个普通 OCI 镜像。第一步构建镜像并推送到 Artifact Registry./laradock ship是 Laradock CLI 提供的构建入口CLI 本体为仓库根目录的 laradock 脚本ship子命令实现见其中cmd_ship函数。它的工作流程是解析应用代码位置来自.env中的APP_CODE_PATH_HOST默认../即 laradock 目录旁边的项目目录若项目根目录没有.dockerignore自动从 production/dockerignore.sample 复制一份安全默认值排除.git、.env、node_modules、laradock/整个开发栈等确保密钥与 git 历史不进镜像使用production/Dockerfile构建镜像指定--push时执行docker push。针对 Cloud Run将镜像推送到 Google Artifact Registry 的命令为其中REGION、PROJECT、REPO分别替换为你的区域、项目 ID 与仓库名./laradock ship REGION-docker.pkg.dev/PROJECT/REPO/laradock-app:latest --push命令等价于底层docker build -f production/Dockerfile -t tag app_root加docker push。CLI 在运行时还会打印真实执行的 docker 命令便于核对。几个值得注意的 ship 行为Apple Silicon 默认构建linux/amd64大多数服务器与云平台运行的是 amd64arm64 镜像在上面会报 exec format error。CLI 检测到uname -m为arm64/aarch64时会自动加上--platform linux/amd64确实需要原生架构可用./laradock ship --platform linux/arm64覆盖。默认 tag 为laradock-app:latest与 production/compose.yml 中APP_IMAGE:-laradock-app:latest的默认值保持一致。PHP_VERSION与基础扩展与开发环境同源Dockerfile 顶部ARG BASE_IMAGElaradock/php-fpm:latest-${PHP_VERSION}默认PHP_VERSION8.3保证生产镜像与开发栈的 PHP 版本、扩展一致。若你在开发时额外启用了redis、pdo_pgsql、gd等扩展可在 Dockerfile 的extensions注释处补装或用--build-arg BASE_IMAGE指向本地构建的 laradock php-fpm 镜像。构建完成后可先在本地验证一次docker run -p 8080:8080 REGION-docker.pkg.dev/PROJECT/REPO/laradock-app:latest # 访问 http://localhost:8080仓库还提供了自动化验证脚本 production/smoke-test.sh它会用临时 PHP 应用构建production/Dockerfile启动单容器后反复curl检查 HTTP 响应中是否出现laradock-prod-ok以此断言自包含镜像能对外提供 HTTP 服务——这正是 Cloud Run 上线前最核心的验收项。第二步部署服务到 Cloud Run方式一使用仓库自带的 Knative Service 清单推荐Laradock 为 Cloud Run 准备了开箱即用的参考清单 google-cloud-run.yaml。它是一份标准的 Knative Serviceserving.knative.dev/v1定义全文如下# Laradock on Google Cloud Run. # gcloud run services replace laradock/production/providers/google-cloud-run.yaml --regionus-central1 # Cloud Run injects PORT and routes to containerPort 8080; the image honors PORT. # Secrets: reference Secret Manager (shown), or use plain env for non-secrets. apiVersion: serving.knative.dev/v1 kind: Service metadata: name: laradock-app spec: template: spec: containers: - image: us-central1-docker.pkg.dev/PROJECT_ID/REPO/laradock-app:latest ports: - containerPort: 8080 env: - name: APP_ENV value: production - name: DB_HOST value: your-managed-db-host - name: DB_PASSWORD valueFrom: secretKeyRef: key: latest name: db-password # a Secret Manager secret resources: limits: cpu: 1 memory: 512Mi把清单中的image换成第一步构建并推送的镜像地址然后执行gcloud run services replace laradock/production/providers/google-cloud-run.yaml --regionus-central1清单各字段与 Laradock 镜像的对应关系containerPort: 8080Cloud Run 会把平台注入的$PORT环境变量默认 8080路由到该容器端口。而 Laradock 生产镜像的入口脚本会在启动时读取$PORT并渲染进 nginx 配置两者正好对接详见下文镜像如何响应 $PORT。envAPP_ENVproduction与DB_HOST属于普通环境变量DB_PASSWORD通过secretKeyRef从 Secret Manager 引用name: db-password为 Secret Manager 中的密钥名。非敏感变量可直接写value敏感值一律走 Secret Manager——这与 production 目录密钥来自运行时环境变量或密钥管理服务绝不烤进镜像的安全准则一致参考 production/README.md 的 Security 章节与 dockerignore.sample。resources.limits示例给出cpu: 1、memory: 512Mi。Laradock 生产镜像内置opcache.memory_consumption 256、memory_limit 256M512Mi 是文档标注的起点可按应用实际负载调整。metadata.name: laradock-appCloud Run 服务名可自行修改。需要说明的是这份清单是刻意保持素颜的参考起点production 目录下的所有 providers 文件都如此复制到你的项目里按需修改即可而不是要学习的框架。方式二一条命令直接部署不修改清单时也可以用gcloud一键部署效果等价gcloud run deploy laradock-app --imageIMAGE --port8080 --regionus-central1其中IMAGE是第一步推送的完整镜像地址--port8080与清单中的containerPort保持一致--region可换成你的目标区域。部署完成后 Cloud Run 会分配 HTTPS 域名并接管流量、TLS 与自动扩缩容。第三步托管数据库、密钥与缩容策略Cloud Run 是无状态容器平台Laradock 的部署文档对三项配套给出了明确建议托管数据库Managed database使用Cloud SQL按需启用 Cloud SQL Auth Proxy / 连接器缓存使用Memorystore for Redis。不要在生产环境把数据库跑成容器——production 目录的准则明确写着数据库用托管服务Laradock 的数据库服务只用于本地开发见 production/README.md 与 生产部署总指南。实践中只需把DB_HOST、REDIS_HOST等环境变量指向托管实例镜像本身无需改动。密钥Secrets在Secret Manager中创建条目如db-password再像上面的清单那样用secretKeyRef引用。构建阶段则通过.dockerignore把.env挡在镜像之外做到密钥永远在运行时注入。缩容到零Scale to zeroCloud Run 在空闲时自动停止实例如果需要至少一个常驻实例设置min-instances即可。注意缩容到零意味着冷启动首个请求会有初始化延迟常驻实例会持续计费按业务取舍。镜像如何响应 $PORTCloud Run 兼容性的底层原理Cloud Run 要求容器监听平台注入的$PORTLaradock 生产镜像通过入口脚本与 nginx 模板实现了这一契约整个链路都可以在 production/Dockerfile 中看到nginx 站点是模板Dockerfile 以 heredoc 写入/etc/nginx/templates/site.conf.template其中listen ${PORT} default_server;、root ${WEBROOT};留待启动时填充nginx 自身的$uri等变量用$转义保持字面量。supervisord 同时托管 php-fpm 与 nginx[program:php-fpm]运行php-fpm -F[program:nginx]运行nginx -g daemon off;两者日志统一输出到容器 stdout/stderr供 Cloud Run 日志平台采集。入口脚本负责注入/usr/local/bin/laradock-entrypoint.sh的逻辑是——如果传入任何命令如php artisan queue:work直接exec $执行该命令worker、scheduler、migration 都复用同一镜像的命令覆盖机制否则以PORT默认 8080与WEBROOT默认/var/www/public为默认值用envsubst ${PORT} ${WEBROOT}渲染 nginx 配置再启动 supervisord#!/bin/sh set -e if [ $# -gt 0 ]; then exec $; fi : ${PORT:8080}; : ${WEBROOT:/var/www/public} export PORT WEBROOT envsubst ${PORT} ${WEBROOT} /etc/nginx/templates/site.conf.template /etc/nginx/conf.d/default.conf exec supervisord -c /etc/supervisor/conf.d/app.conf健康检查与元信息Dockerfile 末尾声明ENV PORT8080 WEBROOT/var/www/public、EXPOSE 8080并内置HEALTHCHECKcurl -fsS http://127.0.0.1:${PORT}/间隔 30s、超时 3s、重试 3 次。Cloud Run 若启用健康检查可直接复用该探测路径。由此可以推断出为什么镜像不用改、直接部署云平台注入$PORT→ 入口脚本读取并渲染 nginx 监听端口 → 平台健康检查/路由命中容器 8080 端口。任何遵循这一约定的单容器云平台Cloud Run、ECS、App Runner、Fly.io 等都能以同样方式运行同一个镜像。验证与故障排查本地预检docker run -p 8080:8080 IMAGE后访问http://localhost:8080确认镜像本身可服务。自动化冒烟运行 production/smoke-test.sh它会用临时 PHP 应用构建生产镜像并断言 HTTP 响应若失败会输出容器最近 20 行日志辅助定位。Cloud Run 侧排查gcloud run services describe laradock-app --regionus-central1查看服务状态日志可到 Cloud Logging 中按容器 stdout/stderr 过滤——Laradock 生产镜像的 php 错误日志已指向/proc/self/fd/2nginx/php-fpm 的 supervisord 日志也走/dev/stdout、/dev/stderr天然可被平台采集。扩展到其他部署目标Cloud Run 只是 Laradock 生产镜像的众多目标之一。生产部署总指南 覆盖了完整的部署矩阵production/providers/目录下还有 AWS ECSaws-ecs-task-definition.json、AWS App Runneraws-app-runner.json、Azure Container Appsazure-container-app.yaml、Fly.iofly.toml、Renderrender.yaml、Railwayrailway.json等参考配置自建基础设施可参考 Deploy to Kubernetes、Deploy with Kamal 与单机 Compose 部署production/compose.yml通过--profile worker/--profile scheduler按需启动队列 worker 与计划任务。核心心法始终是一条先./laradock ship构建出那个监听$PORT的自包含镜像再让各平台去运行它——云厂商差异只体现在推镜像的仓库地址与参考清单上应用侧无需任何平台专用代码。【免费下载链接】laradockFull PHP development environment for Docker. Run Laravel, Symfony, CodeIgniter, Phalcon, WordPress, Drupal, Magento, Moodle, or any PHP project with 70 pre-configured services: Nginx, Apache, PHP-FPM, MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch more.项目地址: https://gitcode.com/gh_mirrors/la/laradock创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考