尧图网站建设 
Wasp v0.14 部署体系详解三部分全栈应用的部署路径与 Dockerfile 自定义机制【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/waspWasp 应用是一个由 Node.js 服务器、静态客户端和 PostgreSQL 数据库组成的全栈应用其各部分可以独立部署到任意支持 Node.js 或静态站点托管的环境。本文基于 Wasp v0.14 部署概览文档完整梳理两条部署路径Wasp CLI 单命令部署与手动部署背后的架构约束并结合 waspc 编译器源码深入讲解 Wasp 生成 Dockerfile 的多阶段构建结构、用户 Dockerfile 追加到底部的扩展机制以及用wasp dockerfile命令检查最终产物的方式帮助你在理解部署全貌的基础上安全地定制构建过程。Wasp 应用的部署目标三个独立部件理解 Wasp 部署的第一步是明确它的产物由哪几部分组成。根据 部署概览文档Wasp 应用是一个全栈应用包含以下三个部分Node.js 服务器API 后端静态客户端构建后的一堆静态文件PostgreSQL 数据库。由于这三个部分都是业界最常见的部署形态你可以把每一部分部署到任何通常能部署 Node.js 应用或静态应用的地方。也就是说Wasp 并不强制要求三个部件部署在同一平台例如客户端可以放在静态托管服务上、服务器放在容器托管平台上、数据库放在托管 PostgreSQL 服务上三者通过环境变量如DATABASE_URL、WASP_WEB_CLIENT_URL互相连接。这一部件可分离的特性是后续所有部署选项无论单命令还是手动的基础。两条部署路径Wasp CLI 与手动部署概览文档通过一个部署方式选项网格源码见 DeploymentOptionsGrid.tsx给出了两种部署路径部署方式说明详细文档使用 Wasp CLI一条命令完成部署与重新部署Deploying with the Wasp CLI手动部署自己构建应用并部署Deploying Manually为了让部署过程尽可能顺滑Wasp 通过Wasp CLI提供了单命令部署能力launch命令会依次执行setup、create-db和deploy一次完成在托管平台上的应用创建、数据库创建与应用发布。而手动部署路径则把上述自动化步骤拆开先执行wasp build在.wasp/build/目录生成可部署代码服务器侧为一份 Dockerfile客户端侧为可进一步构建的 web-app然后分别将服务器镜像、客户端静态产物和 PostgreSQL 部署到你选择的平台。无论选择哪条路径概览文档都强调你需要了解下面这些通用模式——尤其是最核心的 Dockerfile 自定义机制。默认的多阶段 DockerfileWasp 如何构建服务器镜像Wasp 默认会生成一份多阶段multi-stageDockerfile用于构建并运行包含 Wasp 生成服务器代码的 Docker 镜像同时执行所有待执行的数据库迁移。当前仓库中可直接查看这份模板Dockerfile 模板。它以node:nodeVersion-alpine为基底并拆分为几个命名构建阶段stagebase在 node 基础镜像上应用安全补丁并安装构建/运行时所需的系统依赖如 Prisma 原生引擎需要的 opensslserver-builder完整构建阶段——拷贝src、package.json、生成代码.wasp/out/server、.wasp/out/sdk等执行npm install在启用 Prisma 时执行prisma generate最后运行npm run bundle完成服务器打包server-production生产阶段——从base重新开始只从server-builder拷贝构建产物bundle、必要的node_modules、db/迁移文件等设置NODE_ENVproductionEXPOSE ${PORT}并以ENTRYPOINT [npm, run, start-production]作为入口。这种拆分的好处正如模板注释所述builder 阶段完成所有构建工作production 阶段另起炉灶只拷贝所需产物避免把构建时的中间产物和环境污染带入生产镜像。生成内容是动态的从源码看Dockerfile 并非静态文本。DockerGenerator.hs 中的genDockerfile会向模板注入四类动态数据usingPrisma由hasEntities spec决定控制是否包含 Prisma 客户端生成prisma generate步骤nodeVersion取自getLowestNodeVersionUserAllows spec即用户在 AppSpec 中允许使用的最低 Node 版本dbSchemaFileFromServerDirPrisma schema 相对服务器目录的路径userDockerfile项目根目录下用户自定义 Dockerfile 的内容若存在详见下一节。这也解释了概览文档中的一条重要提醒生成的 Dockerfile 内容是动态的取决于你的应用使用了哪些功能而且可能在未来版本中变化因此建议定期核对。自定义 Dockerfile追加到底部的扩展机制这是概览文档的核心能力你可以通过在项目根目录创建自己的Dockerfile来给默认多阶段 Dockerfile 添加额外步骤。工作原理当 Wasp 在项目根目录发现Dockerfile时会把它的内容追加到默认多阶段 Dockerfile 的底部。这一行为在编译器源码中有清晰对应的调用链项目分析阶段Analyze.hs 调用 Deployment.hs 中的loadUserDockerfileContents检查项目根目录是否存在Dockerfile并读取其内容存入 AppSpec 的userDockerfileContents字段定义见 AppSpec.hs生成阶段genDockerfile将该内容不存在时为空字符串作为userDockerfile模板变量注入模板最后一行即为占位符# Any user-defined Dockerfile contents will be appended below.之后紧跟{ userDockerfile }见 Dockerfile 模板 末尾。利用后定义者胜出规则做覆盖或延续由于 Dockerfile 中最后一条指令/定义生效且你的内容位于整个文件末尾你可以覆盖已有的构建阶段例如重新定义server-production来替换基础镜像从现有阶段延续例如FROM server-builder AS my-stage接着加自己的层完全弃用 Wasp 的构建阶段写一份自己的最终镜像定义让最终镜像完全由你控制。概览文档同时给出了三条必须记住的注意事项如果你覆盖了某个中间构建阶段其后依赖该阶段的后续构建阶段将失效除非你在下方重新复现它们Docker 的 stage 依赖是单向引用被覆盖后引用者拿到的就是新版本生成内容是动态的且可能随版本变化——你针对某个版本的 stage 名字写的覆盖升级 Wasp 后需重新验证务必在最终构建阶段提供ENTRYPOINT。如果你定义了自定义的最终阶段却没有设置入口应用将无法按预期启动你的改动也不会产生实际效果。概览文档建议读者结合 Docker 官方文档关于 multi-stage builds 的说明来理解这些规则此处不再列出外部链接。用wasp dockerfile查看最终合并结果自定义 Dockerfile 最大的不确定性在于追加之后最终文件长什么样Wasp 提供了专门的命令来消除这种不确定性wasp dockerfile该命令会编译并渲染出你项目实际的可能已合并用户内容的Dockerfile并打印到终端供你核对。从源码看其实现CLI 侧 Dockerfile.hs 中的printDockerfile先要求处于 Wasp 项目内且 AppSpec 可用然后调用 DockerGenerator.hs 中的compileAndRenderDockerfile——它复用与真实构建完全相同的genDockerfile生成逻辑渲染模板因此打印出的内容与wasp build实际写入构建目录的 Dockerfile 一致若项目编译有错命令会明确报告 Displaying Dockerfile failed due to a compilation error in your Wasp project而不是输出错误的产物。推荐的调试流程是在项目根目录写好自定义Dockerfile→ 运行wasp dockerfile确认合并结果与 stage 依赖关系符合预期 → 再执行构建/部署。小结Wasp v0.14 的部署概览可以归纳为三层认知架构层一个 Wasp 应用 Node.js 服务器 静态客户端 PostgreSQL三者可分别部署到任意对应形态的托管环境路径层Wasp CLI 提供launch/setup/create-db/deploy组成的单命令部署链路手动路径则是wasp build之后自行部署服务器镜像、客户端静态产物与数据库定制层默认的多阶段 Dockerfilebase/server-builder/server-production支持在项目根目录放置自定义Dockerfile其内容被追加到文件底部借助 Docker后定义者胜出规则实现覆盖或延续前提是保持最终阶段的ENTRYPOINT任何定制都应先用wasp dockerfile验证最终合并产物。深入实现可参考 Dockerfile 模板、Deployment.hs、DockerGenerator.hs 以及 CLI 命令实现完整部署操作细节则见同目录下的 CLI 部署文档 与 手动部署文档。【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wasp v0.14 部署体系详解：三部分全栈应用的部署路径与 Dockerfile 自定义机制
Wasp v0.14 部署体系详解三部分全栈应用的部署路径与 Dockerfile 自定义机制【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/waspWasp 应用是一个由 Node.js 服务器、静态客户端和 PostgreSQL 数据库组成的全栈应用其各部分可以独立部署到任意支持 Node.js 或静态站点托管的环境。本文基于 Wasp v0.14 部署概览文档完整梳理两条部署路径Wasp CLI 单命令部署与手动部署背后的架构约束并结合 waspc 编译器源码深入讲解 Wasp 生成 Dockerfile 的多阶段构建结构、用户 Dockerfile 追加到底部的扩展机制以及用wasp dockerfile命令检查最终产物的方式帮助你在理解部署全貌的基础上安全地定制构建过程。Wasp 应用的部署目标三个独立部件理解 Wasp 部署的第一步是明确它的产物由哪几部分组成。根据 部署概览文档Wasp 应用是一个全栈应用包含以下三个部分Node.js 服务器API 后端静态客户端构建后的一堆静态文件PostgreSQL 数据库。由于这三个部分都是业界最常见的部署形态你可以把每一部分部署到任何通常能部署 Node.js 应用或静态应用的地方。也就是说Wasp 并不强制要求三个部件部署在同一平台例如客户端可以放在静态托管服务上、服务器放在容器托管平台上、数据库放在托管 PostgreSQL 服务上三者通过环境变量如DATABASE_URL、WASP_WEB_CLIENT_URL互相连接。这一部件可分离的特性是后续所有部署选项无论单命令还是手动的基础。两条部署路径Wasp CLI 与手动部署概览文档通过一个部署方式选项网格源码见 DeploymentOptionsGrid.tsx给出了两种部署路径部署方式说明详细文档使用 Wasp CLI一条命令完成部署与重新部署Deploying with the Wasp CLI手动部署自己构建应用并部署Deploying Manually为了让部署过程尽可能顺滑Wasp 通过Wasp CLI提供了单命令部署能力launch命令会依次执行setup、create-db和deploy一次完成在托管平台上的应用创建、数据库创建与应用发布。而手动部署路径则把上述自动化步骤拆开先执行wasp build在.wasp/build/目录生成可部署代码服务器侧为一份 Dockerfile客户端侧为可进一步构建的 web-app然后分别将服务器镜像、客户端静态产物和 PostgreSQL 部署到你选择的平台。无论选择哪条路径概览文档都强调你需要了解下面这些通用模式——尤其是最核心的 Dockerfile 自定义机制。默认的多阶段 DockerfileWasp 如何构建服务器镜像Wasp 默认会生成一份多阶段multi-stageDockerfile用于构建并运行包含 Wasp 生成服务器代码的 Docker 镜像同时执行所有待执行的数据库迁移。当前仓库中可直接查看这份模板Dockerfile 模板。它以node:nodeVersion-alpine为基底并拆分为几个命名构建阶段stagebase在 node 基础镜像上应用安全补丁并安装构建/运行时所需的系统依赖如 Prisma 原生引擎需要的 opensslserver-builder完整构建阶段——拷贝src、package.json、生成代码.wasp/out/server、.wasp/out/sdk等执行npm install在启用 Prisma 时执行prisma generate最后运行npm run bundle完成服务器打包server-production生产阶段——从base重新开始只从server-builder拷贝构建产物bundle、必要的node_modules、db/迁移文件等设置NODE_ENVproductionEXPOSE ${PORT}并以ENTRYPOINT [npm, run, start-production]作为入口。这种拆分的好处正如模板注释所述builder 阶段完成所有构建工作production 阶段另起炉灶只拷贝所需产物避免把构建时的中间产物和环境污染带入生产镜像。生成内容是动态的从源码看Dockerfile 并非静态文本。DockerGenerator.hs 中的genDockerfile会向模板注入四类动态数据usingPrisma由hasEntities spec决定控制是否包含 Prisma 客户端生成prisma generate步骤nodeVersion取自getLowestNodeVersionUserAllows spec即用户在 AppSpec 中允许使用的最低 Node 版本dbSchemaFileFromServerDirPrisma schema 相对服务器目录的路径userDockerfile项目根目录下用户自定义 Dockerfile 的内容若存在详见下一节。这也解释了概览文档中的一条重要提醒生成的 Dockerfile 内容是动态的取决于你的应用使用了哪些功能而且可能在未来版本中变化因此建议定期核对。自定义 Dockerfile追加到底部的扩展机制这是概览文档的核心能力你可以通过在项目根目录创建自己的Dockerfile来给默认多阶段 Dockerfile 添加额外步骤。工作原理当 Wasp 在项目根目录发现Dockerfile时会把它的内容追加到默认多阶段 Dockerfile 的底部。这一行为在编译器源码中有清晰对应的调用链项目分析阶段Analyze.hs 调用 Deployment.hs 中的loadUserDockerfileContents检查项目根目录是否存在Dockerfile并读取其内容存入 AppSpec 的userDockerfileContents字段定义见 AppSpec.hs生成阶段genDockerfile将该内容不存在时为空字符串作为userDockerfile模板变量注入模板最后一行即为占位符# Any user-defined Dockerfile contents will be appended below.之后紧跟{ userDockerfile }见 Dockerfile 模板 末尾。利用后定义者胜出规则做覆盖或延续由于 Dockerfile 中最后一条指令/定义生效且你的内容位于整个文件末尾你可以覆盖已有的构建阶段例如重新定义server-production来替换基础镜像从现有阶段延续例如FROM server-builder AS my-stage接着加自己的层完全弃用 Wasp 的构建阶段写一份自己的最终镜像定义让最终镜像完全由你控制。概览文档同时给出了三条必须记住的注意事项如果你覆盖了某个中间构建阶段其后依赖该阶段的后续构建阶段将失效除非你在下方重新复现它们Docker 的 stage 依赖是单向引用被覆盖后引用者拿到的就是新版本生成内容是动态的且可能随版本变化——你针对某个版本的 stage 名字写的覆盖升级 Wasp 后需重新验证务必在最终构建阶段提供ENTRYPOINT。如果你定义了自定义的最终阶段却没有设置入口应用将无法按预期启动你的改动也不会产生实际效果。概览文档建议读者结合 Docker 官方文档关于 multi-stage builds 的说明来理解这些规则此处不再列出外部链接。用wasp dockerfile查看最终合并结果自定义 Dockerfile 最大的不确定性在于追加之后最终文件长什么样Wasp 提供了专门的命令来消除这种不确定性wasp dockerfile该命令会编译并渲染出你项目实际的可能已合并用户内容的Dockerfile并打印到终端供你核对。从源码看其实现CLI 侧 Dockerfile.hs 中的printDockerfile先要求处于 Wasp 项目内且 AppSpec 可用然后调用 DockerGenerator.hs 中的compileAndRenderDockerfile——它复用与真实构建完全相同的genDockerfile生成逻辑渲染模板因此打印出的内容与wasp build实际写入构建目录的 Dockerfile 一致若项目编译有错命令会明确报告 Displaying Dockerfile failed due to a compilation error in your Wasp project而不是输出错误的产物。推荐的调试流程是在项目根目录写好自定义Dockerfile→ 运行wasp dockerfile确认合并结果与 stage 依赖关系符合预期 → 再执行构建/部署。小结Wasp v0.14 的部署概览可以归纳为三层认知架构层一个 Wasp 应用 Node.js 服务器 静态客户端 PostgreSQL三者可分别部署到任意对应形态的托管环境路径层Wasp CLI 提供launch/setup/create-db/deploy组成的单命令部署链路手动路径则是wasp build之后自行部署服务器镜像、客户端静态产物与数据库定制层默认的多阶段 Dockerfilebase/server-builder/server-production支持在项目根目录放置自定义Dockerfile其内容被追加到文件底部借助 Docker后定义者胜出规则实现覆盖或延续前提是保持最终阶段的ENTRYPOINT任何定制都应先用wasp dockerfile验证最终合并产物。深入实现可参考 Dockerfile 模板、Deployment.hs、DockerGenerator.hs 以及 CLI 命令实现完整部署操作细节则见同目录下的 CLI 部署文档 与 手动部署文档。【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考