GitLab 전용 인스턴스 만들기
이 페이지의 지침은 Switchboard를 사용하여 GitLab 전용 인스턴스의 온보딩 및 초기 설정을 안내합니다.
단계 1: Switchboard 액세스
GitLab 전용 인스턴스는 Switchboard를 사용하여 설정됩니다. Switchboard에 액세스하려면 계정 팀에게 다음 정보를 제공하십시오.
- 예상 사용자 수.
- 저장소의 초기 저장소 크기(GB).
- 온보딩을 완료하고 GitLab 전용 인스턴스를 생성할 책임이 있는 사용자의 이메일 주소.
- BYOK(데이터 안정상 암호화)를 사용하고 싶은지 여부. 그렇다면 BYOK를 활성화하려면 AWS 계정 ID가 필요합니다.
- 전용 인스턴스의 내부 이전을 위해 지오 마이그레이션을 사용하고 싶은지 여부.
Switchboard에 액세스 권한이 부여되면 임시 자격 증명이 포함된 이메일로 초대장을 받게 될 것입니다.
Switchboard의 자격 증명은 기존의 GitLab Self-Managed나 GitLab.com 인스턴스에 로그인하기 위한 다른 GitLab 자격 증명과 별도입니다.
Switchboard에 처음으로 로그인한 후에는 새 인스턴스를 만들기 위한 온보딩을 완료하기 전에 비밀번호를 업데이트하고 MFA를 설정해야 합니다.
BYOK(데이터 안정상 암호화)
참고: BYOK를 활성화하려면 온보딩 전에 수행해야 합니다. 활성화된 후에는 나중에 BYOK를 비활성화할 수 없습니다.
AWS KMS 키를 사용하여 GitLab 데이터를 안정하게 암호화할 수 있으며, 이 키는 GitLab 전용 인프라에서 액세스할 수 있어야 합니다. 키 회전 요구 사항 때문에 GitLab Dedicated는 AWS 관리형 키 자료(원천 유형인 AWS_KMS)를 지원합니다.
이동 중인 데이터(네트워크 상의 이동)의 암호화는 GitLab Dedicated 구성 요소에서 생성하고 관리하는 키를 사용하여 TLS로 수행되며, 이는 BYOK가 적용되지 않습니다.
GitLab Dedicated에서는 다음 두 가지 방법으로 KMS 키를 사용할 수 있습니다.
- 모든 서비스에 대한 하나의 KMS 키
- 서비스별 KMS 키(백업, EBS, RDS, S3)
- 키는 각 서비스마다 고유할 필요가 없습니다.
- 모든 서비스는 안정하게 암호화되어야 합니다.
- 이 기능의 선택적 사용은 지원되지 않습니다.
- 키는 각 서비스마다 고유할 필요가 없습니다.
AWS에서 KMS 키 만들기
AWS 계정 ID를 받은 후에는 AWS 콘솔을 사용하여 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에 대한 영향은 고려되지 않습니다.
- 주간 예약 유지 관리 윈도우는 동일한 주에 다른 윈도우로 연기될 수 있습니다. 이 옵션은 담당 고객 성공 매니저와 최소한 1주일 전에 합의해야 합니다.
- 주간 예약 유지 관리 윈도우는 긴급 유지 관리와 서로 다릅니다.
GitLab 릴리스 롤아웃 일정
GitLab 전용 테넌트 인스턴스는 선정된 윈도우 내에서 소수의 GitLab 릴리스로 업그레이드됩니다. 다음과 같은 일정으로 N 소규모 GitLab 릴리스의 N-1 릴리스로 업그레이드됩니다:
- T+5 달력 일:
EMEA및AMER 옵션 1유지 관리 윈도우의 테넌트 인스턴스가 업그레이드됩니다. - T+6 달력 일:
APAC유지 관리 윈도우의 테넌트 인스턴스가 업그레이드됩니다. - T+10 달력 일:
AMER 옵션 2유지 관리 윈도우의 테넌트 인스턴스가 업그레이드됩니다.
예를 들어, GitLab 16.9가 2024-02-15에 릴리스되었습니다. 따라서 EMEA 및 AMER 옵션 1 유지 관리 윈도우의 테넌트 인스턴스는 2024-02-20에 16.8로 업그레이드됩니다.
긴급 유지보수
플랫폼 장애, 저하, 또는 긴급 조치가 필요한 보안 사건이 발생한 경우, 긴급 변경 프로세스에 따라 긴급 유지보수가 진행됩니다.
긴급 유지보수는 GitLab이 전용 테넌트 인스턴스에서 즉각적인 조치가 필요할 때 시작됩니다. 유지보수를 시작하기 전에는 최선을 다해 고객과의 커뮤니케이션이 제공되며, 즉각적인 조치 후에는 완전한 커뮤니케이션이 이루어집니다. GitLab 지원팀은 온보딩 중 Switchboard에 등록된 사용자들의 이메일 주소로 새 티켓을 생성하고 메시지를 보냅니다.
예를 들어, GitLab의 S1 취약점에 대한 중요한 보안 프로세스가 시작되면, GitLab을 취약하지 않은 버전으로 업그레이드하기 위해 긴급 유지보수가 진행되며, 이는 예정된 유지보수 창 외에도 발생할 수 있습니다. 긴급 유지보수를 연기하는 것은 불가능합니다. 왜냐하면 동일한 프로세스가 모든 전용 고객에게 적용되어야 하며, 주요 우려사항은 전용 테넌트 인스턴스의 안전 및 가용성을 보장하는 것입니다.
도움말