Laradock 部署 Railway 指南用一张自包含镜像Nginx PHP-FPM把 Laravel / Symfony / WordPress 快速上云【免费下载链接】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导读本文基于 Laradock 官方部署指南DOCUMENTATION/docs/deploy/deploy-to-railway.md与仓库内的生产构建产物讲解如何把用 Laradock 开发的应用原封不动地部署到 Railway PaaS 平台。你将掌握./laradock ship构建自包含生产镜像、配置开箱即用的 railway.json、通过 CLI 或仪表盘完成发布以及托管数据库与密钥注入的正确姿势。在 Laradock 中开发栈 与 生产镜像 是两回事本地docker-compose.yml面向开发代码 bind-mount、Xdebug 可用、opcache 每次请求都检查文件而生产需要相反的特性——代码烤进不可变镜像、去掉 Xdebug、冻结 opcache。production/README.md 用一句话概括了整个生产体系的设计哲学The image is the universal deploy adapter.镜像是通用的部署适配器./laradock ship产出的是一张自包含的 OCI 镜像nginx php-fpm 打包在同一个容器里它对外只暴露一个 HTTP 端口$PORT。因此同一张镜像既可以跑在单台服务器上也可以跑在 Kubernetes、Cloud Run、ECS以及本文的主角Railway上——没有任何平台专属魔法需要学习。本文就以 Railway 为目标带你走完从本地构建到云端上线的全流程。一、为什么 Railway 能直接运行 Laradock 的镜像Railway 是一款托管 PaaS它会根据项目根目录的railway.json找到构建配置帮你拉取源码、构建镜像并部署服务。关键在于 Laradock 的生产镜像满足两个 Railway 的约定镜像自包含nginx 与 php-fpm 都在这一个容器里Railway 无需理解 PHP 生态只要运行这个容器即可。镜像遵从$PORT环境变量Railway 会向每个服务注入一个随机分配的$PORT而 Laradock 生产镜像在启动时会读取它并让 nginx 监听该端口。这正是官方指南 deploy-to-railway.md 开头所说的Railway builds the self-contained image (nginx php-fpm) from the production Dockerfile and injects$PORT, which the image honors.1.1 自包含镜像的内部结构源码级拆解打开 production/Dockerfile可以看到这张镜像的完整构成约 146 行注释详尽组成部分位置说明基础镜像Dockerfile L21-25laradock/php-fpm:latest-${PHP_VERSION}默认 PHP 8.3与开发环境同一套扩展生产 PHP 配置L30-43display_errorsOff、error_log/proc/self/fd/2日志直达容器 stdout/stderr、memory_limit256M、max_execution_time60、upload_max_filesize32M生产 opcacheL46-56opcache.validate_timestamps0镜像内代码不可变无需再校验时间戳nginx 站点模板L65-87listen ${PORT}、root ${WEBROOT}含安全响应头与隐藏点文件规则supervisor 编排L90-112nodaemontrue同时拉起php-fpm -F与nginx -g daemon off;入口脚本L115-124用envsubst把$PORT/$WEBROOT写入 nginx 配置后启动 supervisord依赖安装L131-134仅在存在composer.json时执行composer install --no-dev --optimize-autoloaderWordPress、Moodle 等无 composer 项目自动跳过健康检查L143-144HEALTHCHECK每 30s 用 curl 探测http://127.0.0.1:${PORT}/入口脚本L115-124是实现$PORT约定的关键其逻辑是#!/bin/sh set -e if [ $# -gt 0 ]; then exec $; fi # 传了命令参数直接执行worker/scheduler 场景 : ${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它同时解释了同镜像复用的设计如果向docker run传入命令如php artisan queue:work入口脚本会直接执行该命令从而用同一张镜像既跑 Web 服务又跑队列 Worker 与定时任务。二、步骤一用./laradock ship构建生产镜像构建镜像的命令在 laradock CLIcmd_shiplaradock L1216-1283与 production/README.md 中均有说明./laradock ship # 构建自包含 Web 镜像默认标签 laradock-app:latest ./laradock ship registry/you/app:1.0 --push # 指定标签并推送到镜像仓库cmd_ship的实际行为与 production.md 的描述一一对应定位应用代码从.env读取APP_CODE_PATH_HOST默认../作为构建上下文自动补.dockerignore如果应用根目录没有该文件会自动把 dockerignore.sample 复制过去laradock L1252-1255确保.git、.env、node_modules、tests、laradock/整个开发栈、production/.env、日志缓存等统统不进镜像Apple Silicon 默认构建linux/amd64laradock L1235-1243绝大多数服务器与 PaaS 是 amd64arm64 镜像上去会报exec format error如需原生架构可./laradock ship --platform linux/arm64默认标签laradock-app:latest与 production/compose.yml 中APP_IMAGE的默认值保持一致--push会把构建结果推到你的 registry供 Railway 拉取。如果不使用 CLI也可以直接用纯 Docker 完成同样的事见 production.mdcp laradock/production/dockerignore.sample .dockerignore docker build -f laradock/production/Dockerfile -t myapp:latest .2.1 本地验证镜像部署前先在本地确认镜像行为正确docker run -p 8080:8080 myapp:latest # → 打开 http://localhost:8080你得到的东西与开发容器截然不同代码烤进镜像无 bind-mount、composer install --no-dev、opcache 冻结、没有 Xdebug并且 PHP 版本与基础扩展与开发环境保持一致。仓库自带的 smoke-test.sh 演示了完整的验证思路用一个临时目录里的public/index.php输出laradock-prod-ok构建镜像、以-p 8088:8080启动然后轮询 30 秒断言能收到预期的 HTTP 响应失败则打印容器日志。三、步骤二把railway.json放进项目根目录构建好镜像后部署 Railway 的第一步是添加配置文件。官方指南deploy-to-railway.md要求把仓库内现成的 production/providers/railway.json 复制到你的项目根目录{ $schema: https://railway.app/railway.schema.json, build: { builder: DOCKERFILE, dockerfilePath: laradock/production/Dockerfile }, deploy: { healthcheckPath: /, restartPolicyType: ON_FAILURE, numReplicas: 1 } }这份配置告诉 Railway 三件事逐字段解读如下字段取值作用build.builderDOCKERFILE让 Railway 用 Dockerfile 方式构建而不是 Nixpacks 等自动检测build.dockerfilePathlaradock/production/Dockerfile构建入口指向 Laradock 仓库内的生产 Dockerfiledeploy.healthcheckPath/健康检查路径与镜像内置的HEALTHCHECK呼应两者都探测根路径deploy.restartPolicyTypeON_FAILURE仅在失败时重启避免滚动部署期间的无谓抖动deploy.numReplicas1单副本起步需要扩容时可在此调整需要说明的适用前提dockerfilePath是相对项目根目录的路径因此该文件默认假设你的 Laradock 以laradock/目录与项目代码平级存放与开发时APP_CODE_PATH_HOST../的经典布局一致。如果你的目录结构不同请同步修改这个路径。railway.json只是起点可以按需调整仓库的 providers 目录下还提供了 ECS、Cloud Run、Fly、Render 等同级别的参考配置模式完全一致。四、步骤三部署到 Railway官方指南给出了两种方式deploy-to-railway.md4.1 方式一Railway CLIrailway init # 在项目根目录初始化 Railway 项目 railway up # 上传并触发一次部署4.2 方式二Dashboard 关联仓库在 Railway 仪表盘中新建项目并连接你的 Git 仓库此后每次 push 都会自动触发部署官方指南原文Or connect the repo in the Railway dashboard, it deploys on every push。4.3 配置环境变量必做镜像自身不含任何密钥与数据库连接信息需要在服务设置中注入。官方指南明确点名的三个变量DB_HOST DB_PASSWORD APP_KEYRailway 会把这些变量作为service variables服务级变量注入容器运行时同时自动注入$PORT让 nginx 监听。它们永远不应出现在镜像里——这正是 dockerignore.sample 把.env、.env.*、production/.env全部排除的原因Secrets are service variables, never in the image。五、生产注意事项托管数据库与密钥5.1 使用托管数据库而不是容器化数据库官方指南的 Notes 部分给出了明确的建议Managed database. Add Railway Postgres and Railway Redis as plugins, or use a managed provider在 Railway 上添加Railway Postgres与Railway Redis插件或使用任意托管数据库服务把DB_*/REDIS_*系列变量指向这些托管服务。这与整个 Laradock 生产体系的立场一致production/compose.yml 有意不暴露任何数据库端口只发布 Web 端口${HTTP_PORT:-80}:${PORT:-8080}production/README.md 也强调Managed DB always. Never run your production database as a container.因为容器内的数据会随部署一起被替换生产数据必须外置。5.2 密钥只存在于运行时环境密钥数据库密码、APP_KEY、第三方 API Token 等通过 Railway 服务设置注入属于运行时环境变量。镜像里只有代码与依赖这让镜像本身可以安全地推到公开或私有 registry也保证了密钥随环境隔离。六、进阶同一张镜像跑 Worker、Scheduler 与迁移PHP 应用的标配是Web 容器 托管数据库框架在此基础上需要额外的进程参考 production/README.md 的对照表应用类型Worker定时任务 / Cron持久化文件Laravelphp artisan queue:workphp artisan schedule:runstorage/Symfonyphp artisan messenger:consume按需var/WordPress—wp-cron / 系统 cronwp-content/uploadsMoodle—必需admin/cli/cron.phpmoodledata纯 PHP——按需得益于入口脚本有命令参数就执行的设计production/Dockerfile L118这些进程可以复用同一张镜像只需覆盖启动命令docker run --rm myapp php artisan queue:work --tries3 --timeout90 # Worker docker run --rm myapp php artisan schedule:run # 定时任务 docker run --rm myapp php artisan migrate --force # 每次部署前执行一次迁移在 Railway 上可以在同一个项目中添加多个 Service 指向同一镜像并覆盖启动命令如果使用的是 Docker Compose 工作流production/compose.yml 还提供了现成的worker与scheduler服务模板分别以--profile worker/--profile scheduler开启。另外注意持久化文件上传、日志、缓存应放在对象存储S3或挂载卷上绝不能写进镜像内——每次部署都会用新镜像替换整个容器。七、验证、排错与参考健康检查镜像内置HEALTHCHECKproduction/Dockerfile L143-144Railway 侧railway.json的healthcheckPath: /与之对应若应用根路由响应慢或返回非 2xxRailway 会判定实例不健康并触发ON_FAILURE重启策略。日志排查生产 PHP 配置把error_log指向/proc/self/fd/2production/Dockerfile L35supervisor 的 nginx 与 php-fpm 日志也都打到/dev/stdout//dev/stderrL97-111因此所有日志都能在 Railway 的日志面板直接查看无需进容器。本地自测./production/smoke-test.sh可以在没有任何真实项目的情况下验证镜像能否构建并响应 HTTP上线前跑一遍能提前暴露基础镜像、入口脚本等层面的问题。架构匹配若部署后出现exec format error说明镜像架构与 Railway 运行环境不匹配需用./laradock ship --platform linux/amd64重新构建见 laradock L1235-1243。想部署到别的平台完整的部署总览见 production.md单服务器方式见 deploy-to-a-server.md自建基础设施可参考 deploy-to-kamal.md 与 deploy-to-kubernetes.md——核心思想始终不变一张自包含镜像处处可跑。【免费下载链接】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），仅供参考 Laradock 部署 Railway 指南：用一张自包含镜像（Nginx + PHP-FPM）把 Laravel / Symfony / WordPress 快速上云
Laradock 部署 Railway 指南用一张自包含镜像Nginx PHP-FPM把 Laravel / Symfony / WordPress 快速上云【免费下载链接】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导读本文基于 Laradock 官方部署指南DOCUMENTATION/docs/deploy/deploy-to-railway.md与仓库内的生产构建产物讲解如何把用 Laradock 开发的应用原封不动地部署到 Railway PaaS 平台。你将掌握./laradock ship构建自包含生产镜像、配置开箱即用的 railway.json、通过 CLI 或仪表盘完成发布以及托管数据库与密钥注入的正确姿势。在 Laradock 中开发栈 与 生产镜像 是两回事本地docker-compose.yml面向开发代码 bind-mount、Xdebug 可用、opcache 每次请求都检查文件而生产需要相反的特性——代码烤进不可变镜像、去掉 Xdebug、冻结 opcache。production/README.md 用一句话概括了整个生产体系的设计哲学The image is the universal deploy adapter.镜像是通用的部署适配器./laradock ship产出的是一张自包含的 OCI 镜像nginx php-fpm 打包在同一个容器里它对外只暴露一个 HTTP 端口$PORT。因此同一张镜像既可以跑在单台服务器上也可以跑在 Kubernetes、Cloud Run、ECS以及本文的主角Railway上——没有任何平台专属魔法需要学习。本文就以 Railway 为目标带你走完从本地构建到云端上线的全流程。一、为什么 Railway 能直接运行 Laradock 的镜像Railway 是一款托管 PaaS它会根据项目根目录的railway.json找到构建配置帮你拉取源码、构建镜像并部署服务。关键在于 Laradock 的生产镜像满足两个 Railway 的约定镜像自包含nginx 与 php-fpm 都在这一个容器里Railway 无需理解 PHP 生态只要运行这个容器即可。镜像遵从$PORT环境变量Railway 会向每个服务注入一个随机分配的$PORT而 Laradock 生产镜像在启动时会读取它并让 nginx 监听该端口。这正是官方指南 deploy-to-railway.md 开头所说的Railway builds the self-contained image (nginx php-fpm) from the production Dockerfile and injects$PORT, which the image honors.1.1 自包含镜像的内部结构源码级拆解打开 production/Dockerfile可以看到这张镜像的完整构成约 146 行注释详尽组成部分位置说明基础镜像Dockerfile L21-25laradock/php-fpm:latest-${PHP_VERSION}默认 PHP 8.3与开发环境同一套扩展生产 PHP 配置L30-43display_errorsOff、error_log/proc/self/fd/2日志直达容器 stdout/stderr、memory_limit256M、max_execution_time60、upload_max_filesize32M生产 opcacheL46-56opcache.validate_timestamps0镜像内代码不可变无需再校验时间戳nginx 站点模板L65-87listen ${PORT}、root ${WEBROOT}含安全响应头与隐藏点文件规则supervisor 编排L90-112nodaemontrue同时拉起php-fpm -F与nginx -g daemon off;入口脚本L115-124用envsubst把$PORT/$WEBROOT写入 nginx 配置后启动 supervisord依赖安装L131-134仅在存在composer.json时执行composer install --no-dev --optimize-autoloaderWordPress、Moodle 等无 composer 项目自动跳过健康检查L143-144HEALTHCHECK每 30s 用 curl 探测http://127.0.0.1:${PORT}/入口脚本L115-124是实现$PORT约定的关键其逻辑是#!/bin/sh set -e if [ $# -gt 0 ]; then exec $; fi # 传了命令参数直接执行worker/scheduler 场景 : ${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它同时解释了同镜像复用的设计如果向docker run传入命令如php artisan queue:work入口脚本会直接执行该命令从而用同一张镜像既跑 Web 服务又跑队列 Worker 与定时任务。二、步骤一用./laradock ship构建生产镜像构建镜像的命令在 laradock CLIcmd_shiplaradock L1216-1283与 production/README.md 中均有说明./laradock ship # 构建自包含 Web 镜像默认标签 laradock-app:latest ./laradock ship registry/you/app:1.0 --push # 指定标签并推送到镜像仓库cmd_ship的实际行为与 production.md 的描述一一对应定位应用代码从.env读取APP_CODE_PATH_HOST默认../作为构建上下文自动补.dockerignore如果应用根目录没有该文件会自动把 dockerignore.sample 复制过去laradock L1252-1255确保.git、.env、node_modules、tests、laradock/整个开发栈、production/.env、日志缓存等统统不进镜像Apple Silicon 默认构建linux/amd64laradock L1235-1243绝大多数服务器与 PaaS 是 amd64arm64 镜像上去会报exec format error如需原生架构可./laradock ship --platform linux/arm64默认标签laradock-app:latest与 production/compose.yml 中APP_IMAGE的默认值保持一致--push会把构建结果推到你的 registry供 Railway 拉取。如果不使用 CLI也可以直接用纯 Docker 完成同样的事见 production.mdcp laradock/production/dockerignore.sample .dockerignore docker build -f laradock/production/Dockerfile -t myapp:latest .2.1 本地验证镜像部署前先在本地确认镜像行为正确docker run -p 8080:8080 myapp:latest # → 打开 http://localhost:8080你得到的东西与开发容器截然不同代码烤进镜像无 bind-mount、composer install --no-dev、opcache 冻结、没有 Xdebug并且 PHP 版本与基础扩展与开发环境保持一致。仓库自带的 smoke-test.sh 演示了完整的验证思路用一个临时目录里的public/index.php输出laradock-prod-ok构建镜像、以-p 8088:8080启动然后轮询 30 秒断言能收到预期的 HTTP 响应失败则打印容器日志。三、步骤二把railway.json放进项目根目录构建好镜像后部署 Railway 的第一步是添加配置文件。官方指南deploy-to-railway.md要求把仓库内现成的 production/providers/railway.json 复制到你的项目根目录{ $schema: https://railway.app/railway.schema.json, build: { builder: DOCKERFILE, dockerfilePath: laradock/production/Dockerfile }, deploy: { healthcheckPath: /, restartPolicyType: ON_FAILURE, numReplicas: 1 } }这份配置告诉 Railway 三件事逐字段解读如下字段取值作用build.builderDOCKERFILE让 Railway 用 Dockerfile 方式构建而不是 Nixpacks 等自动检测build.dockerfilePathlaradock/production/Dockerfile构建入口指向 Laradock 仓库内的生产 Dockerfiledeploy.healthcheckPath/健康检查路径与镜像内置的HEALTHCHECK呼应两者都探测根路径deploy.restartPolicyTypeON_FAILURE仅在失败时重启避免滚动部署期间的无谓抖动deploy.numReplicas1单副本起步需要扩容时可在此调整需要说明的适用前提dockerfilePath是相对项目根目录的路径因此该文件默认假设你的 Laradock 以laradock/目录与项目代码平级存放与开发时APP_CODE_PATH_HOST../的经典布局一致。如果你的目录结构不同请同步修改这个路径。railway.json只是起点可以按需调整仓库的 providers 目录下还提供了 ECS、Cloud Run、Fly、Render 等同级别的参考配置模式完全一致。四、步骤三部署到 Railway官方指南给出了两种方式deploy-to-railway.md4.1 方式一Railway CLIrailway init # 在项目根目录初始化 Railway 项目 railway up # 上传并触发一次部署4.2 方式二Dashboard 关联仓库在 Railway 仪表盘中新建项目并连接你的 Git 仓库此后每次 push 都会自动触发部署官方指南原文Or connect the repo in the Railway dashboard, it deploys on every push。4.3 配置环境变量必做镜像自身不含任何密钥与数据库连接信息需要在服务设置中注入。官方指南明确点名的三个变量DB_HOST DB_PASSWORD APP_KEYRailway 会把这些变量作为service variables服务级变量注入容器运行时同时自动注入$PORT让 nginx 监听。它们永远不应出现在镜像里——这正是 dockerignore.sample 把.env、.env.*、production/.env全部排除的原因Secrets are service variables, never in the image。五、生产注意事项托管数据库与密钥5.1 使用托管数据库而不是容器化数据库官方指南的 Notes 部分给出了明确的建议Managed database. Add Railway Postgres and Railway Redis as plugins, or use a managed provider在 Railway 上添加Railway Postgres与Railway Redis插件或使用任意托管数据库服务把DB_*/REDIS_*系列变量指向这些托管服务。这与整个 Laradock 生产体系的立场一致production/compose.yml 有意不暴露任何数据库端口只发布 Web 端口${HTTP_PORT:-80}:${PORT:-8080}production/README.md 也强调Managed DB always. Never run your production database as a container.因为容器内的数据会随部署一起被替换生产数据必须外置。5.2 密钥只存在于运行时环境密钥数据库密码、APP_KEY、第三方 API Token 等通过 Railway 服务设置注入属于运行时环境变量。镜像里只有代码与依赖这让镜像本身可以安全地推到公开或私有 registry也保证了密钥随环境隔离。六、进阶同一张镜像跑 Worker、Scheduler 与迁移PHP 应用的标配是Web 容器 托管数据库框架在此基础上需要额外的进程参考 production/README.md 的对照表应用类型Worker定时任务 / Cron持久化文件Laravelphp artisan queue:workphp artisan schedule:runstorage/Symfonyphp artisan messenger:consume按需var/WordPress—wp-cron / 系统 cronwp-content/uploadsMoodle—必需admin/cli/cron.phpmoodledata纯 PHP——按需得益于入口脚本有命令参数就执行的设计production/Dockerfile L118这些进程可以复用同一张镜像只需覆盖启动命令docker run --rm myapp php artisan queue:work --tries3 --timeout90 # Worker docker run --rm myapp php artisan schedule:run # 定时任务 docker run --rm myapp php artisan migrate --force # 每次部署前执行一次迁移在 Railway 上可以在同一个项目中添加多个 Service 指向同一镜像并覆盖启动命令如果使用的是 Docker Compose 工作流production/compose.yml 还提供了现成的worker与scheduler服务模板分别以--profile worker/--profile scheduler开启。另外注意持久化文件上传、日志、缓存应放在对象存储S3或挂载卷上绝不能写进镜像内——每次部署都会用新镜像替换整个容器。七、验证、排错与参考健康检查镜像内置HEALTHCHECKproduction/Dockerfile L143-144Railway 侧railway.json的healthcheckPath: /与之对应若应用根路由响应慢或返回非 2xxRailway 会判定实例不健康并触发ON_FAILURE重启策略。日志排查生产 PHP 配置把error_log指向/proc/self/fd/2production/Dockerfile L35supervisor 的 nginx 与 php-fpm 日志也都打到/dev/stdout//dev/stderrL97-111因此所有日志都能在 Railway 的日志面板直接查看无需进容器。本地自测./production/smoke-test.sh可以在没有任何真实项目的情况下验证镜像能否构建并响应 HTTP上线前跑一遍能提前暴露基础镜像、入口脚本等层面的问题。架构匹配若部署后出现exec format error说明镜像架构与 Railway 运行环境不匹配需用./laradock ship --platform linux/amd64重新构建见 laradock L1235-1243。想部署到别的平台完整的部署总览见 production.md单服务器方式见 deploy-to-a-server.md自建基础设施可参考 deploy-to-kamal.md 与 deploy-to-kubernetes.md——核心思想始终不变一张自包含镜像处处可跑。【免费下载链接】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），仅供参考