1ecefc80af
- 设置 PLAYWRIGHT_BROWSERS_PATH 环境变量指向 /app/.browsers - 创建 /app/.browsers 目录用于存放浏览器文件 - 分别以 root 用户和 appuser 用户执行 Playwright 依赖和浏览器安装 - 提升 /app/.browsers 目录权限，保证 appuser 访问权限 - 调整安装步骤顺序，优化权限和用户切换流程 docs(kami-gateway): 新增 kami-gateway 模块文档及构建脚本说明 - 添加了 kami-gateway 模块的整体介绍及项目结构概述 - 详细描述了基础镜像构建流程和核心组件（Dockerfile.base 与 build-base-image.sh） - 分析了 Go 依赖管理方式及 Docker 构建优化机制 - 介绍了 CI/CD 集成流程及自动化构建逻辑 - 阐述了性能优化措施，包括中国镜像源配置和极速构建策略 - 提供了常见故障排查指南以提高镜像构建和推送的稳定性 - 补充了安全性设计，如非 root 用户运行和证书管理 chore(docker): 更新 Go 模块代理地址 - 将 GOPROXY 从 https://goproxy.cn 更改为 https://goproxy.io - 保持其他环境变量配置不变 - 解决国内代理访问速度或稳定性问题
6.3 KiB
CI/CD集成与自动化
**Referenced Files in This Document** - [build-base-image.sh](file://kami-gateway/build-base-image.sh) - [README.md](file://kami-gateway/README.md) - [build-base-image.sh](file://kami-spider-monorepo/build-base-image.sh) - [build-base-image.sh](file://alpine-base/build-base-image.sh)目录
简介
本文档全面介绍kami-gateway模块与Drone CI等持续集成系统的集成方案。文档解析了构建脚本中的环境变量控制逻辑，说明了如何实现条件化构建与镜像推送，阐述了变更检测机制如何避免不必要的镜像重建，展示了在CI流水线中如何安全地注入凭证并执行构建任务，并讨论了镜像标签策略的最佳实践。
项目结构
项目包含多个模块的构建脚本，每个模块都有独立的构建配置。kami-gateway模块作为重点分析对象，其构建流程代表了整个项目的CI/CD实践标准。
Section sources
核心组件
kami-gateway模块的核心构建组件是build-base-image.sh脚本，该脚本负责创建包含Go环境和Alpine运行时的基础Docker镜像。脚本实现了环境变量控制、条件构建、镜像标记和推送等关键功能。
Section sources
架构概述
kami-gateway的CI/CD架构基于Drone CI系统，通过变更检测机制触发条件化构建流程。构建脚本与CI系统协同工作，实现了高效的镜像构建和推送流程。
graph TB
subgraph "CI/CD Pipeline"
Trigger["变更检测\n(Drone CI)"] --> Condition["条件判断\n(目录变更)"]
Condition --> Build["执行构建\n(build-base-image.sh)"]
Build --> Push["镜像推送\n(Registry)"]
end
subgraph "构建脚本"
Env["环境变量控制\n(VERSION, DOCKER_REGISTRY)"] --> Build
Proxy["代理配置\n(USE_PROXY)"] --> Build
Tagging["镜像标记策略\n(latest, version)"] --> Build
end
Trigger --> Build
Build --> Push
**Diagram sources **
详细组件分析
构建脚本分析
kami-gateway的构建脚本实现了完整的CI/CD流程，包括环境变量配置、镜像构建、标记和推送等步骤。
环境变量控制逻辑
flowchart TD
Start([开始]) --> Registry["REGISTRY=\n${DOCKER_REGISTRY:-git.oceanpay.cc/danial}"]
Registry --> Version["VERSION=\n${VERSION:-latest}"]
Version --> UseProxy["USE_PROXY=\n${USE_PROXY:-0}"]
UseProxy --> Build["执行docker build"]
Build --> ConditionalTag["条件标记\n(REGISTRY != localhost:5000)"]
ConditionalTag --> Push["条件推送\n(REGISTRY != localhost:5000)"]
Push --> End([完成])
**Diagram sources **
Section sources
CI/CD工作流程
sequenceDiagram
participant Drone as "Drone CI"
participant Script as "build-base-image.sh"
participant Docker as "Docker Engine"
participant Registry as "镜像仓库"
Drone->>Script : 检测到kami-gateway/目录变更
Script->>Script : 初始化环境变量
Script->>Docker : 执行docker build
Docker-->>Script : 返回构建结果
Script->>Script : 检查REGISTRY配置
alt 非本地仓库
Script->>Docker : 执行docker tag
Script->>Registry : 执行docker push
Registry-->>Script : 返回推送结果
end
Script->>Drone : 返回构建状态
**Diagram sources **
镜像标签策略
kami-gateway采用多标签策略，为每个构建版本创建两个标签：版本号标签和latest标签，确保既有版本追溯性又有最新版本可用性。
Section sources
依赖分析
各模块的构建脚本具有相似的结构和逻辑，表明项目采用了统一的构建标准。kami-gateway模块作为Go应用的代表，其构建流程为其他模块提供了参考模式。
graph TB
alpine-base --> kami-gateway
kami-gateway --> kami-spider-monorepo
common["通用构建模式"] --> alpine-base
common --> kami-gateway
common --> kami-spider-monorepo
**Diagram sources **
Section sources
性能考虑
通过条件化构建和变更检测机制，系统避免了不必要的镜像重建，显著提升了资源利用率。基础镜像缓存机制将应用构建时间缩短至10-30秒，Go模块预下载避免了重复下载，多阶段构建优化了最终镜像体积。
Section sources
故障排除指南
当CI/CD流程出现问题时，应首先检查环境变量配置是否正确，特别是DOCKER_REGISTRY和VERSION变量。确认变更检测机制是否正常工作，检查构建脚本的条件判断逻辑是否按预期执行。
Section sources
结论
kami-gateway模块的CI/CD集成方案展示了高效的自动化构建实践。通过环境变量控制、条件化构建、变更检测和多标签策略，系统实现了资源高效利用和版本可追溯性的平衡。该方案可作为其他模块的参考模板，并可根据需要扩展支持多平台构建和自动化安全扫描等高级功能。