最近在探索自动化平台选型时看到不少团队从 SaaS 自动化工具转向自托管方案核心诉求无非是数据不出内网、执行环境可控、任务编排逻辑完全掌握在自己手里。本文要聊的 Dagychu 正是这样一款定位清晰的 self-hosted 自动化平台它把运行、调度、监控和管理自动化任务整合到一个界面中适合团队内部快速搭建属于自己的自动化中控台。如果你们正在调研自托管自动化平台或者希望把零散的脚本、定时任务、API 调用统一管理起来这篇文章可以给你一个完整的落地参考。我会从概念讲起给出可复制的部署配置、工作流编写示例以及日常运维中最容易踩的坑。1. Dagychu 是什么解决什么问题1.1 一句话理解 DagychuDagychu 是一个可以部署在自己服务器上的自动化平台。所谓 self-hosted意思是整个系统运行在你自己控制的机器上代码、数据、执行日志都由自己管理不依赖第三方云服务。它的核心能力可以拆成三块运行自动化任务支持定时触发、手动触发、事件触发等方式。管理工作流把多个步骤编排成一条完整流程步骤之间可以传递数据。集中监控所有执行记录、日志、成功失败状态统一查看。1.2 它和普通的定时任务工具有什么区别很多开发者第一反应是“我有 crontab 不就够了吗”确实单机场景下 crontab 很实用但当你面对下面这些情况时crontab 会变得难以招架任务数量超过几十个依赖关系复杂。任务需要跨机器执行。某个步骤失败后需要重试、告警、通知。需要看历史执行记录和日志。团队成员都要能查看任务状态而不是登录服务器翻日志。Dagychu 这类平台解决的核心问题是“自动化任务的可见性和可编排性”。它把散落在各个服务器上的脚本任务集中到统一平台中并提供 Web 界面进行操作。1.3 适用场景从实际使用场景来看Dagychu 比较适合以下几类需求场景说明定时数据处理每天定时拉取数据、清洗、写入数据库CI/CD 辅助任务构建前执行代码检查、构建后自动部署运维自动化日志清理、备份任务、健康检查脚本业务自动化定时生成报表、发送通知、同步第三方接口内部工具平台团队共享的自动化任务执行入口如果你正在做这些事Dagychu 可以作为一个基础能力平台来使用。2. 环境准备与部署规划在动手部署前先梳理一下需要准备的环境。这里以常见的 Linux 服务器 Docker 部署方式为例因为这是目前自托管项目最主流、也最容易迁移的部署形态。2.1 运行环境清单组件建议配置操作系统Ubuntu 22.04 / Debian 12 / CentOS 7CPU2 核及以上内存4GB 及以上磁盘20GB 及以上取决于日志和任务产物Docker20.10 及以上Docker Composev2 及以上数据库PostgreSQL版本根据镜像要求调整反向代理Nginx / Caddy可选用于 HTTPS版本说明Dagychu 迭代速度较快具体版本号请以官方发布为准。本文示例中的配置思路适用于大多数自托管平台如果版本差异较大重点调整镜像标签和数据库连接参数即可。2.2 数据库选择建议Dagychu 本身需要持久化存储任务定义、执行记录、用户信息等数据。生产环境强烈建议使用外部 PostgreSQL 实例而不是容器内部自带的数据库。原因很简单容器重建后数据不丢失。便于统一备份。方便接入现有的数据库监控体系。如果你只是本地体验也可以先用 Docker 启动一个 PostgreSQL不建议在生产环境用 SQLite 或临时数据库。2.3 项目目录规划/opt/dagychu ├── docker-compose.yml ├── .env ├── data/ # 容器数据目录 │ ├── postgres/ │ └── dagychu/ └── logs/ # 平台日志把数据目录和配置文件放在独立位置后续升级、备份都很方便。3. 使用 Docker Compose 部署 Dagychu3.1 编写 docker-compose.yml下面是一份完整的 docker-compose 配置包含 Dagychu 服务本身和 PostgreSQL 数据库。请根据实际情况调整镜像版本号和端口。# 文件路径/opt/dagychu/docker-compose.yml version: 3.8 services: postgres: image: postgres:15-alpine container_name: dagychu-postgres restart: unless-stopped environment: POSTGRES_USER: dagychu POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: dagychu volumes: - ./data/postgres:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U dagychu] interval: 10s timeout: 5s retries: 5 dagychu: image: dagychu/dagychu:latest container_name: dagychu-server restart: unless-stopped depends_on: postgres: condition: service_healthy ports: - 8080:8080 environment: DAGYCHU_DATABASE_URL: postgresql://dagychu:${DB_PASSWORD}postgres:5432/dagychu DAGYCHU_DATA_DIR: /data DAGYCHU_LOG_LEVEL: info volumes: - ./data/dagychu:/data - ./logs:/logs - /var/run/docker.sock:/var/run/docker.sock3.2 配置环境变量在与 docker-compose.yml 同级的目录下创建.env文件# 文件路径/opt/dagychu/.env DB_PASSWORDyour_strong_password_here DAGYCHU_JWT_SECRETyour_jwt_secret_here注意事项DB_PASSWORD必须替换为高强度密码。DAGYCHU_JWT_SECRET用于签名登录令牌请使用随机字符串生成例如openssl rand -hex 32。不要把生产环境的密钥提交到 Git 仓库。3.3 启动服务cd /opt/dagychu docker compose up -d启动后查看状态docker compose ps等待 postgres 健康检查通过后访问http://服务器IP:8080应该能看到 Dagychu 的 Web 界面。3.4 初始化配置第一次打开界面时需要创建管理员账号。请牢记这个账号密码它用于后续登录和 API 调用。常见初始化步骤打开 Web 页面。创建管理员用户。登录后进入 Settings。配置时区、默认执行器、日志保留策略。4. 核心概念拆解使用 Dagychu 之前需要先理解几个核心概念。这些概念和常见的 workflow 引擎类似但不同平台命名略有差异。4.1 Workflow工作流Workflow 是 Dagychu 中最基本的执行单元。一个 Workflow 包含多个步骤步骤之间按顺序执行也可以配置条件分支。一个典型的数据同步工作流如下name: daily_data_sync description: 每天同步业务数据到数据仓库 triggers: - type: cron cron: 0 2 * * * timezone: Asia/Shanghai steps: - id: extract name: 拉取业务数据 type: http endpoint: https://api.internal.example.com/data method: GET headers: Authorization: Bearer ${TOKEN} - id: transform name: 数据清洗 type: command command: python scripts/clean_data.py docker_image: python:3.11-slim - id: load name: 写入数据仓库 type: database db_connection: DWH sql: INSERT INTO daily_sales SELECT * FROM temp_sales;说明triggers定义了触发方式示例中使用cron表达式每天凌晨 2 点执行。steps数组中的每个步骤按从上到下顺序执行。前一步的输出可以作为后一步的输入具体通过上下文变量引用。4.2 Executor执行器Executor 是真正执行步骤的运行时环境。Dagychu 支持多种执行方式执行器类型说明Docker Executor每个步骤在独立容器中运行隔离性好Host Executor直接在宿主机上执行命令适合简单脚本HTTP Executor调用外部 HTTP API适合对接现有服务推荐使用 Docker Executor因为它能保证每次执行的环境一致性避免“在我机器上能跑”的问题。4.3 Schedule调度调度功能负责按时触发 Workflow。Dagychu 支持Cron 表达式。固定间隔。日历指定日期时间。事件驱动通过 Webhook 触发。4.4 Run执行记录每次触发都会生成一条 Run 记录包含执行状态成功、失败、运行中、取消。每个步骤的开始时间、结束时间、耗时。输出日志。错误堆栈。通过 Run 页面可以回溯任何一次执行的细节这是排查问题的关键入口。5. 编写并运行第一个自动化任务5.1 创建任务描述文件Dagychu 支持通过 Web 界面创建任务也支持通过 YAML 文件导入。这里演示 YAML 方式。假设业务需求每天检查服务器磁盘使用率超过 80% 时发送通知。# 文件路径/opt/dagychu/workflows/disk_check.yaml name: disk_space_check description: 检查服务器磁盘使用率超过阈值发送通知 triggers: - type: cron cron: */30 * * * * steps: - id: check_disk name: 获取磁盘使用率 type: command command: df -h / | tail -1 | awk {print $5} | sed s/%// docker_image: alpine:3.18 - id: evaluate name: 判断是否需要告警 type: command command: if [ ${STEP_OUTPUTS.check_disk} -gt 80 ]; then echo WARN_DISK_HIGH; else echo DISK_OK; fi docker_image: alpine:3.18 - id: notify name: 发送告警通知 type: http endpoint: https://api.example.com/alert method: POST body: | { message: 磁盘使用率超过 80%当前使用率: ${STEP_OUTPUTS.check_disk}%, level: warning } headers: Content-Type: application/json5.2 导入任务在 Dagychu Web 界面中进入 Workflows 页面。点击 “Import YAML”。选择disk_check.yaml文件。确认导入。导入成功后Workflow 列表中会出现disk_space_check。5.3 手动触发验证点击 Workflow 上的 “Run Now” 按钮立刻执行一次。执行过程中可以在 “Runs” 页面观察当前执行到哪个步骤。每个步骤的日志输出。步骤间的数据传递。预期结果check_disk步骤输出一个数字例如67。evaluate步骤判断是否为DISK_OK。如果磁盘用量低于 80%notify步骤会被跳过或标记为成功但无实际请求。6. 使用 API 管理自动化平台Dagychu 提供了 REST API方便把自动化能力集成到自己的系统中。下面给出几个高频场景的示例。6.1 获取访问令牌curl -X POST http://localhost:8080/api/v1/auth/login \ -H Content-Type: application/json \ -d { username: admin, password: your_password }返回结果中会包含access_token。6.2 查看任务列表curl -X GET http://localhost:8080/api/v1/workflows \ -H Authorization: Bearer YOUR_ACCESS_TOKEN6.3 触发任务执行curl -X POST http://localhost:8080/api/v1/workflows/disk_space_check/run \ -H Authorization: Bearer YOUR_ACCESS_TOKEN6.4 查看执行日志curl -X GET http://localhost:8080/api/v1/runs/RUN_ID/logs \ -H Authorization: Bearer YOUR_ACCESS_TOKEN注意API 路径和参数可能随版本调整具体以对应版本的 Swagger UI/docs或/api-docs为准。这里给出的示例用于演示 REST 风格实际对接时请先确认版本接口。7. 进阶配置与运维实践7.1 配置 HTTPS 反向代理生产环境不建议直接用 IP 加端口访问推荐使用 Nginx 反向代理并启用 HTTPS。下面是一个 Nginx 配置示例# 文件路径/etc/nginx/sites-available/dagychu.conf server { listen 80; server_name dagychu.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name dagychu.example.com; ssl_certificate /etc/letsencrypt/live/dagychu.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/dagychu.example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }配置完成后nginx -t systemctl reload nginx7.2 日志保留策略自动化平台运行时间越长日志和 Run 记录积累越多磁盘占用会持续增长。建议在 Settings 中配置日志保留策略执行日志保留 30 天。历史 Run 记录保留 90 天。定时清理任务建议放在凌晨低峰期。也可以手动清理docker exec -it dagychu-server sh # 进入容器后执行清理命令具体命令以官方文档为准7.3 备份策略每天备份 PostgreSQL 数据库并把备份文件同步到异地存储。#!/bin/bash # 文件路径/opt/dagychu/scripts/backup.sh BACKUP_DIR/opt/dagychu/backup DATE$(date %Y%m%d_%H%M%S) docker exec dagychu-postgres pg_dump -U dagychu dagychu $BACKUP_DIR/dagychu_$DATE.sql find $BACKUP_DIR -type f -mtime 7 -delete echo Backup completed: $BACKUP_DIR/dagychu_$DATE.sql添加定时任务crontab -e # 每天凌晨 3 点执行备份 0 3 * * * /opt/dagychu/scripts/backup.sh /opt/dagychu/logs/backup.log 218. 常见问题与排查思路问题现象常见原因解决思路启动容器后 Web 页面打不开端口被占用检查 8080 端口ss -lntp | grep 8080修改映射端口PostgreSQL 健康检查失败数据库目录权限问题检查data/postgres目录属主必要时chmod -R 777或用命名卷Workflow 执行超时脚本执行时间过长在步骤配置中调大timeout参数Docker Executor 无法运行容器未挂载 docker.sock 或权限不足确认 docker-compose 中挂载了/var/run/docker.sock宿主机用户有 docker 权限HTTP 步骤返回 401Token 过期或未配置认证检查步骤中的 headers 配置确认变量引用正确中文日志乱码容器内 locale 未配置在 Dockerfile 或执行器镜像中设置ENV LANGC.UTF-8数据库连接丢失连接池参数过小在环境变量中调大连接池数量任务执行重复通知重试逻辑配置不当在步骤中设置retry: 0或合理配置重试次数排查问题时的通用思路先查看 Run 记录确认卡在哪个步骤。点击对应步骤查看完整日志。检查步骤间的变量传递确认前一步输出是否为空。在执行器环境中手动执行相同命令对比结果。最后看平台自身日志定位是否基础设施问题。9. 最佳实践与工程建议9.1 把执行环境容器化尽量让每个步骤都在独立的 Docker 容器中执行而不是直接在宿主机上跑。这样可以保证依赖隔离。版本可追溯。不同任务互不影响。9.2 配置合理的超时和重试网络请求、命令执行都可能卡住。建议HTTP 请求超时设置为 30 秒以上根据实际接口调整。外部依赖步骤可以配置 2-3 次重试间隔 5 秒。重试超过 3 次后直接失败不要无限重试。9.3 敏感信息使用 Secret 管理不要在 Workflow 的 YAML 中明文写 API Key、密码、Token。Dagychu 通常提供 Secret 或环境变量引用能力。如果版本支持请使用 Secrets 功能存放敏感信息。9.4 命名规范任务和步骤的命名直接影响团队协作效率Workflow 名称采用业务_动作格式如order_sync。步骤 ID 使用动词开头如fetch_data、clean_data、write_db。描述信息写清楚业务含义便于其他人理解。9.5 执行计划要错峰多个耗时任务避免在同一时间点触发尤其是数据库相关操作。建议数据同步任务放在业务低峰期。重任务和执行器资源评估后再设置并发。使用 Cron 表达式时错开分钟避免整点洪峰。9.6 监控平台自身健康状态Dagychu 自身也是服务需要纳入监控体系检查容器是否正常运行。检查 Web UI 是否可以访问。检查数据库磁盘空间。配置告警当平台宕机或任务大面积失败时能及时收到通知。10. 总结与下一步学习方向通过本文你应该已经掌握了 Dagychu 的核心概念、Docker Compose 部署方式、第一个自动化任务的编写与执行以及日常运维中的备份、日志、安全注意事项。这套流程不仅适用于 Dagychu也适用于其他 self-hosted 自动化平台核心方法论是相通的所有任务都要可视、可控、可回溯。接下来可以继续探索的方向包括深入阅读 Dagychu 官方文档了解每个配置项的完整含义。尝试接入更多执行器类型比如 Kubernetes Executor。学习如何开发自定义插件或扩展模块。将 Dagychu 与现有的监控系统、告警系统、内部办公系统打通。实际投入生产环境前建议先在测试环境完整跑通备份恢复流程、权限控制方案以及关键任务的降级策略。自动化平台一旦成为团队基础设施稳定性就是第一位的事情。