GitLab 전용 인스턴스 생성
이 페이지의 지침은 Switchboard를 사용하여 GitLab 전용 인스턴스의 온보딩 및 초기 설정을 안내합니다.
단계 1: Switchboard에 액세스하세요
귀하의 GitLab 전용 인스턴스는 Switchboard를 사용하여 설정됩니다. Switchboard에 액세스하려면 계정 팀에게 다음 정보를 제공하세요:
- 예상 사용자 수.
- GB 단위의 저장소 초기 용량.
- 온보딩을 완료하고 귀하의 GitLab 전용 인스턴스를 생성할 책임이 있는 사용자의 이메일 주소.
- BYOK(본인 키 가져오기)를 사용하려는지 여부. 그렇다면 BYOK를 활성화하려면 필요한 AWS 계정 ID를 GitLab이 제공합니다.
- 전용 인스턴스의 인바운드 마이그레이션을 위해 Geo 마이그레이션을 사용하려는지 여부.
Switchboard에 액세스 권한이 부여되면 임시 자격 증명을 통해 이메일로 초대장을 받게 됩니다.
Switchboard의 자격 증명은 GitLab self-managed나 GitLab.com 인스턴스에 로그인하는 데 사용되는 다른 GitLab 자격 증명과는 별도입니다.
참고:
VPN을 통해 Switchboard에 로그인하면 403 Forbidden 오류가 발생할 수 있습니다. 해결 방법은 VPN을 통하는 대신 직접 로그인하는 것입니다.
Switchboard에 처음 로그인한 후에는 새로운 인스턴스를 만들기 위해 온보딩을 완료하기 전에 암호를 업데이트하고 MFA를 설정해야 합니다.
안정적인 데이터 암호화 (BYOK)
참고: BYOK를 활성화하려면 온보딩 이전에 수행해야 합니다.
AWS KMS 키를 사용하여 GitLab 데이터를 안정적으로 암호화할 수 있으며, 이 키는 GitLab 전용 인프라에서 접근 가능해야 합니다. GitLab 전용은 AWS 관리형 키 자료(원본 유형인 AWS_KMS)을 지원합니다.
GitLab 전용에서 KMS 키를 다음 두 가지 방법으로 사용할 수 있습니다:
- 모든 서비스에 대한 단일 KMS 키
- 서비스별 KMS 키 (백업, EBS, RDS, S3)
- 각 서비스에 대해 고유한 필요는 없습니다.
- 모든 서비스는 안정적으로 암호화되어야 합니다.
- 이 기능을 선택적으로 활성화하는 것은 지원되지 않습니다.
- 각 서비스에 대해 고유한 필요는 없습니다.
AWS에서 KMS 키 생성
AWS 콘솔을 사용하여 AWS 계정 ID를 수신한 후, KMS 키를 생성하세요:
-
키 구성에서 다음을 선택하세요:- 키 유형: 대칭
- 키 사용: 암호화 및 복호화
-
고급 옵션:- 키 자료 원본: 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 문서를 참조하세요.
키를 생성한 후에는 해당 키의 ARN을 GitLab에 보내어 GitLab이 전용 인스턴스에 저장된 데이터를 암호화하는 데 사용할 수 있도록 해야 합니다.
AWS KMS 키가 온보딩 중에 지정된 주요, 보조 및 백업 지역에 복제되었는지 확인하세요(단계 2: GitLab 전용 인스턴스 생성하기).
단계 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-04-20에 업그레이드됩니다.
긴급 유지 보수
플랫폼 장애, 저하 또는 긴급 조치가 필요한 보안 이벤트 발생 시, 긴급 유지 보수가 수행됩니다. 긴급 유지 보수는 긴급 변경 프로세스 에 따라 적용됩니다.
긴급 유지 보수는 GitLab이 전용 테넌트 인스턴스에서 긴급 조치를 취해야 할 때 시작됩니다. 유지 보수를 시작하기 전에 고객과의 커뮤니케이션은 최선을 다해 제공되며, 즉각적인 조치 후에 완전한 커뮤니케이션을 이어갈 것입니다. GitLab 지원팀은 온보딩 과정에서 Switchboard에 나열된 사용자들의 이메일 주소로 새 티켓을 생성하고 메시지를 보냅니다.
예를 들어, GitLab의 S1 취약점을 해결하기 위해 중요한 보안 프로세스가 시작되면, 긴급 유지 보수를 진행하여 GitLab을 취약하지 않은 버전으로 업그레이드합니다. 이는 예정된 유지 보수 창 외에 발생할 수 있습니다. 긴급 유지 보수를 연기하는 것은 불가능합니다, 왜냐하면 동일한 프로세스가 모든 기존 전용 고객에게 적용되어야 하며, 주요 관심사는 전용 테넌트 인스턴스의 안전과 가용성을 보장하는 것입니다.
도움말