InfoGrab Docs

GitLab Dedicated 인스턴스 생성

요약

GitLab Dedicated 관리 포털인 Switchboard를 사용하여 GitLab Dedicated 인스턴스를 생성합니다. 이 프로세스는 다음 단계로 구성됩니다: 자체 암호화 키를 사용하려는 경우 GitLab은 키 설정을 위한 AWS 계정 ID를 제공합니다.

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: 계약에 따라 구매한 총 저장 공간(리포지토리 및 객체 저장소). 계정 팀이 사전에 결정합니다.
    • Repository storage: 모든 리포지토리에 사용 가능한 총 저장 공간(예: 16 GiB). Evaluate 도구를 사용한 초기 용량 계획 논의를 기반으로 합니다. 프로비저닝 후 늘릴 수 있지만 줄일 수 없습니다.

    이 설정은 계약 및 계정 팀 논의에 의해 사전에 결정됩니다.

  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 Resource Name(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를 사용하여 GitLab Dedicated로 마이그레이션하기를 참조하세요.

  6. Tenant summary 페이지에서 모든 설정 세부 정보를 검토합니다.

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

    • AWS KMS 키(BYOK) 설정
    • AWS 리전(기본, 보조, 백업 리전)
    • AWS 가용성 영역 ID(기본 및 보조 리전)
    • 리포지토리 용량(늘릴 수만 있음)
    • 테넌트 이름 및 URL
  7. Create tenant를 선택합니다.

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

인스턴스 접근#

GitLab Dedicated 인스턴스에 접근하려면:

  1. Switchboard에 로그인합니다.

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

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

    [!note] 임시 루트 자격 증명은 한 번만 가져올 수 있습니다. Switchboard를 떠나기 전에 안전하게 저장하세요.

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

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

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

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

다음 단계#

업그레이드 및 유지 관리를 위한 릴리즈 롤아웃 일정을 검토합니다.

다음 기능이 필요한 경우 미리 계획하세요:

모든 설정 옵션은 GitLab Dedicated 인스턴스 설정을 참조하세요.

Note

GitLab Dedicated 인스턴스는 GitLab Self-Managed 인스턴스와 동일한 기본 설정을 사용합니다.

GitLab 18.0부터 새 인스턴스에 대해 GitLab Duo Core 기능이 기본으로 활성화됩니다. 데이터 상주 요건이나 AI 사용 정책을 준수하려면 GitLab Duo Core를 해제할 수 있습니다.

GitLab Dedicated 인스턴스 생성

Tier: Ultimate
Offering: GitLab Dedicated
원문 보기
요약

GitLab Dedicated 관리 포털인 Switchboard를 사용하여 GitLab Dedicated 인스턴스를 생성합니다. 이 프로세스는 다음 단계로 구성됩니다: 자체 암호화 키를 사용하려는 경우 GitLab은 키 설정을 위한 AWS 계정 ID를 제공합니다.

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: 계약에 따라 구매한 총 저장 공간(리포지토리 및 객체 저장소). 계정 팀이 사전에 결정합니다.
    • Repository storage: 모든 리포지토리에 사용 가능한 총 저장 공간(예: 16 GiB). Evaluate 도구를 사용한 초기 용량 계획 논의를 기반으로 합니다. 프로비저닝 후 늘릴 수 있지만 줄일 수 없습니다.

    이 설정은 계약 및 계정 팀 논의에 의해 사전에 결정됩니다.

  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 Resource Name(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를 사용하여 GitLab Dedicated로 마이그레이션하기를 참조하세요.

  6. Tenant summary 페이지에서 모든 설정 세부 정보를 검토합니다.

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

    • AWS KMS 키(BYOK) 설정
    • AWS 리전(기본, 보조, 백업 리전)
    • AWS 가용성 영역 ID(기본 및 보조 리전)
    • 리포지토리 용량(늘릴 수만 있음)
    • 테넌트 이름 및 URL
  7. Create tenant를 선택합니다.

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

인스턴스 접근#

GitLab Dedicated 인스턴스에 접근하려면:

  1. Switchboard에 로그인합니다.

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

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

    [!note] 임시 루트 자격 증명은 한 번만 가져올 수 있습니다. Switchboard를 떠나기 전에 안전하게 저장하세요.

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

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

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

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

다음 단계#

업그레이드 및 유지 관리를 위한 릴리즈 롤아웃 일정을 검토합니다.

다음 기능이 필요한 경우 미리 계획하세요:

모든 설정 옵션은 GitLab Dedicated 인스턴스 설정을 참조하세요.

Note

GitLab Dedicated 인스턴스는 GitLab Self-Managed 인스턴스와 동일한 기본 설정을 사용합니다.

GitLab 18.0부터 새 인스턴스에 대해 GitLab Duo Core 기능이 기본으로 활성화됩니다. 데이터 상주 요건이나 AI 사용 정책을 준수하려면 GitLab Duo Core를 해제할 수 있습니다.