尧图网站建设 
使用 Laradock 将 PHP 应用部署到 AWS App Runner一条命令构建镜像、推送 ECR 并上线【免费下载链接】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 仓库中的 deploy-to-aws-app-runner.md 文档讲解如何把用 Laradock 开发的 PHP 应用Laravel、Symfony、WordPress 等无痛迁移到AWS App Runner通过./laradock ship构建一个nginx php-fpm 合体的自包含镜像推送到 ECR 后用仓库自带的aws-app-runner.json一键创建服务即可获得内置 HTTPS 与自动扩缩容的生产运行环境无需配置负载均衡器。读完本文你将掌握镜像构建、ECR 推送、App Runner 服务创建的完整命令链以及数据库、密钥、自动部署等生产级配置要点。核心思路镜像即通用部署适配器AWS App Runner 是一个托管容器服务你把镜像交给它它负责运行、扩缩容、HTTPS 与健康检查。因此部署的唯一前置产物就是一份自包含的镜像。Laradock 的生产镜像由 production/Dockerfile 定义它的设计哲学在文件头部注释中写得很清楚ONE image that serves HTTP on $PORT (nginx php-fpm inside), so it runs anywhere a container runs—— 一份镜像可以原样跑在单台服务器、Kubernetes、Cloud Run、ECS、App Runner、Fly、Render 等任何能运行容器的目标上无需为每个平台重写镜像。这份镜像在开发容器的基础上做了以下生产化处理单容器承载 Web 服务镜像内同时安装 nginx 与 supervisor由 supervisor 配置 同时拉起php-fpm -F和nginx -g daemon off;两个进程的日志都重定向到容器的 stdout/stderr便于 App Runner 等平台采集生产 PHP 配置zz-laradock-prod.ini关闭display_errors、expose_php开启log_errors并把错误日志写到/proc/self/fd/2即 stdout/stderr同时设定memory_limit 256M、upload_max_filesize 32M等常用上限生产级 OpCachezz-laradock-opcache.iniopcache.validate_timestamps 0因为容器内的代码在部署后不再变动可最大化字节码缓存命中入口脚本自适应laradock-entrypoint.sh 默认以PORT缺省 8080和WEBROOT缺省/var/www/public为模板渲染 nginx 站点配置如果传入额外命令如php artisan queue:work则直接执行该命令而非启动 Web 服务这为后续扩展 worker/scheduler 留下了通道健康检查Dockerfile 内置HEALTHCHECK间隔 30s、超时 3s、重试 3 次用 curl 探测容器内http://127.0.0.1:${PORT}/与 App Runner 的 HTTP 健康检查语义一致。第一步构建镜像并推送到 ECR1.1 创建 ECR 仓库首先在 AWS 上创建存放镜像的 ECR 私有仓库也可在控制台创建后跳过此命令aws ecr create-repository --repository-name laradock-app1.2 构建并推送在 Laradock 仓库根目录执行./laradock ship指定完整 ECR 镜像地址与--push./laradock ship ACCOUNT.dkr.ecr.REGION.amazonaws.com/laradock-app:latest --push从 laradock CLI 的 ship 命令实现 可以看到这条命令背后的几个关键行为定位应用代码通过.env中的APP_CODE_PATH_HOST缺省为../即 Laradock 仓库的上一级目录找到你的 PHP 项目作为构建上下文自动补全 .dockerignore如果应用根目录没有.dockerignore会把 production/dockerignore.sample 复制过去确保.git、密钥等不被烧进镜像这也是后面密钥绝不进镜像原则的落地平台适配在 Apple Silicon 上默认构建linux/amd64避免 arm64 镜像在大多数 amd64 服务器/云平台上出现 exec format error如需原生 arm64 可显式指定./laradock ship --platform linux/arm64构建时的依赖安装镜像构建过程中如果检测到项目存在composer.json会自动执行composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist见 production/Dockerfile并将代码以www-data身份复制进/var/www。推送到 ECR 之前务必先用aws ecr get-login-password --region REGION | docker login --username AWS --password-stdin ACCOUNT.dkr.ecr.REGION.amazonaws.com完成 Docker 客户端登录本仓库不包含该命令属于 AWS 标准前置操作。1.3 本地先验证镜像在推送之前可以本地先跑一遍确认镜像能正常对外提供 HTTP 服务docker run -p 8080:8080 ACCOUNT.dkr.ecr.REGION.amazonaws.com/laradock-app:latest # 浏览器访问 http://localhost:8080仓库还提供了自动化冒烟测试脚本 production/smoke-test.sh它会用临时 PHP 应用构建镜像、启动容器并断言能返回laradock-prod-ok响应可作为 CI 中验证生产镜像的最小回归用例。第二步使用仓库自带的配置创建 App Runner 服务Laradock 已经为 App Runner 准备好了可直接使用的服务配置production/providers/aws-app-runner.json。它的完整内容如下{ ServiceName: laradock-app, SourceConfiguration: { ImageRepository: { ImageIdentifier: ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/laradock-app:latest, ImageRepositoryType: ECR, ImageConfiguration: { Port: 8080, RuntimeEnvironmentVariables: { APP_ENV: production, DB_HOST: your-managed-db-host } } }, AutoDeploymentsEnabled: true }, InstanceConfiguration: { Cpu: 1024, Memory: 2048 }, HealthCheckConfiguration: { Protocol: HTTP, Path: /, Interval: 10, Timeout: 5 } }把文件里的ACCOUNT_ID、REGION替换成你的实际值并视需要补充RuntimeEnvironmentVariables然后执行aws apprunner create-service --cli-input-json file://aws-app-runner.json逐字段解读这份配置与 Laradock 生产镜像的对应关系配置字段值与 Laradock 镜像的对应关系SourceConfiguration.ImageRepository.ImageRepositoryTypeECR镜像来源为 ECR 私有仓库ImageConfiguration.Port8080与 production/Dockerfile 的ENV PORT8080及EXPOSE 8080严格对应App Runner 会对该端口发起流量RuntimeEnvironmentVariablesAPP_ENV、DB_HOST等对应 production/.env.example 中的应用变量运行时注入绝不写入镜像AutoDeploymentsEnabledtrue启用镜像标签级自动部署见下文自动部署InstanceConfiguration.Cpu / Memory1024/2048实例规格1 vCPU、2 GiB可按流量调整HealthCheckConfigurationHTTP、/、间隔 10s、超时 5s与镜像内置 HEALTHCHECK 语义一致探活根路径/实操提示从仓库结构看这份 JSON 是刻意保持简洁的起点production/README.md 明确说明这些 provider 配置是 starting points需要按项目实际复制调整。App Runner 拉取 ECR 私有镜像通常还需要为服务配置访问 ECR 的 IAM 角色/权限以及按需启用 VPC 连接这些需要结合你账户的实际 IAM 与网络环境补齐。生产环境三件套托管数据库、密钥与自动部署原文档在 Notes 中给出了三条上线后的硬性原则这里结合仓库配置逐一展开托管数据库RDS VPC 连接器生产环境的数据库应该使用RDS 等托管服务而不是把数据库跑在容器里。连接方式通过 App Runner 的 VPC 连接器VPC connector让服务访问到 RDS。配置层面只需要在RuntimeEnvironmentVariables或运行时环境中注入DB_HOST、DB_PORT、DB_DATABASE、DB_USERNAME、DB_PASSWORD命名与 production/.env.example 中的 Laravel 约定一致Symfony/WordPress 等按各自框架改名即可。Laradock 的单服务器 Compose 文件 production/compose.yml 同样刻意不暴露任何数据库端口这条托管数据库、容器只跑应用的原则在所有部署目标上保持一致。密钥来自运行时环境 / Secrets Manager绝不进镜像生产镜像构建时就把.env密钥挡在门外./laradock ship会自动为应用补写 .dockerignore见 production/dockerignore.sample确保.env、.git、SSH 密钥等不会进入镜像层。所有敏感值应通过 App Runner 的运行时环境变量或 AWS Secrets Manager 注入这样镜像本身可以安全地公开分发、跨环境复用。自动部署推新标签即触发重部署配置中的AutoDeploymentsEnabled: true意味着当你向 ECR 推送新的镜像标签例如新的:latest时App Runner 会自动重新部署服务无需手动干预。这正好与./laradock ship ... --push形成闭环本地一条命令完成构建 推送云上自动完成发布。扩展worker、调度器与迁移App Runner 以单容器服务为单位Laravel/Symfony 等框架的队列、调度、迁移如何落地关键点在于 Laradock 生产镜像的命令覆盖机制——entrypoint 脚本 检测到传入命令时直接exec $执行而不是启动 Web 服务。因此在同一份镜像之上迁移在流量切换前执行一次docker run --rm 镜像 php artisan migrate --force队列 workerphp artisan queue:work --tries3 --timeout90对应 production/.env.example 的WORKER_COMMAND缺省值调度器php artisan schedule:run对应SCHEDULER_COMMAND缺省值。在 App Runner 上你可以基于同一镜像创建第二个服务如laradock-app-worker并覆写启动命令来承载这些后台进程若希望用更成熟的方式编排 worker 与定时任务可参考 deploy-to-aws-ecs.mdECS 任务定义 production/providers/aws-ecs-task-definition.json或 Kubernetes 方案 production/kubernetes.yaml。此外任何持久化文件Laravelstorage/、WordPresswp-content/uploads、Moodlemoodledata都必须放到 S3 对象存储或挂载卷上因为每次部署都会用新镜像替换容器镜像内的文件改动无法保留详见 production/README.md 的框架对照表。小结与更多部署目标整个流程可以浓缩为三步aws ecr create-repository建仓库 →./laradock ship ECR地址 --push构建并推送自包含镜像 →aws apprunner create-service --cli-input-json file://aws-app-runner.json创建服务。HTTPS、自动扩缩容与健康检查全部由 App Runner 托管你无需配置负载均衡器。这份同一镜像、多处运行的资产可以被复用到其他目标单台服务器见 deploy-to-a-server.md配合 production/compose.yml 与--profile worker --profile schedulerKubernetes 见 deploy-to-kubernetes.md其余云端目标ECS、Cloud Run、Fly、Render 等的参考配置都集中在 production/providers/ 目录下完整的部署总览参见 production.md。关于用 Laradock 搭建本地开发环境可先阅读 Intro 与 getting-started.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 将 PHP 应用部署到 AWS App Runner：一条命令构建镜像、推送 ECR 并上线
使用 Laradock 将 PHP 应用部署到 AWS App Runner一条命令构建镜像、推送 ECR 并上线【免费下载链接】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 仓库中的 deploy-to-aws-app-runner.md 文档讲解如何把用 Laradock 开发的 PHP 应用Laravel、Symfony、WordPress 等无痛迁移到AWS App Runner通过./laradock ship构建一个nginx php-fpm 合体的自包含镜像推送到 ECR 后用仓库自带的aws-app-runner.json一键创建服务即可获得内置 HTTPS 与自动扩缩容的生产运行环境无需配置负载均衡器。读完本文你将掌握镜像构建、ECR 推送、App Runner 服务创建的完整命令链以及数据库、密钥、自动部署等生产级配置要点。核心思路镜像即通用部署适配器AWS App Runner 是一个托管容器服务你把镜像交给它它负责运行、扩缩容、HTTPS 与健康检查。因此部署的唯一前置产物就是一份自包含的镜像。Laradock 的生产镜像由 production/Dockerfile 定义它的设计哲学在文件头部注释中写得很清楚ONE image that serves HTTP on $PORT (nginx php-fpm inside), so it runs anywhere a container runs—— 一份镜像可以原样跑在单台服务器、Kubernetes、Cloud Run、ECS、App Runner、Fly、Render 等任何能运行容器的目标上无需为每个平台重写镜像。这份镜像在开发容器的基础上做了以下生产化处理单容器承载 Web 服务镜像内同时安装 nginx 与 supervisor由 supervisor 配置 同时拉起php-fpm -F和nginx -g daemon off;两个进程的日志都重定向到容器的 stdout/stderr便于 App Runner 等平台采集生产 PHP 配置zz-laradock-prod.ini关闭display_errors、expose_php开启log_errors并把错误日志写到/proc/self/fd/2即 stdout/stderr同时设定memory_limit 256M、upload_max_filesize 32M等常用上限生产级 OpCachezz-laradock-opcache.iniopcache.validate_timestamps 0因为容器内的代码在部署后不再变动可最大化字节码缓存命中入口脚本自适应laradock-entrypoint.sh 默认以PORT缺省 8080和WEBROOT缺省/var/www/public为模板渲染 nginx 站点配置如果传入额外命令如php artisan queue:work则直接执行该命令而非启动 Web 服务这为后续扩展 worker/scheduler 留下了通道健康检查Dockerfile 内置HEALTHCHECK间隔 30s、超时 3s、重试 3 次用 curl 探测容器内http://127.0.0.1:${PORT}/与 App Runner 的 HTTP 健康检查语义一致。第一步构建镜像并推送到 ECR1.1 创建 ECR 仓库首先在 AWS 上创建存放镜像的 ECR 私有仓库也可在控制台创建后跳过此命令aws ecr create-repository --repository-name laradock-app1.2 构建并推送在 Laradock 仓库根目录执行./laradock ship指定完整 ECR 镜像地址与--push./laradock ship ACCOUNT.dkr.ecr.REGION.amazonaws.com/laradock-app:latest --push从 laradock CLI 的 ship 命令实现 可以看到这条命令背后的几个关键行为定位应用代码通过.env中的APP_CODE_PATH_HOST缺省为../即 Laradock 仓库的上一级目录找到你的 PHP 项目作为构建上下文自动补全 .dockerignore如果应用根目录没有.dockerignore会把 production/dockerignore.sample 复制过去确保.git、密钥等不被烧进镜像这也是后面密钥绝不进镜像原则的落地平台适配在 Apple Silicon 上默认构建linux/amd64避免 arm64 镜像在大多数 amd64 服务器/云平台上出现 exec format error如需原生 arm64 可显式指定./laradock ship --platform linux/arm64构建时的依赖安装镜像构建过程中如果检测到项目存在composer.json会自动执行composer install --no-dev --optimize-autoloader --no-interaction --no-progress --prefer-dist见 production/Dockerfile并将代码以www-data身份复制进/var/www。推送到 ECR 之前务必先用aws ecr get-login-password --region REGION | docker login --username AWS --password-stdin ACCOUNT.dkr.ecr.REGION.amazonaws.com完成 Docker 客户端登录本仓库不包含该命令属于 AWS 标准前置操作。1.3 本地先验证镜像在推送之前可以本地先跑一遍确认镜像能正常对外提供 HTTP 服务docker run -p 8080:8080 ACCOUNT.dkr.ecr.REGION.amazonaws.com/laradock-app:latest # 浏览器访问 http://localhost:8080仓库还提供了自动化冒烟测试脚本 production/smoke-test.sh它会用临时 PHP 应用构建镜像、启动容器并断言能返回laradock-prod-ok响应可作为 CI 中验证生产镜像的最小回归用例。第二步使用仓库自带的配置创建 App Runner 服务Laradock 已经为 App Runner 准备好了可直接使用的服务配置production/providers/aws-app-runner.json。它的完整内容如下{ ServiceName: laradock-app, SourceConfiguration: { ImageRepository: { ImageIdentifier: ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/laradock-app:latest, ImageRepositoryType: ECR, ImageConfiguration: { Port: 8080, RuntimeEnvironmentVariables: { APP_ENV: production, DB_HOST: your-managed-db-host } } }, AutoDeploymentsEnabled: true }, InstanceConfiguration: { Cpu: 1024, Memory: 2048 }, HealthCheckConfiguration: { Protocol: HTTP, Path: /, Interval: 10, Timeout: 5 } }把文件里的ACCOUNT_ID、REGION替换成你的实际值并视需要补充RuntimeEnvironmentVariables然后执行aws apprunner create-service --cli-input-json file://aws-app-runner.json逐字段解读这份配置与 Laradock 生产镜像的对应关系配置字段值与 Laradock 镜像的对应关系SourceConfiguration.ImageRepository.ImageRepositoryTypeECR镜像来源为 ECR 私有仓库ImageConfiguration.Port8080与 production/Dockerfile 的ENV PORT8080及EXPOSE 8080严格对应App Runner 会对该端口发起流量RuntimeEnvironmentVariablesAPP_ENV、DB_HOST等对应 production/.env.example 中的应用变量运行时注入绝不写入镜像AutoDeploymentsEnabledtrue启用镜像标签级自动部署见下文自动部署InstanceConfiguration.Cpu / Memory1024/2048实例规格1 vCPU、2 GiB可按流量调整HealthCheckConfigurationHTTP、/、间隔 10s、超时 5s与镜像内置 HEALTHCHECK 语义一致探活根路径/实操提示从仓库结构看这份 JSON 是刻意保持简洁的起点production/README.md 明确说明这些 provider 配置是 starting points需要按项目实际复制调整。App Runner 拉取 ECR 私有镜像通常还需要为服务配置访问 ECR 的 IAM 角色/权限以及按需启用 VPC 连接这些需要结合你账户的实际 IAM 与网络环境补齐。生产环境三件套托管数据库、密钥与自动部署原文档在 Notes 中给出了三条上线后的硬性原则这里结合仓库配置逐一展开托管数据库RDS VPC 连接器生产环境的数据库应该使用RDS 等托管服务而不是把数据库跑在容器里。连接方式通过 App Runner 的 VPC 连接器VPC connector让服务访问到 RDS。配置层面只需要在RuntimeEnvironmentVariables或运行时环境中注入DB_HOST、DB_PORT、DB_DATABASE、DB_USERNAME、DB_PASSWORD命名与 production/.env.example 中的 Laravel 约定一致Symfony/WordPress 等按各自框架改名即可。Laradock 的单服务器 Compose 文件 production/compose.yml 同样刻意不暴露任何数据库端口这条托管数据库、容器只跑应用的原则在所有部署目标上保持一致。密钥来自运行时环境 / Secrets Manager绝不进镜像生产镜像构建时就把.env密钥挡在门外./laradock ship会自动为应用补写 .dockerignore见 production/dockerignore.sample确保.env、.git、SSH 密钥等不会进入镜像层。所有敏感值应通过 App Runner 的运行时环境变量或 AWS Secrets Manager 注入这样镜像本身可以安全地公开分发、跨环境复用。自动部署推新标签即触发重部署配置中的AutoDeploymentsEnabled: true意味着当你向 ECR 推送新的镜像标签例如新的:latest时App Runner 会自动重新部署服务无需手动干预。这正好与./laradock ship ... --push形成闭环本地一条命令完成构建 推送云上自动完成发布。扩展worker、调度器与迁移App Runner 以单容器服务为单位Laravel/Symfony 等框架的队列、调度、迁移如何落地关键点在于 Laradock 生产镜像的命令覆盖机制——entrypoint 脚本 检测到传入命令时直接exec $执行而不是启动 Web 服务。因此在同一份镜像之上迁移在流量切换前执行一次docker run --rm 镜像 php artisan migrate --force队列 workerphp artisan queue:work --tries3 --timeout90对应 production/.env.example 的WORKER_COMMAND缺省值调度器php artisan schedule:run对应SCHEDULER_COMMAND缺省值。在 App Runner 上你可以基于同一镜像创建第二个服务如laradock-app-worker并覆写启动命令来承载这些后台进程若希望用更成熟的方式编排 worker 与定时任务可参考 deploy-to-aws-ecs.mdECS 任务定义 production/providers/aws-ecs-task-definition.json或 Kubernetes 方案 production/kubernetes.yaml。此外任何持久化文件Laravelstorage/、WordPresswp-content/uploads、Moodlemoodledata都必须放到 S3 对象存储或挂载卷上因为每次部署都会用新镜像替换容器镜像内的文件改动无法保留详见 production/README.md 的框架对照表。小结与更多部署目标整个流程可以浓缩为三步aws ecr create-repository建仓库 →./laradock ship ECR地址 --push构建并推送自包含镜像 →aws apprunner create-service --cli-input-json file://aws-app-runner.json创建服务。HTTPS、自动扩缩容与健康检查全部由 App Runner 托管你无需配置负载均衡器。这份同一镜像、多处运行的资产可以被复用到其他目标单台服务器见 deploy-to-a-server.md配合 production/compose.yml 与--profile worker --profile schedulerKubernetes 见 deploy-to-kubernetes.md其余云端目标ECS、Cloud Run、Fly、Render 等的参考配置都集中在 production/providers/ 目录下完整的部署总览参见 production.md。关于用 Laradock 搭建本地开发环境可先阅读 Intro 与 getting-started.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），仅供参考