GitLab 전용 인스턴스 생성하기
이 페이지의 지침은 Switchboard인 GitLab Dedicated 포털을 사용하여 GitLab Dedicated 인스턴스의 온보딩 및 초기 설정을 안내합니다.
1단계: Switchboard에 접근하기
GitLab Dedicated 인스턴스는 Switchboard를 사용하여 설정됩니다. Switchboard에 접근하기 위해 다음 정보를 귀하의 계정 팀에 제공하십시오:
- 예상 사용자 수.
- 리포지토리의 초기 저장 용량(GB 기준).
- 온보딩을 완료하고 귀하의 GitLab Dedicated 인스턴스를 생성할 사용자들의 이메일 주소.
- 자체 암호화 키(BYOK)를 가져오고 싶은지 여부. 그렇다면 GitLab은 BYOK를 활성화하는 데 필요한 AWS 계정 ID를 제공합니다.
- 귀하의 Dedicated 인스턴스의 수신 마이그레이션을 위한 Geo 마이그레이션 사용 여부.
Switchboard에 대한 접근이 허가되면, 로그인할 수 있는 임시 자격 증명이 포함된 이메일 초대장을 받게 됩니다.
Switchboard의 자격 증명은 GitLab self-managed 또는 GitLab.com 인스턴스에 로그인하기 위해 이미 가지고 있을 수 있는 다른 GitLab 자격 증명과는 별개입니다.
처음 Switchboard에 로그인하면, 비밀번호를 업데이트하고 MFA를 설정해야 새로운 인스턴스를 생성하기 위한 온보딩을 완료할 수 있습니다.
데이터 암호화 at Rest (BYOK)
AWS KMS 키를 사용하여 GitLab 데이터를 at rest에서 암호화하도록 선택할 수 있으며, 이는 GitLab Dedicated 인프라에 접근 가능해야 합니다. 키 회전 요구 사항으로 인해, GitLab Dedicated는 AWS 관리 키 자재를 가진 키만 지원합니다 (AWS_KMS 원본 유형).
네트워크를 통해 이동 중인 데이터에 대한 암호화는 GitLab Dedicated 구성 요소에서 생성되고 관리되는 키를 사용하여 TLS로 수행되며, BYOK의 적용을 받지 않습니다.
GitLab Dedicated에서는 KMS 키를 두 가지 방법으로 사용할 수 있습니다:
- 모든 서비스에 대한 하나의 KMS 키
- 서비스별 KMS 키 (Backup, EBS, RDS, S3)
- 각 서비스에 대해 고유할 필요는 없습니다.
- 모든 서비스는 at rest에서 암호화되어야 합니다.
- 이 기능의 선택적 활성화는 지원되지 않습니다.
- 각 서비스에 대해 고유할 필요는 없습니다.
AWS에서 KMS 키 생성하기
AWS 계정 ID를 수령한 후, AWS 콘솔을 사용하여 KMS 키를 생성하십시오:
-
Configure key에서 선택합니다:- 키 유형: 대칭형
- 키 사용: 암호화 및 복호화
-
고급 옵션:- 키 자재 출처: KMS
- 지역성: 다중 지역 키
- 키 별칭, 설명 및 태그에 대한 값을 입력합니다.
- 키 관리자 선택.
- 선택 사항. 키 관리자가 키를 삭제하지 못하도록 허용하거나 방지합니다.
- 키 사용 권한 정의 페이지에서, 기타 AWS 계정 아래에 GitLab AWS 계정을 추가합니다.
마지막 페이지는 KMS 키 정책을 확인하도록 요청합니다. 다음 예와 유사해야 하며, 귀하의 계정 ID 및 사용자 이름으로 채워져야 합니다:
{
"Version": "2012-10-17",
"Id": "byok-key-policy",
"Statement": [
{
"Sid": "IAM 사용자 권한 활성화",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "키 관리자의 접근 허용",
"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": "키 사용 허용",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "지속적인 리소스 첨부 허용",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*"
}
]
}
KMS 키를 생성하고 관리하는 방법에 대한 자세한 내용은 AWS KMS 문서를 참조하십시오.
키를 생성한 후, GitLab이 귀하의 Dedicated 인스턴스에 저장된 데이터를 암호화하는 데 사용할 수 있도록 각 키의 해당 ARN을 GitLab에 보내주십시오.
AWS KMS 키가 온보딩 중에 지정된 기본, 보조 및 백업 지역에 복제되었는지 확인하십시오.
2단계: GitLab 전용 인스턴스 생성하기
Switchboard에 로그인하면 GitLab 전용 인스턴스를 생성하는 데 필요한 정보를 제공하기 위해 네 가지 단계를 거쳐야 합니다.
- 계정 세부정보 확인: GitLab 전용 계정의 주요 속성을 확인합니다:
- 테넌트 구성: GitLab 전용 인스턴스를 생성하는 데 필요한 최소 정보를 제공합니다:
- 원하는 인스턴스 서브 도메인: GitLab 전용 인스턴스의 기본 도메인은
gitlab-dedicated.com입니다. 인스턴스에 접근할 수 있는 서브도메인 이름을 선택합니다. 예:customer_name.gitlab-dedicated.com. 후속 단계에서 커스텀 호스트 이름을 추가할 수 있습니다. - 원하는 기본 지역: 데이터가 저장되는 기본 AWS 지역입니다. 사용 가능한 AWS 지역을 확인하세요.
- 원하는 보조 지역: 데이터가 저장되는 보조 AWS 지역입니다. 이 지역은 재해 발생 시 GitLab 전용 인스턴스를 복구하는 데 사용됩니다.
- 원하는 백업 지역: 데이터의 기본 백업이 복제되는 AWS 지역입니다. 기본 또는 보조 지역과 같거나 다를 수 있습니다.
- 원하는 유지 관리 창: GitLab이 모든 테넌트 인스턴스에서 정기 유지 보수 및 업그레이드 작업을 수행하는 데 사용하는 주간 4시간 시간대입니다. 더 많은 정보는 유지 관리 창을 참조하세요.
- 원하는 인스턴스 서브 도메인: GitLab 전용 인스턴스의 기본 도메인은
-
선택 사항. 보안: 암호화된 AWS 서비스를 위한 KMS 키를 제공할 수 있습니다. KMS 키를 제공하지 않으면 인스턴스가 생성될 때 암호화 키가 생성됩니다. 더 많은 정보는 데이터 암호화를 참조하세요.
- 요약: 인스턴스 생성 시작 전에 이전 단계에서 제공한 정보가 정확한지 확인합니다.
주의: 일부 구성 설정(예: 자체 키를 가져오는 옵션 및 테넌트 이름)은 영구적이며 인스턴스가 생성되면 변경할 수 없습니다.
GitLab 전용 인스턴스 생성에는 최대 3시간이 소요될 수 있습니다. 설정이 완료되면 인스턴스에 접근하는 방법에 대한 추가 지침이 포함된 확인 이메일을 받게 됩니다.
3단계: GitLab 전용 인스턴스 구성하기
GitLab 전용 인스턴스가 생성되면 다음에 대한 권장 사항을 따르세요:
다음 기능이 필요한 경우 미리 계획하세요:
알아야 할 사항
유지 보수 시간
표준 근무 시간 외에 수행되는 예약된 유지 보수 시간:
- APAC: 수요일 오후 1시 - 오후 5시 UTC
- EMEA: 화요일 오전 1시 - 오전 5시 UTC
- AMER 옵션 1: 화요일 오전 7시 - 오전 11시 UTC
- AMER 옵션 2: 일요일 오후 9시 - 월요일 오전 1시 UTC
다음의 주의 사항을 고려하세요:
-
전담 인스턴스는 유지 보수 시간 동안 전체 기간이 다운될 것으로 예상되지 않습니다. 간헐적으로, 업그레이드 후 컴퓨트 리소스가 재시작되는 동안 몇 십 초에 해당하는 작은 다운타임이 발생할 수 있습니다. 이러한 경우, 이 작은 다운타임은 일반적으로 유지 보수 시간의 전반부에 발생합니다. 장기 연결은 이 기간 동안 중단될 수 있습니다. 이를 완화하기 위해 고객은 자동 복구 및 재시도를 포함한 전략을 구현해야 합니다. 유지 보수 시간 동안의 긴 다운타임은 드물며, GitLab은 긴 다운타임이 예상될 경우 사전 통지를 제공합니다.
-
예약된 유지 보수 시간 동안 성능 저하나 다운타임이 발생하는 경우, 시스템 SLA에 대한 영향은 계산되지 않습니다.
-
매주 예약된 유지 보수 시간은 같은 주의 다른 시간으로 연기될 수 있습니다. 이 옵션은 최소 일주일 전에 지정된 고객 성공 관리자와 합의해야 합니다.
-
예약된 주간 유지 보수 시간은 긴급 유지 보수와 다릅니다.
GitLab 릴리스 출시 일정
GitLab 전담 테넌트 인스턴스는 미리 선택된 시간 내에 소규모 GitLab 릴리스로 업그레이드됩니다.
여기서 T는 소규모 GitLab 릴리스 N의 날짜입니다. GitLab 전담 인스턴스는 다음과 같이 N-1 릴리스로 업그레이드됩니다:
-
T+5일 후:
EMEA및AMER Option 1유지 보수 시간의 테넌트 인스턴스가 업그레이드됩니다. -
T+6일 후:
APAC유지 보수 시간의 테넌트 인스턴스가 업그레이드됩니다. -
T+10일 후:
AMER Option 2유지 보수 시간의 테넌트 인스턴스가 업그레이드됩니다.
예를 들어, GitLab 16.9가 2024-02-15에 출시되었습니다. 따라서 EMEA 및 AMER Option 1 유지 보수 시간의 테넌트 인스턴스는 2024-02-20에 16.8로 업그레이드됩니다.
긴급 유지 보수
플랫폼 중단, 성능 저하 또는 긴급 조치가 필요한 보안 이벤트가 발생할 경우, 긴급 유지 보수가 긴급 변경 프로세스에 따라 수행됩니다.
긴급 유지 보수는 GitLab이 전담 테넌트 인스턴스에서 실행해야 하는 긴급 조치를 시작할 때 진행됩니다. 유지 보수를 시작하기 전에 고객과의 커뮤니케이션은 최선의 노력에 따라 제공되며, 즉각적인 조치가 수행된 후에 전체 커뮤니케이션이 후속적으로 이루어집니다. GitLab 지원 팀은 새로운 티켓을 생성하고, 온보딩 중에 Switchboard에 나열된 사용자들의 이메일 주소로 메시지를 보냅니다.
예를 들어, GitLab의 S1 취약점을 해결하기 위해 중요한 보안 프로세스가 시작될 때, 긴급 유지 보수가 수행되어 GitLab이 비취약성 버전으로 업그레이드됩니다. 이는 예약된 유지 보수 시간 외에도 발생할 수 있습니다. 긴급 유지 보수를 연기하는 것은 불가능합니다. 왜냐하면 동일한 프로세스가 모든 기존 전담 고객에게 적용되어야 하며, 주요 관심사는 전담 테넌트 인스턴스의 안전성과 가용성을 보장하는 것입니다.
도움말