양방향 미러링

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 13.9에서 GitLab 프리미엄으로 이전됨.
caution
양방향 미러링은 충돌을 일으킬 수 있습니다.

양방향 미러링은 두 저장소를 서로에서 가져오고 밀어 넣도록 구성합니다. 두 저장소 중 하나가 오류 없이 업데이트될 수 있는 것을 보장할 수 없습니다.

양방향 미러링에서 충돌 줄이기

양방향 미러링을 구성하면 저장소를 충돌을 줄이도록 구성하고 충돌이 발생했을 때 어떻게 조정할지를 준비하세요:

  • 보호된 브랜치만 미러링. 원격 저장소의 미러링된 커밋을 변경하면 충돌이 발생하고 미러링에 실패합니다.
  • 반드시 브랜치를 보호하세요. 이를 통해 히스토리를 다시 작성하여 발생하는 충돌을 방지할 수 있습니다.
  • push 이벤트 웹훅으로 미러링 지연을 줄입니다. 양방향 미러링은 같은 브랜치에 매우 가까이 만든 커밋으로 인해 경합 조건을 생성합니다. 푸시 이벤트 웹훅은 경합 조건을 완화하는 데 도움이 됩니다. 푸시 미러링은 보호된 브랜치만 푸시 미러링될 때 분당 한 번으로 제한됩니다.
  • pre-receive 훅을 사용하여 충돌 방지.

웹훅을 구성하여 GitLab에서 직접 풀을 트리거하세요

다운스트림 인스턴스에서의 push 이벤트 웹훅은 변경 사항을 더 자주 동기화하여 경합 상태를 줄이는 데 도움이 됩니다.

전제 조건:

  • 상위 GitLab 인스턴스에서 push 및 pull 미러를 구성했습니다.

다음 단계에 따라 다운스트림 인스턴스에서 웹훅을 생성합니다:

  1. API 범위로 개인 액세스 토큰을 구성했습니다.
  2. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  3. 설정 > 웹훅을 선택합니다.

  4. 이 경우에는 레포지토리 업데이트 후 Pull 미러 API 요청을 사용하여 즉시 풀을 트리거하는 웹훅 URL을 추가합니다: 

    https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
  5. Push Events를 선택합니다.
  6. 웹훅 추가를 선택합니다.

통합을 테스트하려면 테스트를 선택하고 GitLab이 오류 메시지를 반환하지 않음을 확인하세요.

pre-receive 훅을 사용하여 충돌 방지

caution
이 솔루션은 Git 푸시 작업의 성능에 부정적인 영향을 미칩니다. 왜냐하면 이 작업들은 상위 Git 저장소로 프록시됩니다.

이 구성에서 하나의 Git 저장소가 권위 있는 상위 저장소 역할을 하고 다른 하나는 하위 저장소 역할을 합니다. 서버 측 pre-receive 훅은 먼저 커밋을 상위 저장소로 푸시한 후에만 푸시를 수락합니다. 이 훅을 하위 저장소에 설치하세요.

예시: 

#!/usr/bin/env bash

# --- 하나의 푸시 미러 타겟만 가정합니다
# 푸시 미러 원격 저장소는 `remote_mirror_<id>`로 지정됩니다.
# 이 줄은 첫 번째 원격을 찾고 해당 원격을 사용합니다.
TARGET_REPO=$(git remote | grep -m 1 remote_mirror)

proxy_push()
{
  # --- Arguments
  OLDREV=$(git rev-parse $1)
  NEWREV=$(git rev-parse $2)
  REFNAME="$3"

  # --- 프록시 푸시할 브랜치의 패턴
  allowlist=$(expr "$branch" : "\(master\)")

  case "$refname" in
    refs/heads/*)
      branch=$(expr "$refname" : "refs/heads/\(.*\)")

      if [ "$allowlist" = "$branch" ]; then
        # https://git-scm.com/docs/git-receive-pack#_quarantine_environment을 처리합니다.
        unset GIT_QUARANTINE_PATH
        error="$(git push --quiet $TARGET_REPO $NEWREV:$REFNAME 2>&1)"
        fail=$?

        if [ "$fail" != "0" ]; then
          echo >&2 ""
          echo >&2 " 오류: 상위 서버가 업데이트를 거부했습니다"
          echo >&2 "   이는 일반적으로 다른 저장소가 동일한 ref로 변경 사항을 푸시하기 때문입니다. 먼저 원격 변경 사항을 통합해야 할 수도 있습니다."
          echo >&2 ""
          return
        fi
      fi
      ;;
  esac
}

# 이중 모드 허용: 명령행에서 업데이트 훅처럼 실행하거나
# 인수가 제공되지 않으면 훅 스크립트로 실행합니다:
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
  # 명령행 모드에서 터미널에 출력합니다. 누군가가
  # 이메일을 다시 보내려면 출력을 직접 sendmail로 리디렉션할 수 있습니다.
  PAGER= proxy_push $2 $3 $1
else
  # 푸시가 하나씩 상위로 프록시됩니다. 일부 항목이 성공하고 다른 항목은 실패할 수 있습니다. 이로 인해 실패한 푸시가 발생합니다.
  while read oldrev newrev refname
  do
    proxy_push $oldrev $newrev $refname
  done
fi

이 샘플에는 여러 가지 제한 사항이 있습니다:

  • 수정 없이 사용 사례에 따라 동작하지 않을 수도 있습니다:
    • 미러의 다양한 인증 메커니즘을 고려하지 않습니다.
    • 강제 업데이트(히스토리를 다시 작성)로 작동하지 않습니다.
    • allowlist 패턴과 일치하는 브랜치만 프록시 푸시합니다.
  • 스크립트는 Git 후크 격리 환경을 우회하며, 이는 $TARGET_REPO의 업데이트가 ref 업데이트로 간주되어 Git이 그에 대해 경고 메시지를 표시합니다.

Perforce Helix와 Git Fusion을 사용한 미러링

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 13.9에서 GitLab 프리미엄으로 이전됨.
caution
양방향 미러링은 영구적 구성으로 사용해서는 안 됩니다. 대안적인 마이그레이션 방법은 Perforce Helix에서 마이그레이션을 참조하세요.

Git Fusion은 Perforce Helix에 대한 Git 인터페이스를 제공합니다. GitLab은 Perforce Helix와의 중첩된 Perforce Helix 워크스페이스를 동시에 마이그레이션할 수 없는 경우 Git Fusion을 사용하여 프로젝트를 양방향으로 미러링할 수 있습니다.

Perforce Helix로 미러링하는 경우 보호된 브랜치만 미러링하세요. Perforce Helix는 히스토리를 다시 작성하는 푸시를 거부합니다. Git Fusion의 성능 제한에 의해 최소한의 수의 브랜치만 미러링해야 합니다.

Perforce Helix와 Git Fusion을 사용하여 미러링을 구성하는 경우 다음 Git Fusion 설정을 사용해야 합니다:

  • change-pusher를 비활성화하세요. 그렇지 않으면 모든 커밋이 미러링 계정으로 커밋된 것으로 다시 작성되어 기존 Perforce Helix 사용자 또는 unknown_git 사용자로 매핑될 수 없습니다.
  • GitLab 사용자가 Perforce Helix에 존재하지 않는 경우 unknown_git 사용자를 커밋 작성자로 사용하세요.

관련 주제