CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载本文围绕 Webiny 开源仓库中 docs/gh-actions-workflows/standalone/ 目录下的完整 CI/CD 示例展开讲解如何用 GitHub Actions 将 Webiny 构建成 Docker 镜像并推送到 GitHub Container RegistryGHCR再由 ECS、Cloud Run、Fly.io、Kubernetes 等容器平台拉取运行。读完本文你将掌握 standalone 托管类型下Dockerfile多阶段构建、三环境dev/staging/prod推送工作流、PR 冒烟检查、构建期与运行期环境变量的划分以及真实部署中的内存、数据库与 CORS 注意事项。一、Standalone 托管模式镜像即部署产物Webiny 提供两类 GitHub Actions 工作流示例分别对应两种托管方式AWS 托管父目录 docs/gh-actions-workflows/ 中的pushDev.yml、pushStaging.yml、pushProd.yml、pullRequest.yml、pullRequestClosed.yml。它们通过yarn webiny deploy --env dev调用 Pulumi 在 AWS 上预置 Lambda、DynamoDB、S3 等基础设施见 pushDev.yml是「基础设施即代码」的部署模式。Standalone 托管即本文主题——standalone/ 目录下的全部示例。它不预置任何云基础设施而是把构建产物打包成 Docker 镜像推送到镜像仓库由你自己的容器平台负责拉取和运行。两者的核心区别在于部署产物的形态AWS 模式下webiny deploy在 CI 中直接编排云资源standalone 模式下Docker 镜像本身就是唯一的部署产物——服务器端永远不会执行yarn install或webiny build所有构建都发生在 CI 的容器内部。整个发布模型可以概括为git push → GitHub Actions → docker build内部运行 webiny build→ push 镜像到 GHCR → 平台拉取并运行二、目录文件清单与部署位置standalone/ 目录共 7 个文件使用时需要复制到项目的不同位置文件复制到用途Dockerfile项目根目录多阶段构建产出apiNode运行node start.mjs与adminnginx 静态站点两个镜像nginx-spa.conf项目根目录Admin 镜像的 nginx 配置——SPA 回退避免深层链接/硬刷新 404pushDev.yml / pushStaging.yml / pushProd.yml.github/workflows/推送dev/staging/prod分支时构建并推送按环境打标签的api和admin镜像pullRequest.yml.github/workflows/PR 时静态分析 仅构建的冒烟检查值得注意的是standalone 模式没有「pull request closed」工作流。原因在于PR 不会创建任何基础设施也就不存在需要部署或销毁的临时环境对比 AWS 模式下的pullRequestClosed.yml。因此 PR 检查只做两件事代码质量把关 验证镜像仍能构建成功。三、多阶段 Dockerfile一次构建双镜像产出Dockerfile 采用标准多阶段结构开头的# syntaxdocker/dockerfile:1声明启用了较新的 Dockerfile 语法。它包含三个阶段builder产出自包含的 build 产物FROM node:24-bookworm AS builder WORKDIR /project ENV WEBINY_HOSTING_TYPEstandalone NODE_ENVproduction COPY . . RUN corepack enable yarn install --immutable # Admin 包在构建期烘焙 API 地址——真实主机请覆盖 # docker build --target admin --build-arg WEBINY_API_URLhttps://api.example.com ... ARG WEBINY_API_URLhttp://localhost:3002 ENV WEBINY_API_URL$WEBINY_API_URL RUN yarn webiny build api yarn webiny build admin要点基于node:24-bookworm与工作流中actions/setup-node的node-version: 24保持一致通过corepack enable启用 Yarn以--immutable严格安装依赖与 CI 中yarn --immutable行为一致设置WEBINY_HOSTING_TYPEstandalone让webiny build产出 standalone 自包含产物yarn webiny build api yarn webiny build admin一次性构建后端 API 与前端 Admin 两个应用。api自包含处理器的精简运行镜像FROM node:24-bookworm-slim AS api WORKDIR /app COPY --frombuilder /project/.webiny/workspace/apps/api/graphql/build ./ ENV PORT3002 EXPOSE 3002 CMD [node, start.mjs]API 镜像只包含构建产物start.mjs入口体积精简数据库、存储和密钥全部在运行期注入绝不烘焙进镜像。这是镜像与部署环境解耦的关键设计——同一个镜像可以在 dev/staging/prod 三套环境复用仅环境变量不同。admin由 nginx 托管的静态资源镜像FROM nginx:alpine AS admin COPY --frombuilder /project/.webiny/workspace/apps/admin/build /usr/share/nginx/html COPY nginx-spa.conf /etc/nginx/conf.d/default.conf EXPOSE 80Admin 是纯静态 SPA用nginx:alpine作为宿主nginx-spa.conf覆盖默认站点配置。如果只想构建其中一个镜像可用--target指定阶段docker build --target api . docker build --target admin --build-arg WEBINY_API_URLhttps://api.example.com .nginx SPA 回退配置nginx-spa.conf 的核心只有一段server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } }try_files $uri $uri/ /index.html正是 SPA 回退文件存在则直接返回否则一律回退到index.html。这样用户在浏览器里直接刷新/cms/content-entries这类客户端路由时nginx 会把请求交给前端应用处理而不是返回 404。没有这段配置Admin 的深层链接硬刷新就会白屏报错。四、镜像仓库GHCR 与 GITHUB_TOKEN示例默认推送目标为GitHub Container Registryghcr.io镜像地址规则为ghcr.io/owner/repo/api:envghcr.io/owner/repo/admin:env登录环节复用 GitHub 自动注入的GITHUB_TOKEN因此不需要额外配置任何密钥。唯一的权限要求是工作流permissions块必须显式声明packages: writeGitHub Actions 的 token 默认只有contents: readpermissions: contents: read packages: write # 允许向 GitHub Container Registry (ghcr.io) 推送镜像推送到 GHCR 后从宿主机拉取镜像有两种途径将包设为public保持 private并给宿主机配置一个带read:packages权限的 token。若想改用 Docker Hub、AWS ECR 等其他仓库只需替换工作流中的registry与tags即可无需改动 Dockerfile。五、配置构建期密钥与运行期环境变量standalone 模式对配置做了严格的「构建期 / 运行期」划分这也是镜像可复用的基础。构建期GitHub Secrets每个环境一个Admin 包会在构建期把 API 地址烘焙进前端 bundle浏览器运行时才知道去请求哪个后端。因此在 GitHub 仓库 Settings → Secrets 中按环境配置Secret 名用途DEV_WEBINY_API_URLdev 环境公网 API 地址STAGING_WEBINY_API_URLstaging 环境公网 API 地址PROD_WEBINY_API_URLprod 环境公网 API 地址它们在推送工作流中通过build-args传入 Docker 构建最终覆盖 Dockerfile 里WEBINY_API_URL的默认值http://localhost:3002- name: Build push Admin image # Admin 在构建期烘焙公网 API 地址 uses: docker/build-push-actionv6 with: context: . target: admin platforms: linux/amd64 push: true tags: ghcr.io/${{ github.repository }}/admin:prod build-args: | WEBINY_API_URL${{ secrets.PROD_WEBINY_API_URL }}运行期容器平台环境变量CI 不参与以下变量在容器平台上配置而不是放在 CI 里——同一镜像跑在三个环境只有这些值随部署变化数据库二选一SQLiteWEBINY_SQL_FILENAME——指向持久卷上的数据库文件PostgresWEBINY_PG_HOST、WEBINY_PG_PORT、WEBINY_PG_USER、WEBINY_PG_PASSWORD、WEBINY_PG_DATABASE。密钥必须从开发默认值改掉WEBINY_UPLOAD_SECRET——文件上传加密/签名密钥WEBINY_SELF_HOSTED_AUTH_SECRET——自托管认证会话密钥。WCP 许可证WEBINY_PROJECT_ID、WEBINY_PROJECT_API_KEY——Webiny 商业平台WCP的许可证凭据。从源码结构看这些环境变量由packages/下的 standalone 相关包如project-standalone、self-hosted-auth、db等在运行时读取分别驱动 SQLite/Postgres 数据源、上传签名与认证加密逻辑具体取值含义与开发默认值可在对应包的源码与 example.env 中核对。六、推送工作流dev / staging / prod 三环境三个推送工作流pushDev.yml、pushStaging.yml、pushProd.yml结构完全一致仅分支、并发键、镜像标签和 API URL Secret 不同。以pushProd.yml为例name: Prod Branch - Push (standalone) on: push: branches: [prod] # 保证同一时刻只有一个 prod 环境的构建推送在运行。 concurrency: prod jobs: build-and-push: name: Build and push images runs-on: ubuntu-latest permissions: contents: read packages: write # 向 GitHub Container Registry (ghcr.io) 推送镜像 env: NODE_OPTIONS: --max_old_space_size4096 steps: - uses: actions/checkoutv5 - uses: actions/setup-nodev5 with: node-version: 24 # 安装并缓存依赖供下面的静态分析使用。 - uses: actions/cachev4 id: yarn-cache with: path: .yarn/cache key: yarn-${{ hashFiles(**/yarn.lock) }} - name: Install dependencies run: yarn --immutable # 静态代码分析。 - name: Check code formatting run: yarn format - name: Lint run: yarn lint # 构建并推送自包含镜像。多阶段 Dockerfile 会在构建过程内部执行 # yarn webiny build因此这里不需要单独的构建步骤。 - name: Log in to GHCR uses: docker/login-actionv3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - uses: docker/setup-buildx-actionv3 - name: Build push API image uses: docker/build-push-actionv6 with: context: . target: api platforms: linux/amd64 push: true tags: ghcr.io/${{ github.repository }}/api:prod - name: Build push Admin image uses: docker/build-push-actionv6 with: context: . target: admin platforms: linux/amd64 push: true tags: ghcr.io/${{ github.repository }}/admin:prod build-args: | WEBINY_API_URL${{ secrets.PROD_WEBINY_API_URL }}执行流程分三段静态分析前置actions/checkoutv5拉取代码 →actions/setup-nodev5Node 24→actions/cachev4缓存.yarn/cachekey 基于yarn.lock哈希依赖不变即命中缓存→yarn --immutable安装 →yarn formatyarn lint把关登录与构建环境docker/login-actionv3用github.actorGITHUB_TOKEN登录 GHCRdocker/setup-buildx-actionv3启用 BuildxBuildKit构建并推送docker/build-push-actionv6分别以target: api和target: admin构建platforms: linux/amd64锁定平台push: true直接推送标签含环境名。dev / staging 两套工作流仅将分支改为dev/staging、标签改为:dev/:stagingAdmin 镜像的build-args对应改为DEV_WEBINY_API_URL/STAGING_WEBINY_API_URL其余逻辑完全相同。七、PR 工作流静态分析 构建冒烟检查pullRequest.yml 在pull_request到dev分支时触发包含两个串行 jobon: pull_request: branches: [dev] jobs: build-test-static: name: Build and run static analysis runs-on: ubuntu-latest steps: # checkout / setup-node / cache / yarn --immutable / yarn format / yarn lint # 与推送工作流相同 build-images: name: Verify Docker images build needs: build-test-static runs-on: ubuntu-latest steps: - uses: actions/checkoutv5 - uses: docker/setup-buildx-actionv3 # 构建两个镜像但不推送——冒烟检查部署产物仍能构建。 - name: Build API image uses: docker/build-push-actionv6 with: context: . target: api push: false - name: Build Admin image uses: docker/build-push-actionv6 with: context: . target: admin push: falsebuild-test-static先做格式化检查与 lintbuild-images通过needs依赖前者用push: false把 api 与 admin 各构建一遍确认改动后镜像仍可产出但不推送、不产生任何基础设施。由于 standalone PR 不创建任何基础设施所以不需要为 PR 单独部署环境也就不存在「PR 关闭时销毁环境」的对应工作流——这正是 standalone 与 AWS 模式需配套pullRequestClosed.yml在工作流数量上的差异。八、部署的最后一步让平台拉取新镜像三个推送工作流在构建推送之后都以注释形式预留了平台特定的「通知平台拉取新镜像」步骤文件末尾的注释给出了四种主流平台的命令# - AWS ECS/Fargate: aws ecs update-service --cluster c --service s --force-new-deployment # - Google Cloud Run: gcloud run deploy webiny-api --image ghcr.io/${{ github.repository }}/api:prod # - Fly.io: flyctl deploy --image ghcr.io/${{ github.repository }}/api:prod # - Kubernetes: kubectl set image deployment/webiny-api apighcr.io/${{ github.repository }}/api:prod使用时按需取消注释并替换占位符。也可以走更省事的路线使用Render、Railway这类监听仓库变更、自动拉取新镜像的平台CI 推送完成后无需任何额外步骤。九、真实部署经验内存、数据库与 CORS文档最后总结了来自真实部署的三条关键经验直接影响生产可用性内存API 容器至少要给 512 MB 以上Webiny API 并不「轻量」容器内存配置建议≥ 512 MB1 GB 更舒适。内存低于约 256 MB 时会发生 swap请求会明显变慢甚至爬行。由于工作流中没有显式设置容器内存这一步需要在容器平台的部署配置中完成。SQLite vs Postgres单节点 vs 多实例SQLite 持久卷是最简单的单节点方案数据与上传文件在容器重启后都能保留但持久卷会把应用钉在一台机器上无法水平扩展。**Postgres共享数据库**面向多实例 / 高可用场景数据库独立于应用节点无需为数据库挂卷任何实例都能访问同一份数据。选择依据很直接只有单实例就选 SQLite 省事要跑多个副本、做 HA 就上 Postgres。Admin 是「静态 跨域」架构Admin 镜像由 nginx 提供静态文件API 跑在独立容器默认端口 3002二者天然是跨域关系因此API 必须开启 CORS允许 Admin 的来源访问否则浏览器会拦截 Admin 发出的 API 请求nginx 的 SPA 回退nginx-spa.conf中的try_files负责兜底客户端路由的硬刷新二者缺一不可。十、总结Webiny standalone 托管模式的 CI/CD 可以浓缩为三条原则镜像即产物Dockerfile多阶段构建在 CI 内完成全部webiny build服务器只负责node start.mjsAPI与 nginx 托管静态文件Admin配置分层API 地址等构建期参数通过 GitHub Secrets build-args烘焙进 Admin 镜像数据库、密钥、许可证等运行期参数由容器平台注入环境变量同一个镜像三环境复用环境隔离dev/staging/prod 三分支 → 三工作流 → 三套标签:dev/:staging/:prodPR 只做静态分析与构建冒烟不产生任何临时基础设施。整套示例文件均可直接查阅 docs/gh-actions-workflows/standalone/将其中的 Dockerfile、nginx 配置与工作流复制到你的项目对应位置替换平台相关命令后即可投入使用。赞分享CMS后端前端【免费下载链接】webiny-jsOpen-source, self-hosted CMS platform on AWS serverless (Lambda, DynamoDB, S3). TypeScript framework with multi-tenancy, lifecycle hooks, GraphQL API, and AI-assisted development via MCP server. Built for developers at large organizations.项目地址https://gitcode.com/gh_mirrors/we/webiny-js点击查看免费下载相关推荐Gitea Actions自托管CI/CD实战Gitea Actions自托管CI/CD实战 痛点与承诺 还在为CI/CD持续集成/持续部署服务的高昂费用和网络延迟烦恼吗还在担心代码安全性和数据隐私后端代码托管版本控制研发协作代码评审缺陷追踪项目管理CI/CD如何快速上手CANN SHMEM开发MoE算子dispatch/combine与MegaMoE通算融合实战指南如何快速上手CANN SHMEM开发MoE算子dispatch/combine与MegaMoE通算融合实战指南 想开发高效 MoE混合专家算子CA通信高性能计算CANNAscendGitea Actions自托管CI/CD解决方案Gitea Actions自托管CI/CD解决方案 Gitea Actions是一个基于事件驱动的自托管CI/CD解决方案采用现代化分布式架构设计完美融合后端代码托管研发协作CI/CD上一篇cnpy 项目安装和配置指南下一篇Ink Kit国际化多语言支持与全球市场的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考