GitLab Dedicated 관리 포털인 Switchboard를 사용해 GitLab Dedicated 인스턴스를 생성합니다.

이 절차는 다음 단계로 이루어집니다:

• Switchboard 액세스 권한을 받습니다.
• 인스턴스를 생성합니다.
• 새 인스턴스에 접속합니다.

Switchboard 액세스 권한 받기#

Switchboard 액세스 권한을 받으려면 다음 단계를 따릅니다:

1. 담당 계정팀에 다음 정보를 제공합니다:

   • 예상 사용자 수
   • 총 구매 스토리지
   • 리포지터리의 초기 스토리지 크기(GiB)
   • GitLab Dedicated 인스턴스를 생성하기 위해 Switchboard 액세스가 필요한 사용자의 이메일 주소
   • Geo 마이그레이션 사용 여부
   • GitLab이 암호화를 관리하는 대신 자체 암호화 키로 데이터를 보호할지 여부

   자체 암호화 키를 사용하려면 GitLab이 키 구성을 위한 AWS 계정 ID를 제공합니다.

2. 임시 Switchboard 자격 증명이 담긴 초대 메일이 왔는지 확인합니다.

   [!note] Switchboard 자격 증명은 기존 GitLab.com 또는 GitLab Self-Managed 자격 증명과 별개입니다.

3. 임시 자격 증명으로 Switchboard에 로그인합니다.

4. 비밀번호를 변경하고 다중 인증(MFA)을 설정합니다.

인스턴스 생성#

GitLab Dedicated 인스턴스를 생성하려면 다음 단계를 따릅니다:

1. Switchboard에 로그인합니다.

2. Account details 페이지에서 구독 설정을 검토하고 확인합니다:

   • Reference architecture: 예상 부하와 사용 패턴을 기준으로 정해지는 인스턴스의 인프라 규모 계층입니다. 권장 최대 사용자 수로 이름이 정해집니다(예: "Up to 3,000 users"). 계약 요구 사항에 따라 담당 계정팀이 결정합니다. 자세한 내용은 예상 부하를 참고합니다.
   • Total purchased storage: 계약과 함께 구매한 총 스토리지 용량(리포지터리 및 오브젝트 스토리지)입니다. 담당 계정팀이 미리 정합니다.

   이 설정들은 계약 내용과 계정팀 협의에 따라 미리 정해집니다.

3. Configuration 페이지에서 다음 필드를 입력합니다:

   • Tenant name: 인스턴스 URL(<tenant_name>.gitlab-dedicated.com)에 사용할 이름을 입력합니다. 사용자 지정 도메인을 구성하지 않는 한 프로비저닝 후에는 변경할 수 없습니다.
   • Primary region: 운영과 데이터 저장에 사용할 AWS 리전을 선택합니다. 모든 인프라(컴퓨팅, 스토리지, 데이터베이스)가 이 리전에 프로비저닝되므로 프로비저닝 후에는 변경할 수 없습니다.
   • Primary region Availability Zone IDs (AZ IDs): GitLab이 가용 영역을 선택하는 방식을 고릅니다:
     • Default AZ IDs(권장): GitLab이 인스턴스의 가용 영역을 선택합니다.
     • Custom AZ IDs: 기존 AWS 인프라와 일치하는 AZ ID 두 개를 선택합니다. PrivateLink 연결을 포함해 특정 가용 영역 안에서 자체 AWS 인프라를 GitLab Dedicated 인스턴스에 연결하려면 필요합니다. 프로비저닝 후에는 변경할 수 없습니다.
   • Secondary region: 선택 사항입니다. Geo 기반 재해 복구에 사용할 AWS 리전을 선택합니다. 프로비저닝 후에는 변경할 수 없습니다. Geo 마이그레이션 방식을 사용하는 경우에는 필요하지 않습니다.
   • Secondary region Availability Zone IDs (AZ IDs): 보조 리전을 구성한 경우에만 사용할 수 있습니다. GitLab이 가용 영역을 선택하는 방식을 고릅니다:
     • Default AZ IDs(권장): GitLab이 인스턴스의 가용 영역을 선택합니다.
     • Custom AZ IDs: 기존 AWS 인프라와 일치하는 AZ ID 두 개를 선택합니다. 프로비저닝 후에는 변경할 수 없습니다.
   • Backup region: 백업 복제에 사용할 AWS 리전을 선택합니다. 기본 및 보조 리전과 같아도 되고, 중복성을 높이기 위해 다르게 지정해도 됩니다. 백업 볼트와 복제가 프로비저닝 중에 구성되므로 프로비저닝 후에는 변경할 수 없습니다.
   • Maintenance window: 업데이트와 유지 관리를 위한 주간 4시간 창을 선택합니다. 선택지는 시간대(APAC, EU, US)에 맞춰져 있습니다. 자세한 내용은 GitLab Dedicated 정보 포털을 참고합니다.

