上一篇详细介绍了mirroring的push功能，本篇给大家介绍下mirroring的pull功能的使用。
文章目录
- 1. pull mirroring
- 1.1 介绍
- 1.2 工作方式
- 2. 配置拉取镜像
- 2.1 基于https的方式
- step1: 选择远程gitlab所在的项目和获取token
- step2: 配置本地gitlab
- step3: 验证
- 2.2 基于ssh方式
- step1: 获取远端地址
- step2: 本地gitlab配置
- step3: 验证
1. pull mirroring
1.1 介绍
可以通过在GitLab的仓库中创建拉取镜像，将分支、标签和提交从上游仓库复制到您的。
与推送镜像不同，拉取镜像按计划从上游（远端）仓库检索更改。为防止镜像与上游仓库分叉，请勿将提交直接推送到下游镜像，改为将提交推送到上游仓库。远端仓库中的更改在以下情况被拉入极狐GitLab 仓库：
- 在一定时间内自动。私有化部署实例可以配置拉取镜像间隔。
- 当管理员强制更新镜像。
- 当 API 调用触发更新时。
默认情况下，如果下游拉取镜像上的任何分支或标签与本地仓库不同，GitLab 将停止更新该分支。这可以防止数据丢失。上游仓库中删除的分支和标签不会反映在下游仓库中。
1.2 工作方式
将 GitLab 仓库配置为拉取镜像后：
- GitLab 将仓库添加到队列中；
- 每分钟一次，Sidekiq cron 作业调度仓库镜像更新，基于：
- 可用容量，由 Sidekiq 设置决定；
- 队列中已有多少镜像需要更新。到期取决于上次更新仓库镜像的时间以及重试更新的次数。
- Sidekiq 可用于处理更新，镜像被更新。如果更新过程：
- 成功：更新再次排队等待至少 30 分钟。
- 失败：稍后再次尝试更新，在 14 次失败后，镜像被标记为 hard failure 并且不再排队等待更新。分支与其上游对应分支的分叉可能导致故障。为防止分支分叉，请在创建镜像时配置覆盖分叉的分支。
2. 配置拉取镜像
2.1 基于https的方式
step1: 选择远程gitlab所在的项目和获取token
如果需要通过某个用户来完成镜像推送，需要在协议后加上被推送仓库的username@,如https://renliting@kube.bdeet.top/ci-file/cd.git,对应的密码就是renliting用户的密码。改用户的权限至少是maintainer权限。
url: https://kube.bdeet.top/ci-file/cd.git
token: xxxxxxxxxx #个人令牌
step2: 配置本地gitlab
step3: 验证
远程gitlab提交
本地gitlab同步
2.2 基于ssh方式
step1: 获取远端地址
ssh://git@kube.bdeet.top:2222/ci-file/cd.git
step2: 本地gitlab配置
复制公钥
获取公钥，并添加到远端gitlab的server上
查看ssh密钥变化
step3: 验证
在http方式的pull中已经对远程gitlab做了提交，只需要验证ssh方式pull同步过来的状态即可
