后端前端Web框架开发工具【免费下载链接】redwoodRedwoodGraphQL项目地址https://gitcode.com/gh_mirrors/re/redwood点击查看免费下载Redwood 框架从设计之初就同时面向 serverless 与传统服务器两类基础设施并为两者提供了统一的持续部署流程。本文以 Redwood 7.x 官方部署文档为骨架系统讲解 Redwood 的部署模型、官方支持的部署目标Baremetal、Coherence、Flightcontrol、Edg.io、Netlify、Render、Serverless.com、Vercel、通用部署四要素宿主配置、构建命令、Prisma 数据库、环境变量并结合仓库源码深入说明yarn rw setup deploy与yarn rw deploy的底层实现帮助你在生产环境完成一次可复现、可维护的部署。Redwood 的部署模型一套流程两种基础设施Redwood 的部署设计独特之处在于无论你选择 serverlessNetlify、Vercel、AWS Lambda还是传统服务器Baremetal都遵循同一条持续部署链路。官方文档将其概括为四个连续步骤代码提交到 GitHub、GitLab 或 Bitbucket 仓库触发部署Redwood 的 API Side 与 Web Side 分别通过构建流程独立准备构建过程中执行所有数据库相关操作例如 Prisma migration托管平台将构建出的 Web 静态资源部署到 CDN将 API 代码部署到 serverless 后端例如 AWS Lambda。这套流程意味着Web Side 本质上是静态产物web/dist而 API Side 是可独立构建的 Node 服务。Redwood 将这两者解耦才使得同一个应用既能跑在纯 serverless 平台上也能跑在你自己的物理服务器上。从源码看这两个 CLI 命令入口分别位于yarn rw setup deploy target生成指定平台的配置入口在 packages/cli/src/commands/setup/deploy/deploy.js通过commandDir(./providers, { recurse: true })动态加载各平台生成器yarn rw deploy target执行对应平台的构建/部署流程入口在 packages/cli/src/commands/deploy.js同样按commandDir(./deploy, { recurse: false })分发到各平台实现。官方支持的部署目标截至 Redwood 7.x官方支持的部署目标如下部署目标类型说明Baremetal传统服务器你有 SSH 访问权限的物理服务器/云主机CoherencePaaS全托管部署平台Flightcontrol.devPaaS面向 AWS 的托管部署平台Edg.io边缘平台提供 CDN 与边缘计算Netlify.comServerless静态站点 函数FunctionsRender.comPaaSWeb Service 与静态站点Serverless.comServerless基于 AWS Lambda 的 serverless 框架Vercel.comServerless静态站点 Serverless Functions与这 8 个目标一一对应仓库的 CLI 中也有对应的生成器与部署实现。生成器位于 packages/cli/src/commands/setup/deploy/providers/包含baremetal.js、coherence.js、flightcontrol.js、netlify.js、render.js、serverless.js、vercel.js等部署实现位于 packages/cli/src/commands/deploy/。生成部署配置Redwood 提供了一个 CLI 生成器用于为指定平台添加所需的代码和配置yarn rw setup deploy provider例如为 Netlify 生成配置yarn rw setup deploy netlify从 netlify.js 生成器源码 可以看到这个命令实际执行了三件事调用updateApiURLTask(/.netlify/functions)把redwood.toml中的apiUrl改写为 Netlify Functions 的路径在项目根目录写入netlify.toml内容来自 templates/netlify.js输出 setup 完成提示。也就是说setup 的核心职责就是把 Redwood 项目调整成目标平台认识的样子——包括 API 路径、平台专属配置文件如netlify.toml、vercel.json、deploy.toml以及必要的依赖。官方文档同时指出除上述官方目标外社区还有在 Google Cloud、直接部署到 AWS 等平台上的实践案例可通过 GitHub Issues 与 Redwood 社区论坛检索获取更多信息。通用部署四要素无论选择哪个平台Redwood 的部署都绕不开以下四个类别的配置。1. 宿主Host特定配置每个托管平台对在哪里、以何种方式配置部署有不同的要求有时需要在仓库中加入代码有时需要在平台控制台Dashboard中配置有时两者都要。这部分必须阅读对应平台的专属文档。在所有 Redwood 配置中最重要的一个是redwood.toml中的apiUrl——它指定了 serverless 函数在你所选托管平台上的 API 路径。Web Side 的 GraphQL 客户端会以该路径作为请求的基准地址。从 packages/project-config/src/config.ts 中的默认配置可以看到web: { title: Redwood App, port: 8910, path: ./web, target: TargetEnum.BROWSER, includeEnvironmentVariables: [], apiUrl: /.redwood/functions, // 默认 API 路径 fastRefresh: true, ... }默认值/.redwood/functions是本地开发与自带 API 服务场景下的路径。而不同平台会改写这个值例如Netlify/.netlify/functionssetup 命令会自动改写见上文Vercel/api自定义 nginx Baremetal可自定义为/api等任意路径见 version-7.x 的 Baremetal 文档 中Custom API Path一节。apiUrl还支持环境变量插值与单独的 GraphQL/dbAuth 路径覆盖详见 Redwood 配置文档 中的 API Paths 部分。2. 构建命令构建命令用于将 Web 与 API 两侧打包为可部署产物同时可在构建期间执行其他动作如数据库迁移。Redwood 的构建命令必须指定一个官方支持的托管平台作为targetyarn rw deploy target各平台示例# Netlify 部署目标 yarn rw deploy netlify # Vercel 部署目标 yarn rw deploy vercel # 使用 serverless.com 框架部署 AWS Lambda仅构建 API 侧 yarn rw deploy serverless --side api # Edgio 部署目标 yarn rw deploy edgio # baremetal 部署目标首次部署加 --first-run yarn rw deploy baremetal [--first-run]注意serverless --side api这个用法它表明 Redwood 允许你只构建某一个 Side。在 deploy/netlify.js 这类平台实现中builder与handler都来自公共的 helpers/helpers.js统一处理构建、Prisma 迁移、数据迁移等子任务的编排。需要说明的是yarn rw deploy target在大多数托管平台上只是构建命令真正把产物推上平台的是平台自身的 CI/CD如 Netlify Build、Vercel Build。而 Baremetal 目标则不同——它本身就会通过 SSH 在远程服务器上执行完整的部署生命周期见下文结合源码看部署流程。3. Prisma 与数据库Redwood 使用 Prisma 管理数据库访问与迁移。api/db/schema.prisma7.x 之前是api/prisma/schema.prisma中的设置必须指向正确的生产数据库例如 PostgreSQL并包含正确的连接字符串。生产环境使用 PostgreSQL 的schema.prisma示例datasource db { provider postgresql url env(DATABASE_URL) }其中url通过环境变量DATABASE_URL获取连接字符串。官方明确推荐使用环境变量理由有二一是便于本地与生产环境切换开发流程友好二是符合安全最佳实践避免把凭据写进代码仓库。每当修改schema.prisma后必须执行yarn rw prisma migrate dev # 创建并应用一个新的 Prisma DB 迁移生产环境连接字符串注意设置生产DATABASE_URL时务必同时带上连接池connection-pooling或 sslmode 参数。例如使用 Supabase Postgres 并启用连接池时连接字符串形如postgresql://postgres:mydb.supabase.co:6432/postgres?sslmoderequirepgbouncertrue——使用特定的 6432 端口、告知 Prisma 走 pgBouncer、并强制 SSL。更详细的说明见 Connection Pooling 文档。从 Baremetal 部署源码 deploy/baremetal.js 可以看到迁移这一步在生产环境实际执行的是三个命令的组合yarn rw prisma migrate deploy—— 应用数据库迁移生产环境不使用migrate devyarn rw prisma generate—— 重新生成 Prisma Clientyarn rw dataMigrate up—— 执行 数据迁移。因此如果你在生产环境的 CI 或部署脚本中手工执行数据库步骤也应遵循这个deploy → generate → dataMigrate的次序。4. 环境变量本地使用的所有环境变量例如env.defaults或.env中的变量都必须同步添加到托管平台的环境变量设置中具体位置见各平台文档。此外如果应用在Web Side使用环境变量你需要配置 Redwood 的构建过程使其在生产环境中可用——Web Side 运行在浏览器里任何process.env.*引用都必须被显式列入白名单并内联进静态产物。具体操作见 Redwood 环境变量文档。这一机制的底层对应redwood.toml中web.includeEnvironmentVariables配置见 config.ts 默认配置。结合源码看部署流程以 Baremetal 为例虽然本文档是部署总览但透过 Baremetal 实现可以最直观地看到 Redwood 一条部署命令背后发生了什么。在 deploy/baremetal.js 中deployTasks按顺序编排了如下任务每个任务都支持before/after生命周期钩子df—— 检查远程磁盘可用空间默认阈值 2048MB可通过freeSpaceRequired调整update——git clone --branchbranch --depth1 repo releaseDir拉取最新代码symlinkEnv—— 把发布目录内的.env软链到应用根目录的共享.envinstall—— 执行yarn install包管理器命令可用packageManagerCommand自定义migrate—— 依次执行prisma migrate deploy、prisma generate、dataMigrate upbuild—— 对sides数组中的每个 Side 执行yarn rw build sidesymlinkCurrent—— 把最新发布目录软链为currentrestart—— 重启processNames中列出的 PM2 进程首次部署用--first-run时执行pm2 startpm2 savecleanup—— 清理keepReleases之外的旧发布目录。其中的serverConfigWithDefaults源码位置给出了 Baremetal 的默认配置值SSH 端口 22、默认分支main、包管理器yarn、监控工具pm2、默认构建[api, web]两个 Side、保留 5 个发布版本。这意味着如果你选择传统服务器部署deploy.toml实际上是一份服务器清单 部署剧本。完整的deploy.toml配置项说明host、port、username、password、privateKey/privateKeyPath、passphrase、agentForward、sides、packageManagerCommand、monitorCommand、path、migrate、processNames、repo、branch、keepReleases以及多服务器、多环境、自定义 before/after 命令、回滚、维护页、nginx 搭配等高级主题请直接阅读 Baremetal 部署文档。各平台部署文档速查本文档deploy 总览是部署体系的入口后续请按目标平台查阅对应深度指南Baremetal物理服务器CoherenceFlightcontrol.devEdg.ioNetlifyRender.comServerless.comAWS LambdaVercel以 Netlify 为例其专属文档 特别提醒不要用 Netlify CLI 在本机执行netlify build/netlify deploy再上传 dist 目录因为 Prisma Client 会在构建时按本机操作系统生成引擎二进制如 macOS 的darwin、Windows 的windows而 Netlify Functions 运行时需要debian-openssl-1.1.x或rhel-openssl-1.1.x这类 Linux 引擎导致函数运行失败。正确做法是让 Netlify 的云端构建系统从你的 Git 仓库拉取代码并自行构建部署。常见问题与补充建议apiUrl忘记改怎么办前端会向默认的/.redwood/functions发请求而平台并不在这个路径提供函数GraphQL 请求将 404。setup 命令会自动改写但手工改动redwood.toml后要仔细核对。迁移与构建的先后官方流程把数据库迁移放在构建之前确保新代码对应的数据库结构已就绪。若迁移失败部署应中断而非继续发布不可用版本。Web Side 环境变量缺失浏览器无法读取服务端环境变量必须通过includeEnvironmentVariables白名单机制在构建期内联否则生产环境取到undefined。首次部署 vs 日常部署Baremetal 的--first-run只用于首次启动服务并pm2 save日常部署不带该参数仅重启已有进程。参考文档完整的 CLI 命令参考见 cli-commands.md其中包含deploy与setup deploy两个命令族部署相关的配置参数见 app-configuration-redwood-toml.md。总体而言Redwood 的部署哲学是一次 build任意 target你的业务代码与数据库 schema 保持不变切换平台时只需要重跑一次yarn rw setup deploy provider、调整apiUrl与平台配置再按上文的四要素补齐宿主配置、构建命令、数据库与环境变量即可。理解了这条主线无论未来出现新的托管平台还是自建服务器你都能快速完成 Redwood 应用的上线。赞分享后端前端Web框架开发工具【免费下载链接】redwoodRedwoodGraphQL项目地址https://gitcode.com/gh_mirrors/re/redwood点击查看免费下载相关推荐Redwood 部署指南从 Serverless 到 Baremetal 的完整部署流程Redwood 部署指南从 Serverless 到 Baremetal 的完整部署流程 Redwood 框架同时支持 Serverless 与传统基础设施两后端前端Web框架开发工具RedwoodJS Baremetal 部署实战SSH 驱动的自托管部署全流程指南RedwoodJS Baremetal 部署实战SSH 驱动的自托管部署全流程指南 在基于云平台的部署方案Serverless、Lambda 等之外Re后端前端Web框架开发工具Redwood 部署指南从 Serverless 到 Baremetal 的完整上线流程Redwood 部署指南从 Serverless 到 Baremetal 的完整上线流程 Redwood 是专为前后端一体Web Side API Si后端前端Web框架开发工具上一篇3分钟掌握Open PS2 Loader让你的PS2焕发新生的完整指南下一篇3步打造你的专属游戏管家AhabAssistantLimbusCompany智能助手完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考