4. Security 페이지에서 인스턴스의 암호화를 구성합니다.

   GitLab이 암호화 키를 자동으로 관리하거나(권장), 컴플라이언스 요구 사항에 따라 직접 키를 관리할 수 있습니다.

   [!warning] 고객 관리 암호화 키는 자체 AWS 계정에서 추가 설정과 지속적인 관리가 필요합니다. 인스턴스를 프로비저닝하기 전에 AWS KMS 키를 생성하고 구성해야 합니다. 한 번 구성하면 프로비저닝 후에는 이 설정을 변경할 수 없습니다.

   GitLab 관리 암호화(권장)의 경우:

   • 모든 AWS Key Management Service(KMS) 필드를 비워 둡니다. GitLab이 모든 서비스(백업, EBS 디스크, RDS 데이터베이스, S3 오브젝트 스토리지, 고급 검색)에 대해 암호화를 자동으로 구성합니다.

   고객 관리 암호화의 경우:

   1. 암호화 키를 생성합니다.

   2. 선택 사항입니다. Geo 기반 재해 복구를 위해 보조 리전을 선택한 경우에만 복제본 키를 생성합니다.

   3. 각 키 또는 복제본 키의 Amazon 리소스 이름(ARN)을 수집합니다. ARN 형식은 arn:aws:kms:::key/ 입니다.

      예: arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012

   4. 선택한 각 AWS 리전(기본, 보조, 백업)에 대해 다음 매핑에 따라 키 필드를 입력합니다:

      • Primary region Default: 기본 리전의 키 ARN을 사용합니다.
      • Secondary region Default: 복제본 키 ARN을 사용합니다(Geo용 보조 리전을 구성한 경우에만 해당).
      • Backup region Default: 백업 리전의 키 ARN을 사용합니다. 백업 리전이 기본 리전과 같다면 같은 키 ARN을 사용합니다.

   5. 각 서비스(Backup, EBS (disks), RDS (database), S3 (object storage), Advanced search)에 대해 해당 리전의 기본 키를 사용하려면 비워 두고, 그렇지 않으면 그 서비스에 사용할 KMS 키 ARN을 입력합니다. 서비스별 키는 해당 기본 키와 같은 AWS 리전에 있어야 합니다.

   6. 사용하지 않는 리전의 필드는 비워 둡니다. 예를 들어 기본 리전만 있다면 보조 리전과 백업 리전 필드를 비워 둡니다.

   7. 계속하기 전에 모든 ARN이 올바른지 확인합니다.

5. 선택 사항입니다. Geo migration secrets 페이지에서 GitLab Self-Managed 인스턴스의 암호화된 시크릿을 수집해 업로드합니다:

   [!note] 이 단계는 계정 설정 중에 Geo 마이그레이션을 선택한 경우에만 필요합니다.

   1. 설치 유형에 맞는 스크립트를 내려받아 GitLab Self-Managed 인스턴스에서 실행합니다.
   2. migration_secrets.json.age 파일을 업로드합니다.
   3. 선택 사항입니다. ssh_host_keys.json.age 파일을 업로드합니다(사용자 지정 도메인을 사용할 계획이라면 권장).

   자세한 지침과 문제 해결 방법은 Geo 마이그레이션 시크릿 수집을 참고합니다.

6. Tenant summary 페이지에서 모든 구성 내용을 검토합니다.

   [!warning] 다음 설정은 프로비저닝 후에 변경할 수 없습니다:

   • AWS KMS 키(BYOK) 구성
   • AWS 리전(기본, 보조, 백업 리전)
   • AWS 가용 영역 ID(기본 및 보조 리전)
   • 리포지터리 용량(늘리는 것만 가능)
   • 테넌트 이름 및 URL

7. Create tenant를 선택합니다.

인스턴스 프로비저닝에는 최대 세 시간이 걸립니다. 설정이 완료되면 확인 메일을 받습니다.

인스턴스 접속#

GitLab Dedicated 인스턴스에 접속하려면 다음 단계를 따릅니다:

1. Switchboard에 로그인합니다.

2. Access your GitLab Dedicated instance 배너에서 View credentials를 선택합니다.

3. 테넌트 URL과 임시 root 자격 증명을 복사합니다.

   [!note] 임시 root 자격 증명은 한 번만 확인할 수 있습니다. Switchboard를 벗어나기 전에 안전하게 보관합니다.

4. 테넌트 URL로 이동해 임시 root 자격 증명으로 로그인합니다.

5. 임시 root 비밀번호를 변경합니다.

6. Admin 영역에서 라이선스 키를 추가합니다.

7. Switchboard로 돌아가 필요에 따라 사용자를 추가합니다.

다음 단계#

업그레이드와 유지 관리에 대해서는 릴리스 롤아웃 일정을 검토합니다.

다음 기능이 필요하다면 미리 계획합니다:

• 인바운드 PrivateLink 연결
• 아웃바운드 PrivateLink 연결
• SAML SSO
• 사용자 지정 도메인

모든 구성 옵션은 GitLab Dedicated 인스턴스 구성을 참고합니다.