Dokploy部署Net服务，打造CI/CD开发环境

Dokploy部署Net服务，打造CI/CD开发环境。

流程图

附代码：

graph TD
A[开发者] --推送代码--> B[代码仓库]
B --Action/Webhook通知--> C[Dokploy服务器]
C--拉取-->B
C --构建--> D[Docker镜像]
F[用户]--访问-->C
D --启动--> E[新容器]
E --运行在--> C

搭建DokPloy环境

购买云服务器

购买一台云服务主机（推荐hostinger的vps），2核8G的配置完全够用了。安装好Docker（一般服务器会自带docker，无需安装）

Linux模拟器搭建

转到：系统设置-应用-程序和功能-启用或关闭Windows功能，开启<font style="color:rgb(0, 0, 0);">虚拟机平台</font>和<font style="color:rgb(0, 0, 0);">适用于Linux的Windows子系统</font>

使用wsl2来搭建环境，需要提前安装docker， 前往安装****

安装DokPloy

运行命令curl -sSL https://dokploy.com/install.sh | sh

安装成功：

打开上面网址：

wsl安装问题

Error response from daemon: must specify a listening address because the address to advertise is not recognized as a system address, and a system's IP address to use could not be uniquely identified

原因：Dokploy 安装脚本尝试使用 公网 IP（139.227.161.253） 初始化 Docker Swarm，但此地址未绑定到 WSL 的网络接口，导致 Docker 无法识别为有效地址。

解决方法：修改安装脚本

# 下载脚本并编辑
curl -sSL https://dokploy.com/install.sh -o install.sh
# 注释掉 Swarm 初始化相关的代码行（例如包含 `docker swarm init` 的行）
sed -i '/docker swarm init/d' install.sh
# 运行修改后的脚本
sh install.sh

或者：

# 设置环境变量强制脚本使用你的 IP
export ADVERTISE_ADDR=172.28.123.234
curl -sSL https://dokploy.com/install.sh | sh

（官网 解决方法为：curl -sSL https://dokploy.com/install.sh | ADVERTISE_ADDR=your-ip sh）

wsl启动dokploy

dokploy一般在启动wsl时会自动开启服务，如果未启动可参考下面步骤：

• 检查docker服务：service docker status service docker start
• 确认已激活swarm：docker info | grep Swarm
• 查看dokploy 容器是否启动：docker ps docker start <ID>，端口号为3000
• 获取wsl IP:hostname -I | awk '{print $1}'或使用localhost访问dokploy

部署项目

域名解析

在Dokploy Server Domain处设置自定义域名，再到解析平台（CloudFlare）添加自定义域名的解析，选择A类地址，IP为服务器IP。

绑定Git

这里使用GitHub作为代码仓库

按照提示创建GitHub App

下载安装

准备项目

事先创建好一个web api应用用于部署，因为部署使用的dockerfile模式，因此准备好docker file文件：

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "WebApplication1.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

创建项目

创建好后可以新建服务

选择应用

创建compose服务

需要更复杂的部署配置可以选择创建compose服务。

在项目解决方案中添加docker-compose.yml文件：

version: "3"
services:
  webapplication1:
    image: webapplication1
    build:
      context: .
      dockerfile: WebApplication1/Dockerfile
    restart: always
    ports:
      - "8080:8080"  # 宿主机:容器
    networks:
      - dokploy-network
networks:
  dokploy-network:
    external: true

创建远程仓库

在GitHub上创建好仓库，推送代码：

配置项目

设置好GitHub仓库和构建类型

在Advanced-Ports中设置将容器内端口暴露给外界：

compose服务配置

对于compose服务，配置GitHub或Git，以及Compose Path（注意路径和文件名是否正确，如果文件是在仓库的根目录下，则不用加./）

配置非GitHub提供者

对于非GitHub，使用Webhooks以实现代码仓库改变时自动部署项目。

