[Feature] 添加docker的部署方式

[feynbin]

当前项目完全依赖 Cloudflare 生态（Workers / Pages + D1），优势是 Zero-Ops，但存在以下局限：

1. 供应商锁定：无法迁移到其他平台
2. 本地开发限制：依赖 wrangler dev，无法完全模拟生产环境
3. 部分用户偏好自托管：出于数据隐私、成本控制或现有基础设施考量
4. 调试困难：Cloudflare 特有 API（如 cloudflare:sockets）难以在本地测试

期望后期项目能够使用docker部署，这会带来几个好处。

• 自托管灵活性
• 本地开发一致性
• 降低供应商锁定风险
• 吸引偏好 Docker 部署的用户群体。

[YewFence]

我理解你希望有自托管选项的需求，但这个功能与 Uptimer 的核心设计理念存在根本性冲突。

Uptimer 的定位是 Cloudflare-native + Zero-Ops：

• 完全依赖 Cloudflare 生态（Workers + Pages + D1）
• 无需维护服务器、数据库、容器
• 一键部署，自动扩展，全球分发

如果要支持 Docker 部署，需要：

1. 重写数据库层：D1 → PostgreSQL/MySQL（包括连接池、迁移脚本）
2. 重写运行时：Cloudflare Workers → Node.js（包括 TCP socket、cron 调度器）
3. 重写部署流程：GitHub Actions → Docker Compose + 反向代理配置
4. 维护两套代码：每个功能都要测试 Cloudflare 和 Docker 两个环境

这基本等于重写整个项目，而且会带来以下问题：

• 维护成本翻倍（两套代码路径、两套测试、两套文档）
• 稀释项目定位（既不是纯 serverless，也不是纯自托管）
• 违背 Zero-Ops 的初衷（用户需要自己维护数据库、备份、监控）

对于自托管需求，我强烈建议使用 Uptime Kuma：

• 专为自托管设计，功能完善（支持 20+ 监控类型）
• 开箱即用的 Docker 部署，社区活跃（20k+ stars）
• 内置数据库（SQLite），无需额外配置
• 支持多用户、RBAC、通知渠道等企业级功能

Uptimer 和 Uptime Kuma 的定位本来就不同：

• Uptimer：Cloudflare 生态 + 零运维 + 公网监控
• Uptime Kuma：自托管 + 全场景监控 + 灵活部署

用对的工具做对的事，比强行让一个工具做所有事情更合理。