상대 URL에서 서브도메인으로 마이그레이션#

GitLab을 상대 URL 구성에서 서브도메인 배포로 마이그레이션할 수 있습니다.

마이그레이션 중 다운타임은 배포 아키텍처 및 로드 밸런서 구성에 따라 다릅니다.

• GitLab 업그레이드 다운타임: 단일 노드 설치의 경우, GitLab 재구성 시 다운타임이 발생합니다. 로드 밸런싱이 적용된 다중 노드 설치의 경우, 무중단 업그레이드 프로세스를 따라 노드를 순차적으로 업데이트하여 다운타임을 최소화할 수 있습니다.

• URL 전환 중 사용자 체감 다운타임: 영향은 로드 밸런서 및 DNS 구성에 따라 다릅니다. GitLab 구성 변경을 적용하기 전에, 로드 밸런서 또는 DNS를 구성하여 이전 URL과 새 URL 모두를 동일한 백엔드로 라우팅할 수 있으며, 이를 통해 전환 중 사용자 체감 중단을 최소화할 수 있습니다.

GitLab은 실제로 사용할 URL로 구성되어야 합니다. 하나의 URL로 GitLab을 구성한 후 로드 밸런서를 사용하여 사용자에게 다른 URL을 제공하는 것은 불가능합니다. GitLab은 API 응답, 이메일, UI 요소에서 내부적으로 절대 URL을 생성하기 때문입니다.

서브도메인으로 마이그레이션#

상대 URL에서 서브도메인으로 마이그레이션하려면 다음 단계를 따르세요.

• 설치 유형에 따라 상대 URL 구성을 비활성화하도록 GitLab 구성을 업데이트합니다.

  Linux package (Omnibus)

  /etc/gitlab/gitlab.rb를 편집하고 external_url을 새 서브도메인으로 업데이트합니다.

  external_url "https://gitlab.example.com"
  

  Helm chart (Kubernetes)

  global.hosts 구성을 새 서브도메인을 사용하도록 업데이트합니다.

  Self-compiled (source)

  GitLab에서 상대 URL 비활성화를 따릅니다.

• 새 서브도메인 구성을 적용하려면 설치 유형에 해당하는 GitLab 인스턴스 업그레이드 업그레이드 프로세스를 따릅니다.

• URL을 변경하면 모든 원격 URL이 변경되므로, GitLab 인스턴스를 가리키는 로컬 리포지터리에서 직접 편집해야 합니다. 상대 URL을 사용하는 동안 클론한 로컬 리포지터리는 이전 경로를 가리키는 원격 URL을 갖고 있으므로, 사용자가 직접 업데이트해야 합니다.

• 전환 기간 동안 기존 링크를 유지해야 하는 경우, 로드 밸런서 리다이렉트 구성을 통해 기존 상대 URL을 새 서브도메인으로 리다이렉트합니다.

로드 밸런서 리다이렉트 구성#

GitLab을 상대 URL에서 서브도메인으로 마이그레이션한 후, 로드 밸런서를 구성하여 이전 상대 URL을 새 서브도메인으로 리다이렉트합니다.

• 로드 밸런서에 이전 도메인과 새 도메인 모두에 대한 SSL 인증서가 있는지 확인합니다.

• 두 도메인이 로드 밸런서로 확인되도록 DNS를 구성합니다.

• 로드 밸런서 구성에 다음을 수행하는 리다이렉트 규칙을 추가합니다.

  상대 URL 접두사로 시작하는 경로(예: /gitlab/)를 갖는 이전 도메인으로의 요청을 감지합니다.

  • 301(영구 리다이렉트) 상태로 새 서브도메인으로 요청을 리다이렉트합니다.

  • 경로의 처음에서 상대 URL 접두사를 제거하여 경로 및 쿼리 파라미터를 보존합니다.

• 별도의 URL 구성이 있는 GitLab 컴포넌트(예: 컨테이너 레지스트리 또는 Pages)가 있는 경우, 해당 경로에 대해서도 유사한 리다이렉트 규칙을 추가합니다.