• 打开Auto Deploy选项
• 在Deploment页面获取Webhook URL
• 
• 转到托管代码的仓库配置webhook
• 
• 注：应使用wsl的IP地址而不是localhost
• 
• 将仓库的url地址添加到项目git设置中
• 还需要添加SSH密钥以验证身份
• 
• 生成并复制公钥
• 
• 在代码仓库中添加密钥
• 
• 此外，针对与Gitea与Dokploy部署于同一服务器时，可能需要额外配置ALLOWED_HOST_LIST（出于安全原因，Webhook 仅能调用允许的主机。默认配置为external，一个有效的非私有单播 IP，可以访问公共互联网上的所有主机）以允许Gitea访问dokploy所在服务器的ip。
• 
• ALLOWED_HOST_LIST环境变量需要增加前缀GITEA__webhook__（在使用docker配置环境变量时，格式为GITEA__[Section Name]_[Key Name], Gitea 将在启动时将其写入 app.ini）
• 
• 在仓库webhook测试推送
• 

部署

点击Deploy进行部署

查看logs：

在主机尝试请求API：

尝试推送一次更新：

可以看到服务在重新部署了

测试下新加的内容也能正常访问：

防错机制

结合自动化检查、分支策略和分阶段部署，显著降低构建失败对生产环境的影响。

添加健康检查点

在web应用中添加代码：

builder.Services.AddHealthChecks();
app.MapHealthChecks("/health");

在advanced-Cluster Settings中编辑Swarm Settings，添加健康检查点：

Health Check

{
  "Test": [
    "CMD",
    "curl",
    "-f",
    "http://localhost:8080/health"
  ],
  "Interval": 30000000000,
  "Timeout": 10000000000,
  "StartPeriod": 30000000000,
  "Retries": 3
}

和Update Config

{
  "Parallelism": 1,
  "Delay": 10000000000,
  "FailureAction": "rollback",
  "Order": "start-first"
}

配置好之后，当Dokploy检测到接口不正常时会自动回滚到上一个版本。

分支保护与PR审查

在 GitHub/GitLab 中设置分支保护规则：

• 禁止直接推送到 main （主要）分支。
• 要求 Pull Request (PR) 通过 CI 检查和至少一人审查后才能合并。

这样一来，开发项目的流程为：

1. 克隆仓库 git clone https://gitea.example.com/your-project/api.git
2. 保持本地 main 分支同步 git checkout main``git pull origin main # 始终从远程获取最新代码
3. 创建新功能分支（基于 main）git checkout -b feature/user-auth # 分支命名规范：feature/[功能名]
4. 开发与本地提交git commit -m "feat: 实现用户JWT认证逻辑"
5. 推送分支到远程仓库git push -u origin feature/user-auth # 首次推送需要建立跟踪关系
6. 创建 Pull Request (PR)，选择base: main ← compare: feature/user-auth，填写 PR 描述模板，关联 Issues（如有），项目等信息
7. 代码审查
   1. 检查代码变更
   2. 提交评论或请求修改（需处理后再推送）
   3. 通过 /test 命令触发 CI 流水线
8. 合并 PR 到 main（设置自动清理分支）
9. 同步本地仓库，同第二步

分支命名应遵循以下规范：

• feature/xxx # 新功能开发
• bugfix/xxx # 问题修复
• hotfix/xxx # 紧急修复
• docs/xxx # 文档更新

提交信息应遵循下面规范：

• feat: 添加用户注册功能
• fix: 解决登录500错误
• docs: 更新API文档
• chore: 更新依赖版本

流程图为：

graph TD
A[开发者] --> B[克隆仓库]
B --> C[拉取最新 main 分支]
C --> D[创建 feature/xxx 分支]
D --> E[本地开发并提交]
E --> F[推送分支到远程]
F --> G[创建 Pull Request]
G --> H{通过审核?}
H -->|是| I[合并到 main]
H -->|否| J[修改后重新推送]
J --> E
I --> K[删除 feature 分支]
K --> L[触发自动部署]

本地与 CI 流水线强验证

• 在本地代码仓库中配置 Git Hooks，在推送前自动运行构建和测试

# .git/hooks/pre-push
#!/bin/sh
dotnet build && dotnet test

• 使用 GitHub Actions/GitLab CI 等工具，在合并代码前运行 CI 流水线

# .github/workflows/build.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: dotnet build
    - run: dotnet test