GitLab Dedicated 인스턴스 만들기
Offering: GitLab Dedicated
이 페이지의 지침은 Switchboard를 사용하여 GitLab Dedicated 인스턴스의 온보딩과 초기 설정을 안내합니다.
단계 1: Switchboard 액세스 권한 얻기
GitLab Dedicated 인스턴스는 Switchboard를 사용하여 설정됩니다. Switchboard 액세스를 얻으려면 계정 팀에게 다음 정보를 제공하십시오:
- 예상 사용자 수.
- 리포지터리 초기 용량(GB).
- 온보딩 및 GitLab Dedicated 인스턴스 생성을 담당하는 사용자의 이메일 주소.
- Bring Your Own Encryption Keys (BYOK)를 사용하려는지 여부. 그렇다면, BYOK 활성화에 필요한 AWS 계정 ID를 제공합니다.
- 전용 인스턴스의 입방향 마이그레이션을 위해 Geo 마이그레이션을 사용하려는지 여부.
Switchboard 액세스를 허용받으면, 임시 자격 증명이 포함된 이메일 초대장을 받게 됩니다.
Switchboard의 자격 증명은 기존의 GitLab Self-managed나 GitLab.com 인스턴스에 로그인하기 위한 다른 GitLab 자격 증명과 별도입니다.
참고:
VPN을 통해 Switchboard에 로그인하는 경우 403 Forbidden
오류가 발생할 수 있습니다. 이 때문에 VPN을 통하지 않고 직접 로그인하는 것이 해결책입니다.
Switchboard에 처음으로 로그인한 후, 새 인스턴스를 만들기 위해 온보딩을 완료하려면 암호를 업데이트하고 MFA를 설정해야 합니다.
정적 데이터 암호화 (BYOK)
참고: BYOK를 활성화하려면 온보딩 전에 해야 합니다.
AWS KMS 키를 사용하여 데이터를 정적으로(안정적으로) 암호화할 수 있으며, 이는 GitLab Dedicated 인프라에서 액세스할 수 있어야 합니다. GitLab Dedicated은 AWS 관리형 키 자료(원천 유형 AWS_KMS)를 지원합니다.
GitLab Dedicated에서 KMS 키를 사용하는 방법은 두 가지입니다:
- 모든 서비스에 대한 하나의 KMS 키
- 서비스별 KMS 키 (백업, EBS, RDS, S3)
- 키는 각 서비스마다 고유할 필요는 없습니다.
- 모든 서비스는 정적으로 암호화되어야 합니다.
- 이 기능은 선택적으로 활성화할 수 없습니다.
- 키는 각 서비스마다 고유할 필요는 없습니다.
AWS에서 KMS 키 생성
AWS 계정 ID를 받은 후, AWS 콘솔을 사용하여 KMS 키를 생성합니다:
-
키 구성
에서 다음을 선택합니다:- 키 유형: Symmetrical
- 키 사용: 암호화 및 복호화
-
고급 옵션
:- 키 자료 원천: KMS
- 지역성: 멀티-리전 키
- 키 별칭, 설명 및 태그에 대한 값을 입력합니다.
- 키 관리자를 선택합니다.
- 선택 사항. 키 관리자가 키를 삭제하는 것을 허용하거나 금지합니다.
- 키 사용 권한 규칙 정의 페이지에서 기타 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 키를 생성한 후, GitLab이 전용 인스턴스에 저장된 데이터를 암호화하는 데 사용할 각 키의 해당 ARN(Amazon 리소스 이름)을 GitLab에 전송합니다.
원하는 기본, 부차 및 백업 지역에 AWS KMS 키가 복제되어 있는지 확인하십시오. 이 지역은 온보딩 중(중간)에 지정됩니다.
단계 2: GitLab Dedicated 인스턴스 생성
Switchboard에 로그인한 후, GitLab Dedicated 인스턴스를 생성하려면 4단계의 시리즈를 거쳐야 합니다.
- 계정 정보 확인: 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에는 영향을 미치지 않습니다.
- 주간 예정된 유지 보수 창은 같은 주 내 다른 창으로 연기할 수 있습니다. 이 옵션은 할당된 고객 성공 매니저와 최소한 1주일 전에 합의해야 합니다.
- 주간 예정된 유지 보수 창은 긴급 유지 보수와 구분됩니다.
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년 02월 15일에 릴리스되었습니다. 따라서 EMEA
및 AMER 옵션 1
유지 보수 창의 테넌트 인스턴스는 2024년 04월 20일에 업그레이드됩니다.
긴급 유지 보수
플랫폼 장애, 저하 또는 긴급 조치가 필요한 보안 사건이 발생하는 경우, 긴급 유지 보수가 긴급 변경 프로세스 에 따라 진행됩니다.
긴급 유지 보수는 GitLab이 전용 테넌트 인스턴스에서 즉각적인 조치를 취해야 하는 경우에 시작됩니다. 유지 보수를 진행하기 전에 최선을 다해 고객과의 소통이 제공되며, 즉각적인 조치 이후에 전체적인 소통이 이루어집니다. GitLab 지원 팀은 온보딩 중에 Switchboard에 나열된 사용자들의 이메일 주소로 새 티켓을 생성하고 메시지를 보냅니다.
예를 들어, GitLab의 S1 취약점을 해결하기 위해 중요한 보안 프로세스가 시작된 경우, 긴급 유지 보수가 예정된 유지 보수 창 외에도 진행되어 GitLab을 취약하지 않은 버전으로 업그레이드합니다. 긴급 유지 보수를 연기하는 것은 불가능합니다. 모든 기존 전용 고객에게 동일한 과정을 적용해야 하며, 주요 관심사는 전용 테넌트 인스턴스의 안전과 가용성을 보장하는 것입니다.