GitLab Dedicated 인스턴스 생성
이 페이지의 지침은 Switchboard인 GitLab Dedicated 포털을 사용하여 GitLab Dedicated 인스턴스의 온보딩 및 초기 설정을 안내합니다.
단계 1: Switchboard에 액세스
GitLab Dedicated 인스턴스는 Switchboard를 사용하여 설정됩니다. Switchboard에 액세스하려면, 다음 정보를 계정 팀에 제공하십시오.
- 예상 사용자 수.
- 리포지터리의 초기 리포지터리 크기 (GB).
- 온보딩을 완료하고 GitLab Dedicated 인스턴스를 생성하는 데 책임이 있는 사용자의 이메일 주소.
- 복호화 키를 직접 사용하려면 Bring Your Own Encryption Keys (BYOK)을 사용하고자 하는지 여부. 그렇다면, BYOK를 활성화하는 데 필요한 AWS 계정 ID를 GitLab이 제공합니다.
- 전용 인스턴스의 인바운드 마이그레이션에 대한 Geo 마이그레이션을 사용하려는지 여부.
Switchboard에 액세스 권한이 부여된 경우, 임시 자격 증명을 사용하여 이메일 초대장을 수신하게 됩니다.
Switchboard의 자격 증명은 GitLab의 Self-Managed형이나 GitLab.com 인스턴스에 로그인하는 데 사용하는 다른 GitLab 자격 증명과는 별도입니다.
403 Forbidden 오류가 발생할 수 있습니다. 해결 방법은 VPN을 통하지 않고 직접 로그인하는 것입니다.Switchboard에 처음으로 로그인한 후에는 새로운 인스턴스를 생성하기 위해 온보딩을 완료하기 전에 비밀번호를 업데이트하고 MFA를 설정해야 합니다.
데이터 안 Rest 암호화 (BYOK)
AWS KMS 키를 사용하여 GitLab 데이터를 안 Rest에서 암호화할 수 있으며, 이는 GitLab Dedicated 인프라에서 액세스할 수 있어야 합니다. GitLab Dedicated은 AWS 관리형 키 재료(AWS_KMS 원형 유형)를 지원합니다.
GitLab Dedicated에서 KMS 키를 두 가지 방법으로 사용할 수 있습니다.
- 모든 서비스에 대한 하나의 KMS 키
- 서비스별 KMS 키 (백업, EBS, RDS, S3)
- 각 서비스에 고유해야 할 필요는 없습니다.
- 모든 서비스는 정지하는 암호화해야 합니다.
- 이 기능의 선택적 활성화는 지원되지 않습니다.
- 각 서비스에 고유해야 할 필요는 없습니다.
AWS에서 KMS 키 만들기
AWS 계정 ID를 수신한 후, AWS 콘솔을 사용하여 KMS 키를 만듭니다.
-
키 구성에서 다음을 선택합니다:- 키 유형: 대칭
- 키 사용법: 암호화 및 복호화
-
고급 옵션:- 키 재료 원형: KMS
- 지역성: 다중 지역 키
- 키 별칭, 설명 및 태그에 대한 값 입력
- 키 관리자 선택
- 선택 사항. 키 관리자가 키를 삭제할 수 있는지 여부를 허용하거나 방지합니다.
- 다른 AWS 계정 아래 기타 AWS 계정 페이지에서 GitLab AWS 계정을 추가합니다.
마지막 페이지에서 KMS 키 정책을 확인하라는 메시지가 표시됩니다. 다음 예제와 유사한 모습을 해야 하며, 귀하의 계정 ID 및 사용자 이름으로 채워져야 합니다.
{
"Version": "2012-10-17",
"Id": "byok-key-policy",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrators",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:user/<CUSTOMER-USER>"
]
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion",
"kms:ReplicateKey",
"kms:UpdatePrimaryRegion"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*"
}
]
}
KMS 키를 만들고 관리하는 자세한 내용은 AWS KMS 문서를 참조하십시오.
키를 만든 후에는 해당 키의 ARN을 GitLab에 보내어 GitLab이 전용 인스턴스에 저장된 데이터를 암호화하는 데 사용할 수 있도록 해야 합니다.
AWS KMS 키가 온보딩 중에 지정된 주요, 보조 및 백업 지역으로 복제되었는지 확인하십시오. (단계 2: GitLab Dedicated 인스턴스 생성 참조)
단계 2: GitLab Dedicated 인스턴스 생성
Switchboard에 로그인한 후, GitLab Dedicated 인스턴스를 만들기 위해 다음의 네 가지 단계를 거쳐야 할 것입니다.
- 계정 세부 정보 확인: GitLab Dedicated 계정의 주요 속성을 확인합니다.
- 테넌트 구성: GitLab Dedicated 인스턴스를 만드는 데 필요한 최소한의 정보를 제공합니다.
- 원하는 인스턴스 서브도메인: GitLab Dedicated 인스턴스의 본 도메인은
gitlab-dedicated.com입니다. 여기에서 인스턴스에 액세스할 수 있는 서브도메인 이름을 선택합니다. 예:customer_name.gitlab-dedicated.com. - 원하는 주요 지역: 데이터가 저장되는 주요 AWS 지역입니다. 사용 가능한 AWS 지역을 확인하십시오.
- 원하는 보조 지역: 재해 시 GitLab Dedicated 인스턴스를 복구하는 데 사용되는 보조 AWS 지역입니다.
- 원하는 백업 지역: 데이터의 주요 백업이 복제되는 AWS 지역입니다. 이는 주요 지역이나 보조 지역과 동일하거나 다를 수 있습니다.
- 원하는 유지 보수 창: GitLab이 모든 테넌트 인스턴스에 대한 일반적인 유지 보수 및 업그레이드 작업을 수행하기 위해 주간 4시간의 시간대를 제공합니다. 자세한 내용은 유지 보수 창을 참조하십시오.
- 원하는 인스턴스 서브도메인: GitLab Dedicated 인스턴스의 본 도메인은
- 보안: 암호화된 AWS 서비스를 위해 직접 KMS 키를 제공할 수 있습니다. KMS 키를 제공하지 않을 경우, 인스턴스 생성 시 암호화 키가 생성됩니다. 자세한 내용은 데이터 보안 암호화를 참조하십시오.
- 요약: 이전 단계에서 제공한 정보가 정확한지 확인한 후 인스턴스 생성을 시작하기 전에 확인합니다.
GitLab Dedicated 인스턴스를 생성하는 데 최대 3시간이 소요될 수 있습니다. 설정이 완료되면 인스턴스에 액세스하는 방법에 대한 추가 지침이 포함된 확인 이메일을 받게 됩니다.
단계 3: GitLab Dedicated 인스턴스 구성
GitLab Dedicated 인스턴스가 생성되면 다음에서 권장하는 대로 진행하십시오:
또한 다음 기능이 필요한 경우 미리 계획하세요:
알아둘 점
유지 보수 창구
표준 근무 시간 이외에 수행되는 예약된 유지 보수 창구:
- APAC: 수요일 1 PM - 5 PM UTC
- EMEA: 화요일 1 AM - 5 AM UTC
- AMER 옵션 1: 화요일 7 AM - 11 AM UTC
- AMER 옵션 2: 일요일 9 PM - 월요일 1 AM UTC
다음 사항을 고려하세요:
- 전용 인스턴스는 유지 보수 창구 전체 기간 동안 다운되지 않을 것으로 예상됩니다. 때때로 업그레이드 후에 컴퓨팅 리소스가 다시 시작될 때 다운타임이 발생할 수 있습니다(보통 몇 십 초 정도). 이러한 다운타임은 주로 유지 보수 창구의 전반부에서 발생합니다. 이 기간에 장기간 실행 중인 연결은 중단될 수 있습니다. 이를 완화하기 위해 클라이언트는 자동 복구 및 재시도와 같은 전략을 구현해야 합니다. 유지 보수 창구 중의 장기간 다운타임은 드물며, 긴 다운타임이 예상될 경우 GitLab에서 알림을 제공합니다.
- 예약된 유지 보수 창구 기간 중 성능 저하 또는 다운타임이 발생하는 경우, 시스템 SLA에는 영향이 없습니다.
- 주간 예약된 유지 보수 창구는 동일한 주 내 다른 창구로 연기될 수 있습니다. 이 옵션은 최소 한 주 전에 지정된 고객 성공 담당자와 합의되어야 합니다.
- 예약된 주간 유지 보수 창구는 긴급 유지 보수와 다릅니다.
GitLab 릴리즈 배포 일정
GitLab Dedicated 테넌트 인스턴스는 마이너 GitLab 릴리스를 다음 일정에 따라 업그레이드합니다.
여기서 T는 마이너 GitLab 릴리스 N의 날짜입니다. GitLab Dedicated 인스턴스는 다음과 같이 N-1 릴리스로 업그레이드됩니다:
- T+5 달력 일:
EMEA및AMER 옵션 1유지 보수 창구의 테넌트 인스턴스가 업그레이드됩니다. - T+6 달력 일:
APAC유지 보수 창구의 테넌트 인스턴스가 업그레이드됩니다. - T+10 달력 일:
AMER 옵션 2유지 보수 창구의 테넌트 인스턴스가 업그레이드됩니다.
예를 들어, GitLab 16.9가 2024년 2월 15일에 릴리스되었습니다. 따라서 EMEA 및 AMER 옵션 1 유지 보수 창구의 테넌트 인스턴스는 2024년 2월 20일에 16.8 버전으로 업그레이드됩니다.
긴급 유지 보수
플랫폼 장애, 저하 또는 긴급 조치가 필요한 보안 사건 발생 시 긴급 유지 보수가 긴급 변경 프로세스에 따라 수행됩니다.
긴급 유지 보수는 GitLab이 전용 테넌트 인스턴스에서 즉각적으로 실행해야 하는 조치가 필요할 때 시작됩니다. 유지 보수를 시작하기 전에 고객과의 커뮤니케이션은 최선을 다해 제공하며, 즉각적인 조치 이후 전체적인 커뮤니케이션도 이어집니다. GitLab 지원팀은 온보딩 중에 Switchboard에 나열된 사용자의 이메일 주소로 새 티켓을 만들고 메시지를 보냅니다.
예를 들어, GitLab의 S1 취약점을 해결하기 위해 중요한 보안 프로세스가 시작되면, 긴급 유지 보수가 예약된 유지 보수 창구 외에 시행되어 GitLab을 취약하지 않은 버전으로 업그레이드됩니다. 긴급 유지 보수를 연기하는 것은 불가능합니다. 왜냐하면 동일한 프로세스가 모든 기존 전용 고객에게 적용되어야 하며, 주요 관심사는 전용 테넌트 인스턴스의 안전 및 가용성을 보장하는 것입니다.
도움말