gitlab高级功能之mirroring - pull mirroring（二）

上一篇详细介绍了mirroring的push功能，本篇给大家介绍下mirroring的pull功能的使用。

文章目录

• • [1. pull mirroring](#1. pull mirroring)
  • • [1.1 介绍](#1.1 介绍)
    • [1.2 工作方式](#1.2 工作方式)
  • [2. 配置拉取镜像](#2. 配置拉取镜像)
  • • [2.1 基于https的方式](#2.1 基于https的方式)
    • • [step1: 选择远程gitlab所在的项目和获取token](#step1: 选择远程gitlab所在的项目和获取token)
      • [step2: 配置本地gitlab](#step2: 配置本地gitlab)
      • [step3: 验证](#step3: 验证)
    • [2.2 基于ssh方式](#2.2 基于ssh方式)
    • • [step1: 获取远端地址](#step1: 获取远端地址)
      • [step2: 本地gitlab配置](#step2: 本地gitlab配置)
      • [step3: 验证](#step3: 验证)

1. pull mirroring

1.1 介绍

可以通过在GitLab的仓库中创建拉取镜像，将分支、标签和提交从上游仓库复制到您的。

与推送镜像不同，拉取镜像按计划从上游（远端）仓库检索更改。为防止镜像与上游仓库分叉，请勿将提交直接推送到下游镜像，改为将提交推送到上游仓库。远端仓库中的更改在以下情况被拉入极狐GitLab 仓库：

• 在一定时间内自动。私有化部署实例可以配置拉取镜像间隔。
• 当管理员强制更新镜像。
• 当 API 调用触发更新时。
  默认情况下，如果下游拉取镜像上的任何分支或标签与本地仓库不同，GitLab 将停止更新该分支。这可以防止数据丢失。上游仓库中删除的分支和标签不会反映在下游仓库中。

1.2 工作方式

将 GitLab 仓库配置为拉取镜像后：

1. GitLab 将仓库添加到队列中；
2. 每分钟一次，Sidekiq cron 作业调度仓库镜像更新，基于：
   • 可用容量，由 Sidekiq 设置决定；
   • 队列中已有多少镜像需要更新。到期取决于上次更新仓库镜像的时间以及重试更新的次数。
3. 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同步过来的状态即可