docker compose部署drone ci的核心是server与runner分离协同：server负责调度和ui（禁用cron、sqlite内置库），runner复用宿主机docker引擎，共用自定义网络和一致rpc密钥，4g内存即可稳定运行微服务ci/cd。
用 Docker Compose 搭 Drone CI，本质是把服务编排和构建执行解耦又协同：Compose 负责稳稳拉起 Drone Server 和 Runner，Drone 负责按需启动临时容器跑构建任务。整套下来不依赖外部调度器，4G 内存小服务器就能扛住多个微服务的日常 CI/CD。
核心组件怎么配才轻又稳
Server 和 Runner 必须分离部署，但通过共享 secret 和网络互通。关键点不是堆配置，而是砍掉冗余：
- Server 只管调度和 UI，禁用数据库持久化（用内置 SQLite 就够）、关掉 cron、不挂日志卷——除非调试需要
- Runner 用 docker-runner-docker:1，直接复用宿主机 Docker 引擎，省去 DinD 开销；只映射
/var/run/docker.sock，不额外开端口 - 两个服务共用一个自定义网络（如
drone-net），避免走 NAT，通信延迟更低 - 环境变量里 DRONE_RPC_SECRET 必须一致，这是 Server 和 Runner 唯一信任凭证，用
openssl rand -hex 16生成一次就好
.drone.yml 怎么写才适配微服务
每个微服务根目录放自己的 .drone.yml，不共用模板。重点在“按需构建、按需发布”：
- 用 trigger 精确控制触发条件，比如只在
services/user-service目录变更时跑对应构建 - 构建阶段用 docker buildx 直接推镜像到私有 Registry（如 Gitea 内置 Registry 或本地 Harbor），跳过本地 save/load
- 部署阶段用 ssh 插件登录目标服务器，执行
docker-compose pull && docker-compose up -d，不重启整个栈，只更新变动服务 - 敏感信息（如 SSH 私钥、Registry 密码）统一存在 Drone 的密钥管理里，YAML 中用
from_secret引入
怎么让流水线真正“极速”起来
快不是靠加资源，而是减少等待和重复动作：
- 启用 workspace 缓存：把
node_modules、~/.m2、~/.gradle这类高频依赖挂成命名卷，下次构建直接复用 - 构建镜像时加
--cache-from参数，优先拉取上一次成功镜像作为缓存源，跳过已构建层 - 测试阶段拆成单元测试（本地跑）和集成测试（单独 stage，只在 main 分支触发），避免每次 PR 都等全量测试
- Runner 设置
DRONE_RUNNER_CAPACITY=3，允许最多 3 个构建并行，但注意别超过宿主机 CPU 核数
Gitee 或 GitLab 接入要点
Webhook 是唯一入口，必须手动配准，不能只靠 OAuth 自动绑定：
- Gitee 上进仓库 Settings → Webhooks，URL 填
http://你的IP:端口/hook（端口要和 Compose 里 Server 的 ports 映射一致） - Secret 填和
DRONE_RPC_SECRET同一个值，Gitee 会用它签名请求，Drone Server 自动验签 - 勾选
Pushes和Pull Request事件，确保代码提交和合并都能触发 - 首次推送后，在 Drone UI 的仓库列表里手动激活，否则不会显示构建历史
