Gitlab之间进行同步备份
目前，我们公司有两个研发团队，分别在北京和武汉，考虑到访问速度的问题，原有武汉的研发环境在近端部署。也就是北京和武汉分别有两套独立的研发管理环境，虽然这解决了近端访问速度的问题，但是管理上较为分散，比如研发环境备份和恢复就是最重要的问题之一。最近，处于对安全性和合规性的考虑，希望将北京和武汉的源代码，统一的集中备份，防止公司资产流失。
Gitlab同步备份需求分析
由于历史原因，北京团队使用Gerrit进行代码审核和管理的工具，但是对于很多开发人员来说，入门比较陡峭，需要记忆很多git命令，所以考虑团队扩展性的需要，将Gerrit环境逐步切换至Gitlab中，而武汉团队则是直接选择了Gitlab进行代码管理。
在选择目标侧环境时，原本想使用阿里云效和腾讯的Coding环境进行备份，以我们目前体量来看，是完全免费的。但是考虑到随着公司增长，后期可能会产生成本，所以决定利用现有的K8S生产环境部署一套Gitlab，用于代码备份。
所以本次要解决的问题就是将两个团队Gitlab环境下的所有项目定期备份至远程的Gitlab中。在最初期的方案设计中，想使用最简单的Sehll脚本进行同步，但是会出现以下几个问题要解决：
- 在前期配置过程中，如果待同步项目较多，则在目标端进行预配置的工作较多，增加了管理成本，所以希望将整组的项目进行完整的增量同步
- 如果在源端有新的代码库增加，则需要至少维护同步脚本和备份端的Gitlab环境进行修改
- 如果还想同步Gitlab上诸如Wiki等文档类页面，则需要额外的手段进行
解决过程及思考
基于以上几点考虑，期望寻求一种自动化手段解决该问题，争取实现零运维的效果。
方案一：利用Gitlab原生机制
在Gitlab中提供了一种仓库(projects)级别的同步方式，具体配置如下：
- 进入仓库的的Settings，点击Repository
- 打开Mirroring repositories
- 配置目标仓库地址及同步方式
在开源版本中，只支持Push方式，而商业版本则支持Push和Pull两种方式。这个功能的优势是实时性，每当有代码提交后，则自动触发同步，避免了不必要的负载。
但是遗憾的是，在本地进行了测试时，只显示正在同步，但是一直没有同步成功，也没有给出具体的任务状态或失败原因。同时，并没有在组级别上提供同步能力，每次新增项目时，仍然需要手动在源端和目标端进行频繁操作，维护成本较高，所以最终放弃了该方案。
方案二：开源项目
在放弃第一个解决方案后，开始在Github上寻找开源项目。有一个基于Shell开发的gitlab-mirrors的项目引起了我的关注，这个项目由多个shell脚本组成。目标端支持除gitlab之外的多种Git仓库，看起来可以满足我们的需要。但是经过调研，发现gitlab-mirrors是以project为单位，无法按照组级别进行同步，所以也无法满足我们的需要。经过多番搜索，并没有一个项目能够百分之百满足我们组级别同步备份需求的项目。
方案三：自主实现自动化流程
由于以上两种方式均无法满足需求，所以决定基于Gitlab开放的Python库进行二次开发，满足需求。基本的思路为：
- 在源端获取待同步组内的所有项目、子组
- 克隆代码、所有分支、tags
- 判断目标端Gitlab是否存在该组或者项目，如果没有则创建
- Push代码、分支、tags
在满足了以上需求后，需要定期执行脚本实现周期性增量同步，那么如何利用Docker实现最简单的部署呢？所以需求进一步更新为：
- 构建一个容器，该容器能够支持定期执行同步任务
- 容器要利用系统的crontab，支持灵活配置
- 任务在执行时要避免重复执行
基于以上需求，我开发了gitlab-sync脚本及容器(https://github.com/xiaoquqi/gitlab-sync)，改代码已经上传到github中，以下就为大家介绍详细的使用方法。
使用方法
通过以下配置，你可以轻松完成从Gitlab A中的Group A周期同步至Gitlab B中的Group B中。
前提条件
在开始配置gitlab-sync前，以下信息是必须提前获取的：
- LOCAL_GTILAB_URL: 源端的Gitlab的WEB地址及端口
- LOCAL_GITLAB_TOKEN: 源端Gitlab的Token，需要读取的权限
- LOCAL_GITLAB_GROUP: 源端Gitlab待同步的组，该组下所有项目及后续新增项目都会自动同步到目标端
- REMOTE_GTILAB_URL: 目标端Gitlab的WEB地址及端口
- REMOTE_GTILAB_TOKEN: 目标端Gitlab的Token，需要读取和写入权限
- REMOTE_GTILAB_GROUP: 目标端的组，可以与源端不一样
- REMOTE_GTILAB_PUSH_URL: 目标端Push地址，用于作为git push的目标端
除了这些信息外，Docker启动会默认将$HOME/.ssh路径挂载至容器内，所以需要你的key已经加入到源端和目标端的Gitlab中，以保证正确的Clone和Push的操作。
获取代码及配置
在代码中，提供了docker-compose.yml文件，可以直接使用。
git clone https://github.com/xiaoquqi/gitlab-sync
cd gitlab-sync
cp env.sample .env
cp crontab/cron.exmaple crontab/cron- 在.env文件中，根据提前准备好的变量进行配置
- cron是crontab的配置文件，根据需求设定周期同步策略，后面的命令行不建议修改，其中flock是为了避免任务被重复运行
启动同步
完成配置后，启动容器开始同步。
docker-compose up -d
可以在Host主机的/var/log/gitlab-sync/gitlab-sync.log获取执行过程中的日志。
总结
在整个过程中，原本是想以脚本方式做最简单的处理，但是考虑到了后期运维成本等问题，最终决定考虑一种全自动化方式进行运维。
在处理容器运行crontab时，遇到用户环境变量无法获取的问题，目前采用的一种方式是一种Work Around，在容器启动后，将当前用户环境变量Dump到根分区下固定文件，在执行period_task.sh脚本中去加载这个脚本，从而获取环境变量。如果有更好的方法进行优化，欢迎提交Pull Request。
如果大家在使用过程中有任何问题，欢迎反馈，我会持续优化代码。