★ FEATURED ARTICLE DevOps云原生运维【免费下载链接】caproverScalable PaaS (automated Dockernginx) - aka Heroku on Steroids项目地址https://gitcode.com/gh_mirrors/ca/caprover点击查看免费下载本指南以 CapRover 仓库中 captain-sample-apps/readme.md 为核心逐一拆解仓库内置的 9 个示例应用Node、PHP、Python/Django、Ruby/Rack、Angular、React、ASP.NET、Go、NginxPHP 高级组合并重点深入讲解每个示例背后最关键的captain-definition文件——这是 CapRover 判断如何构建并运行你的应用的唯一入口。读完本文你将掌握dockerfilePath、dockerfileLines、templateId、imageName四种构建声明方式各自的适用场景、底层校验逻辑对应 ImageMaker.ts 源码并能据此为自己的项目编写出第一个可运行的captain-definition。一、Sample Apps 是什么官方内置的快速试玩包CapRover 仓库的 captain-sample-apps 目录存放了一批开箱即用的示例应用目的是让开发者在不搭建复杂环境的前提下快速体验 CapRover 提供的核心能力。按照 readme.md 的说明它的定位是一批用于quickly try out functionality that CapRover gives you的示例应用而阅读这些示例时最值得关注的就是每个项目根目录下的captain-definition文件。当前仓库中实际提供 9 个应用归档tar 包归档文件技术栈核心看点node.tarNode.js (Express/EJS)使用templateId声明构建php.tarPHP (Stylish Portfolio 静态页)使用templateId声明构建python-django.tarPython Django使用templateId声明构建ruby-rack.tarRuby Rack (Sinatra 风格)使用templateId声明构建angular-via-caprover.tarAngular Nginx多阶段 Dockerfile 自定义 Nginx 配置react-via-caprover.tarReact Nginx多阶段 Dockerfile 自定义 Nginx 配置asp_dot_net.tarASP.NET Core 2.0官方 dotnet 多阶段构建go-sample.tarGo 1.19现代 Go 多阶段构建未附带 captain-definitionnginx-php-advanced.tarNginx PHP (webdevops 镜像)使用dockerfileLines内联声明构建这些 tar 包内各自包含一个完整的最小可运行项目源码、依赖清单、Dockerfile、captain-definition解压后即可作为新应用的起点。示例通过展示不同的captain-definition写法覆盖了 CapRover 构建系统的全部主流声明方式——这正是阅读本目录的核心价值。二、captain-definitionCapRover 的构建指令书captain-definition是位于应用仓库根目录的 JSON 文件无扩展名CapRover 在拉取你的代码后第一件事就是解析这个文件来决定如何产出可运行镜像。它的结构在源码 ICaptainDefinition.ts 中有明确定义export interface ICaptainDefinition { schemaVersion: number dockerfileLines?: string[] dockerfilePath?: string imageName?: string templateId?: string }五个字段含义如下字段类型作用示例值schemaVersionnumber配置格式版本号当前示例统一为22dockerfileLinesstring[]以字符串数组形式内联 Dockerfile 指令无需单独 Dockerfile 文件[FROM webdevops/php-nginx:alpine-php5, COPY ./app /app]dockerfilePathstring指向仓库内已有的 Dockerfile 文件路径如./Dockerfile./DockerfileimageNamestring直接指定一个已构建好的镜像名CapRover 只负责拉取、不执行任何构建nginx:1.13.9-alpinetemplateIdstring引用 CapRover 内置的构建模板对应 dockerfiles 目录下的模板文件node/8.7.0四个构建来源的四选一强制约束从源码可以确认dockerfileLines、dockerfilePath、templateId、imageName这四项是互斥的每次构建只能声明其中一种镜像来源。在 ImageMaker.ts 中CapRover 会统计同时出现的来源数量并给出明确报错One, and only one, of these properties should be present in captain-definition: templateId, imageName, dockerfilePath, or, dockerfileLines随后按优先级依次处理若提供了templateId则按模板生成 Dockerfile否则若有dockerfileLines将数组逐行用换行符拼接join(\n)作为 Dockerfile 内容否则若有dockerfilePath读取该路径对应的文件源码中还校验了dockerfilePath不得以..开头指向父目录即不允许引用仓库之外的路径见 ImageMaker.ts否则若有imageName则跳过整个构建流程直接拉取指定镜像构建日志中会明确提示 An explicit image name was provided... no build process is needed见 ImageMaker.ts。也就是说captain-definition的存在让如何构建这件事完全由开发者掌控可以用现成模板、可以用仓库内的 Dockerfile、可以直接内联几行 Dockerfile 指令、也可以干脆发布一个预构建镜像让 CapRover 只负责运行。三、templateId 方式四个内置语言模板示例templateId是最省事的声明方式。仓库中 4 个语言类示例都采用它node.tar 内captain-definition{ schemaVersion :2 , templateId :node/8.7.0 }php.tar 内captain-definition{ schemaVersion :2 , templateId :php/7.1.10 }python-django.tar 内captain-definition{ schemaVersion :2 , templateId :python-django/3.6.3 }ruby-rack.tar 内captain-definition{ schemaVersion :2 , templateId: ruby-rack/2.4.3 }templateId由技术栈/版本两部分组成。它对应的模板 Dockerfile 存放在仓库 dockerfiles 目录模板文件本身无扩展名例如dockerfiles/nodeAlpine 基础镜像 → 安装 git → 复制package.json→npm install --production→ 复制全部源码 → 设置NODE_ENVproduction、PORT80→ 以npm start启动。模板首行注释# FROM node:14-alpine提示你若不想用模板可自行改用 Dockerfile 方式。dockerfiles/php默认以php:7.3-apache为底座同样以注释形式给出直接复制全部文件到/var/www/html/并清理.git目录适合纯 PHP 静态站点或传统 ApachePHP 应用。dockerfiles/python-djangoAlpine make g bash git openssh postgresql-dev curl等编译依赖 → 先复制requirements.txt并pip install→ 复制源码 →EXPOSE 80→ 以python manage.py runserver 0.0.0.0:80运行。dockerfiles/ruby-rackAlpine make g git postgresql-dev→ 复制Gemfile并bundle install→ 复制源码 →RACK_ENVproduction→ 以rackup config.ru --host 0.0.0.0 --port 80启动。可见 templateId 模式的共同规律是CapRover 按模板替你把安装依赖 → 复制代码 → 设定运行命令全部标准化你只需要保证仓库根目录包含模板所要求的文件如package.json、requirements.txt、Gemfile、manage.py。注意示例中 templateId 携带的版本号如node/8.7.0、python-django/3.6.3是编写示例时的版本快照而当前仓库 dockerfiles 目录中的模板已随项目演进更新如 node 注释指向node:14-alpine、python-django 指向python:3.8.3-alpine、ruby-rack 指向ruby:2.7.1-alpine实际部署时应以你部署版本所内置的模板为准。四、dockerfilePath 方式前端 SPA 的多阶段构建与 Nginx 托管对于需要自定义构建过程的应用示例给出了dockerfilePath指向仓库内 Dockerfile 的做法。Angular 与 React 两个前端示例的captain-definition完全一致{ schemaVersion: 2, dockerfilePath :./Dockerfile }./Dockerfile即仓库根目录下的 Dockerfile。两个示例采用了同一套多阶段构建思路以 angular-via-caprover.tar 内的 Dockerfile 为例# build environment FROM node:9.6.1 as builder RUN mkdir /usr/src/app WORKDIR /usr/src/app ENV PATH /usr/src/app/node_modules/.bin:$PATH COPY . /usr/src/app RUN npm install RUN npm run build:prod # production environment FROM nginx:1.13.9-alpine RUN rm -rf /etc/nginx/conf.d RUN mkdir -p /etc/nginx/conf.d COPY ./default.conf /etc/nginx/conf.d/ COPY --frombuilder /usr/src/app/dist/caprover-angular-app /usr/share/nginx/html EXPOSE 80 CMD [nginx, -g, daemon off;]React 版本 Dockerfile 结构相同仅在构建输出目录上不同npm run build产物位于/usr/src/app/build复制到/usr/share/nginx/html。两个示例都附带了自定义 Nginx 配置default.conf核心是前端路由的 SPA 回退规则server { listen 80; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; } error_page 500 502 503 504 /50x.html; location /50x.html { root /usr/share/nginx/html; } }try_files $uri $uri/ /index.html正是 Angular/React 这类单页应用在刷新非首页路由如/about时不出现 404 的关键。CapRover 对外暴露的 80 端口会由平台内置的负载均衡 Nginx 统一转发到该容器因此容器内只需监听 80 即可。这类编译阶段 → 运行阶段的两阶段 Dockerfile是前端项目在 CapRover 上的标准姿势构建期镜像负责 npm install 打包运行期镜像只包含 Nginx 与静态产物镜像体积小、启动快。五、dockerfileLines 方式Nginx PHP 高级组合nginx-php-advanced.tar 演示了第三种写法——不使用独立 Dockerfile而是把 Dockerfile 指令直接内联在captain-definition的dockerfileLines数组中{ schemaVersion :2 , dockerfileLines :[ FROM webdevops/php-nginx:alpine-php5, ENV PHP_MAX_EXECUTION_TIME 110, COPY ./app /app, COPY ./php.ini opt/docker/etc/php/php.ini ] }这个示例展示了几点实战技巧基础镜像选用webdevops/php-nginx它内置了 Nginx 与 PHP-FPM 一体化运行环境适合PHP 应用 自定义 Nginx 行为的组合场景通过ENV PHP_MAX_EXECUTION_TIME 110直接注入环境变量调整 PHP 最大执行时间COPY ./app /app将应用代码app/index.php、app/info.php放入镜像COPY ./php.ini ...用仓库自带的php.ini覆盖镜像内默认 PHP 配置。从实现原理看ImageMaker.tsdockerfileLines数组最终被join(\n)拼成一份临时 Dockerfile 参与构建因此数组里可以写任何标准 Dockerfile 指令。这种方式特别适合改动很小、不想为几行配置单独维护 Dockerfile 文件的场景。六、更多示例补充ASP.NET、Go 与模板之外的形态ASP.NET Core官方多阶段构建模板asp_dot_net.tar 内的 Dockerfile 是微软官方推荐的 dotnet 构建模式同样配合dockerfilePath{ schemaVersion :2 , dockerfilePath :./Dockerfile }Dockerfile 核心第一阶段用microsoft/aspnetcore-build:2.0执行dotnet restore与dotnet publish -c Release -o out第二阶段用运行时镜像microsoft/aspnetcore:2.0复制发布产物以dotnet aspnetapp.dll启动。这证明 CapRover 对任意能产出自包含可运行镜像的多阶段构建都是开放的。Go未附带 captain-definition 的最小示例go-sample.tar 内是 Go 1.19 的经典 Dockerfile先COPY go.mod go.sum并go mod download缓存依赖再COPY *.go ./CGO_ENABLED0 GOOSlinux go build -o /docker-gs-pingEXPOSE 8080。从归档内容看该示例并未附带 captain-definition 文件——可以推断它主要用于展示一段可独立构建的最小 Go 服务在 CapRover 上部署时需要你自行在仓库根目录补一份声明例如使用dockerfilePath指向./Dockerfile同时记得让应用监听 80 端口或通过 CapRover 端口映射暴露 8080。这正是 readme 强调pay attention to captain-definition的原因没有这个文件CapRover 无法确定如何构建你的应用。七、如何用这些示例在 CapRover 上跑起来在本地拿到示例后的标准玩法如下CapRover 的部署入口是应用Apps→ 部署页解压/克隆示例代码将对应 tar 解压或将项目推送到一个 Git 仓库确认根目录存在captain-definitionGo 示例除外需自补一份并确认其引用的文件Dockerfile、default.conf、php.ini、requirements.txt等路径真实存在在 CapRover 面板创建应用填写应用名并选择目标服务器触发部署把代码推送到该应用的 Git 仓库地址或在面板中直接上传项目归档CapRover 拉取代码后由 ImageMaker.ts 负责解析captain-definition并完成镜像构建构建日志可在面板实时查看绑定域名并访问构建成功后在应用详情页开启 HTTPS/绑定域名由平台负载均衡 Nginx对应 template/base-nginx-conf.ejs、template/server-block-conf.ejs 等模板将流量路由到你的容器。整个从代码到运行的链路由 AppDefinitionHandler.ts 等服务端处理器承接captain-definition的解析与校验位于构建核心 ImageMaker.ts其四选一校验逻辑见 ImageMaker.ts。仓库的测试目录如 OneClickAppDeployManager.test.ts、OneClickAppDeployRoute.test.ts也覆盖了应用定义与部署链路的验证可作为理解内部行为的补充阅读。八、社区示例应用更多技术栈的扩展起点readme.md 还提示除了仓库内置的这批示例社区还维护着更多技术栈的示例应用包括Django、Elixir/Phoenix、Laravel等。社区示例遵循同样的约定——每个项目根目录都有captain-definition——因此学习价值与内置示例一致当你需要部署某个未收录技术栈时找到对应社区示例并模仿其captain-definition写法是最快、最不易出错的路径。官方文档caprover.com/docs/sample-apps.html 的 community apps 一节收录了完整的社区示例清单可直接访问查看。九、总结一份面向实战的 captain-definition 速查你的场景推荐写法参考示例使用 CapRover 内置语言模板Node/PHP/Django/Ruby{schemaVersion: 2, templateId: node/8.7.0}node.tar、php.tar、python-django.tar、ruby-rack.tar仓库已有自定义 Dockerfile{schemaVersion: 2, dockerfilePath: ./Dockerfile}angular-via-caprover.tar、react-via-caprover.tar、asp_dot_net.tar不想维护 Dockerfile仅内联几行构建指令{schemaVersion: 2, dockerfileLines: [FROM ..., COPY ...]}nginx-php-advanced.tar使用预构建镜像跳过构建{schemaVersion: 2, imageName: nginx:1.13.9-alpine}字段定义见 ICaptainDefinition.ts无论选择哪种方式请记住三条底层约束schemaVersion必填且当前为2dockerfileLines/dockerfilePath/templateId/imageName四者只能出现其一dockerfilePath不允许指向仓库父目录之外。对照 captain-sample-apps 中的真实示例逐行研读captain-definition与配套 Dockerfile你就能举一反三为任意技术栈写出正确、可复现的 CapRover 部署声明。赞分享DevOps云原生运维【免费下载链接】caproverScalable PaaS (automated Dockernginx) - aka Heroku on Steroids项目地址https://gitcode.com/gh_mirrors/ca/caprover点击查看免费下载相关推荐KubeVela Application 示例全解析从 Definition 到 Deployment 的声明式交付实战KubeVela Application 示例全解析从 Definition 到 Deployment 的声明式交付实战 本篇指南基于 KubeVela 官方云原生DevOps运维微服务用 TableGen 声明式构建模块化 CLI深入解析 Modular 仓库 greeter-cli 示例用 TableGen 声明式构建模块化 CLI深入解析 Modular 仓库 greeter cli 示例 greeter cli 是 Modular 开源仓人工智能大模型编程语言编译器标准库算子库模型推理服务模型量化OneUptime 事件申报完全指南四种声明方式、字段解析与创建时的后台执行链路OneUptime 事件申报完全指南四种声明方式、字段解析与创建时的后台执行链路 事件Incident申报是 OneUptime 一切事件管理的起点创建可观测性后端运维前端云原生微服务AI Agent上一篇dotnet-diag 诊断指南使用 perfcollect 在 Linux 上采集 .NET 原生调用栈 CPU Profile下一篇如何全面监控Karakeep性能应用指标与业务指标完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
