k8sgerrit/git-gc Docker 镜像 - 轩辕镜像 | Docker 镜像高效稳定拉取服务

Git GC容器镜像

镜像概述

Git GC容器镜像是一个专门用于执行Git垃圾回收（git gc）操作的容器化解决方案。该镜像通过自动化清理Git仓库中的冗余数据、优化存储结构，提升仓库性能并减少存储空间占用。主要设计用于Kubernetes环境，可作为CronJob实现定时自动回收，或作为Job按需手动触发。

核心功能和特性

• 内置垃圾回收脚本：包含gc-all.sh脚本，封装git gc命令，支持批量或单仓库回收操作
• 灵活执行模式：支持定时任务（通过Kubernetes CronJob）和按需执行（通过Kubernetes Job或直接运行容器）
• 轻量级设计：基于基础镜像构建，资源占用低，部署便捷
• 权限兼容：支持自定义文件系统权限配置，确保对Git仓库的读写访问

使用场景和适用范围

• 定时维护场景：在管理多个Git仓库的Kubernetes集群中，通过CronJob定期（如每日/每周）执行垃圾回收，保持仓库长期高效运行
• 按需清理场景：当Git仓库出现性能下降、存储空间异常增长时，通过手动创建Job或直接运行容器执行临时清理
• CI/CD集成场景：作为流水线环节，在代码合并、仓库归档等操作后自动触发，优化仓库状态

使用方法和配置说明

前提条件

• 目标Git仓库路径需通过卷挂载至容器内
• 容器运行用户需对挂载的Git仓库目录拥有读写权限（包含.git子目录）

配置步骤

1. 准备Git仓库
   将需要维护的Git仓库通过持久化存储（如Kubernetes PV/PVC、本地目录）挂载至容器，确保容器内路径可访问（建议挂载路径：/git-repo）

2. 权限配置
   根据实际环境设置容器运行用户ID（UID），确保与仓库目录权限匹配：

   • 直接运行容器时：通过--user参数指定用户ID（如--user 1000:1000）
   • Kubernetes环境：通过securityContext配置runAsUser和fsGroup

3. 脚本参数自定义
   如需调整垃圾回收行为（如启用激进清理、设置压缩深度等），可修改gc-all.sh脚本或通过环境变量传递参数（具体参数参考Git官方文档）

部署示例

Docker命令行运行（按需执行）

bash
docker run --rm \
  -v /path/to/local/git/repo:/git-repo \  # 挂载本地Git仓库目录
  --user $(id -u):$(id -g) \             # 使用当前用户权限避免权限问题
  git-gc-image \                         # 替换为实际镜像名称
  /gc-all.sh /git-repo                   # 执行脚本并指定仓库路径

Kubernetes CronJob配置（定时执行）

yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: git-gc-cronjob
spec:
  schedule: "0 3 * * *"  # 每日凌晨3点执行（Cron表达式）
  jobTemplate:
    spec:
      template:
        spec:
          securityContext:
            runAsUser: 1000
            fsGroup: 1000
          containers:
          - name: git-gc
            image: git-gc-image  # 替换为实际镜像地址
            volumeMounts:
            - name: repo-volume
              mountPath: /git-repo  # 容器内仓库挂载路径
            command: ["/gc-all.sh", "/git-repo"]  # 执行垃圾回收脚本
          volumes:
          - name: repo-volume
            persistentVolumeClaim:
              claimName: git-repo-pvc  # 指向包含Git仓库的PVC
          restartPolicy: OnFailure  # 失败时重启容器

注意事项

• 仓库路径验证：确保挂载路径包含完整的Git仓库（需存在.git子目录）
• 执行频率规划：根据仓库活跃度调整CronJob周期（频繁更新仓库建议每日执行，静态仓库可每周执行）
• 资源配置：大型仓库建议增加资源限制（如resources.limits.cpu=1、resources.limits.memory=1Gi），避免执行超时
• 数据备份：首次执行前建议备份仓库数据，防止异常情况导致数据丢失