GitLab Dedicated 인스턴스 구성

Tier: Ultimate Offering: GitLab Dedicated

이 페이지의 지침은 GitLab Dedicated 인스턴스를 구성하는 과정을 안내합니다. 이 과정에는 사용 가능한 기능을 활성화하고 업데이트하는 것도 포함됩니다.

SaaS 환경에서 제어되지 않는 GitLab 애플리케이션의 모든 기능은 관리자 영역을 사용하여 구성할 수 있습니다.

SaaS 환경 설정의 예로는 gitlab.rb 구성 및 셸, Rails 콘솔, 그리고 PostgreSQL 콘솔 액세스 등이 있습니다. 이러한 환경 설정은 테넌트가 변경할 수 없습니다.

GitLab Dedicated 엔지니어는 긴급 상황을 제외하고 테넌트 환경에 직접 액세스할 수 없습니다.

note
인스턴스는 GitLab Dedicated 배포를 가리키며, 테넌트는 고객을 가리킵니다.

구성 변경

구성 변경 정책

지원 티켓을 통해 요청된 구성 변경은 환경의 주간 4시간 정기 유지 관리 창에서 일괄적으로 적용됩니다.

이 정책은 Switchboard를 사용하여 GitLab Dedicated 인스턴스 관리자가 만든 구성 변경에는 적용되지 않습니다.

다가올 주간 유지 관리 창을 고려하여 변경 사항이 해당 창의 시작일의 2영업일 전까지 전체 필요 정보를 제출해야 합니다.

최소 전대 시간을 충족하더라도 다가올 주간 유지 관리 창에서 구성 변경이 적용되지 않을 수 있습니다. GitLab이 유지 관리 창을 벗어난 상태에서 고우선 순위 유지 보수 작업을 수행해야 하는 경우 구성 변경은 다음 주로 연기됩니다.

긴급 지원과 관련하여 긴급 지원을 받을 수 있는 경우를 제외하고 지원 티켓을 통해 요청된 변경 사항은 주간 유지 관리 창 외에는 적용되지 않습니다.

Switchboard의 구성 변경

Switchboard를 사용하면 사용자가 제한적인 구성 변경을 GitLab Dedicated 인스턴스에 적용할 수 있습니다. Switchboard가 더욱 성숙해지면 추가 구성 변경이 가능해질 것입니다.

GitLab Dedicated 인스턴스 구성을 변경하거나 업데이트하려면 관련 섹션의 지침에 따라 Switchboard를 사용하거나 지원 티켓을 열어야 합니다.

Switchboard를 사용하여 적용된 구성 변경은 즉시 적용되거나 다음 예정된 주간 유지 관리 창까지 연기될 수 있습니다.

즉시 적용된 변경은 최대 90분이 소요될 수 있습니다. 각 변경은 저장된 순서대로 적용되며 묶어서 한 번에 적용하기 전에 여러 변경을 저장할 수도 있습니다. 변경이 배포되면 이메일 알림을 받게 됩니다. 주요 이메일함이 아니라면 스팸 메일함을 확인해야 할 수도 있습니다.

Switchboard의 테넌트를 보거나 편집할 수 있는 모든 사용자는 각 변경에 대한 알림을 받게 됩니다. Switchboard 통지 기본 설정을 관리하는 방법을 확인하세요.

note
Switchboard 테넌트 관리자가 한 변경은 이메일 알림을 받게 됩니다. GitLab 운영자(예: 유지 보수 창에서 완료된 GitLab 버전 업데이트)가 한 변경은 이메일 알림이 생성되지 않습니다.

구성 변경 로그 보기

구성 변경 로그를 사용하여 GitLab Dedicated 인스턴스에 대한 변경 사항을 추적할 수 있습니다. 변경 로그에는 다음이 포함됩니다.

  • 구성 변경: 변경된 구성 설정의 이름입니다.
  • 사용자: 구성 변경을 한 사용자의 이메일 주소입니다. GitLab 운영자가 변경을 한 경우 이 값은 GitLab 운영자로 표시됩니다.
  • IP: 구성 변경을 한 사용자의 IP 주소입니다. GitLab 운영자가 변경을 한 경우 이 값은 사용 불가능으로 표시됩니다.
  • 상태: 구성 변경이 시작되었는지, 진행 중인지, 완료되었는지, 연기되었는지를 나타냅니다.
  • 시작 시간: 구성 변경이 시작된 UTC 날짜 및 시간입니다.
  • 종료 시간: 구성 변경이 배포된 UTC 날짜 및 시간입니다.

각 구성 변경에는 상태가 있습니다.

  • 시작됨: Switchboard에서 구성 변경이 이뤄졌지만 아직 인스턴스에 배포되지 않은 상태입니다.
  • 진행 중: 구성 변경이 현재 인스턴스에 배포 진행 중인 상태입니다.
  • 완료됨: 구성 변경이 인스턴스에 배포된 상태입니다.
  • 지연됨: 초기 작업에서 변경을 배포하지 못하고 새 작업으로 할당되지 않은 상태입니다.

구성 변경 로그 보기 방법:

  1. Switchboard에 로그인합니다.
  2. 테넌트를 선택합니다.
  3. 페이지 상단에서 구성 변경 로그를 선택합니다.

인바운드 프라이빗 링크

AWS Private Link를 사용하면 AWS의 VPC에 있는 사용자 및 응용 프로그램이 공개 인터넷 트래픽 없이 GitLab Dedicated 엔드포인트에 안전하게 연결할 수 있습니다.

인바운드 프라이빗 링크를 활성화하기 위해:

  1. 지원 티켓을 엽니다. 지원 티켓의 본문에는 AWS 조직의 IAM 사용자 또는 역할을 설정하는 IAM 주체를 포함해야 합니다. IAM 주체는 IAM 역할 주체 또는 IAM 사용자 주체여야 합니다. GitLab Dedicated은 이 IAM 주체를 액세스 제어에 사용합니다. 이 IAM 주체만 서비스 엔드포인트를 설정할 수 있습니다.
  2. IAM 주체가 화이트리스트 처리된 후, GitLab은 지원 티켓에서 서비스 엔드포인트 이름을 전달합니다. 서비스 이름은 AWS가 서비스 엔드포인트를 생성할 때 생성됩니다.
    • GitLab은 Private DNS 이름의 도메인 검증을 처리하여 VPC 내 인스턴스 도메인 이름의 DNS 해상도를 PrivateLink 엔드포인트에 해상될 수 있도록합니다.
    • GitLab은 초기 온보딩 과정에서 지정한 사용 가능한 가용 영역에 엔드포인트 서비스를 사용할 수 있도록 설정합니다. 가용 영역을 지정하지 않은 경우, GitLab은 무작위로 가용 영역 ID를 선택합니다.
  3. 자체 AWS 계정에서 VPC에 엔드포인트 인터페이스를 생성합니다. 다음과 같은 설정을 사용합니다.
    • 서비스 엔드포인트 이름: 지원 티켓에서 GitLab이 제공하는 이름을 사용합니다.
    • Private DNS 이름 활성화: 예.
    • 서브넷: 일치하는 모든 서브넷을 선택합니다.
    1. 엔드포인트를 생성한 후, 온보딩 중에 제공된 인스턴스 URL을 사용하여 공개 인터넷 트래픽 없이 VPC에서 GitLab Dedicated 인스턴스에 안전하게 연결할 수 있습니다.

아웃바운드 프라이빗 링크

note
환경에 프라이빗링크 연결(인바운드 또는 아웃바운드)을 추가하는 계획이 있고 연결을 특정 사용 가능한 영역에 사용할 경우, 온보딩 중에 계정팀에 가용 영역 ID 최대 두 개를 제공해야 합니다. 지정하지 않았을 경우, GitLab은 연결이 가능한 무작위 두 개의 가용 영역 ID를 선택합니다.

아웃바운드 프라이빗 링크를 사용할 때 다음을 고려하세요:

  • 아웃바운드 프라이빗 링크를 통해 GitLab Dedicated 인스턴스는 AWS의 VPC에서 실행되는 서비스와 안전하게 통신할 수 있습니다. 이러한 유형의 연결은 웹훅, VPC에서 실행되는 대상 서비스를 사용하는 프로젝트 및 리포지터리 가져오기 또는 미러, 또는 다른 GitLab 기능을 사용하여 개인 서비스에 액세스하는 등의 작업을 실행할 수 있습니다.
  • VPC 간에만 프라이빗링크를 설정할 수 있습니다. 따라서 전용 인스턴스의 선택한 지역에서만 연결을 설정할 수 있습니다.
  • 당신의 엔드포인트 서비스를 지원하는 네트워크 로드 밸런서(NLB)는 당신의 전용 인스턴스가 배포된 최소한 하나의 가용성 영역에서 활성화되어야 합니다. 이것은 us-east-1a와 같은 사용자가 직접 볼 수 있는 이름이 아닌 내에 있는 가용 영역 ID입니다. 온보딩 중에 지정하지 않은 경우 이 옵션을 사용하기 위해, 연결을 활성화하기 위해 발생한 티켓에서 가용 영역 ID를 요청하거나, NLB가 해당 가용 영역에서 활성화되도록 보장해야 합니다.

Switchboard의 테넌트 세부 정보 섹션에서 반대 프라이빗링크 IAM 주체 속성을 볼 수 있습니다.

아웃바운드 프라이빗링크를 활성화하려면:

  1. 내부 서비스를 GitLab Dedicated에서 사용 가능하도록 하는 서비스 엔드포인트 생성합니다. 연결되는 서비스 엔드포인트 이름을 지원 티켓에서 제공합니다.
  2. 지원 티켓에서 GitLab은 엔드포인트 서비스에 대한 연결을 시작할 IAM 역할의 ARN을 제공합니다. 이 ARN이 연결 서비스의 “허용된 주체” 디렉터리에 포함되도록 해야 하고, 예를 들어 AWS 문서에서 설명한 내용 중 하나로 다루어져야 합니다. 선택 사항이지만, 명시적으로 추가하여 수락 필요를 아니요로 설정하여 단일 작업에서 Dedicated가 연결할 수 있도록 하는 것이 좋습니다. 수락 필요를 예로 둔 경우 Dedicated가 연결을 시작한 후 연결을 매뉴얼으로 수락해야 합니다.
  3. 엔드포인트를 사용하기 위해 엔드포인트를 사용하는 서비스에 연결하려면 전용 서비스는 DNS 이름이 요구됩니다. Private Link는 자동으로 내부 이름을 생성하지만 일반적으로 바로 사용할 수 없습니다. 사용 가능한 옵션으로는 다음이 있습니다.
    • 서비스 엔드포인트에서 개인 DNS 이름 활성화하고 필요한 검증을 수행하고 이 옵션을 사용한다고 지원 티켓에서 알립니다. 만약 수락 필요를 예로 설정한 경우, 이 엔드포인트 서비스를 사용하기 위해 Dedicated가 연결을 수행한 후 당신이 수락한 후에 연결을 업데이트하여 프라이빗 DNS를 사용할 수 있도록 합니다.
    • Dedicated가 Dedicated AWS Account 내에서 프라이빗 호스팅 영역(PHZ)을 관리하고 임의의 DNS 이름을 Endpoint에 별칭을 지정하여 해당 이름을 Endpoint 서비스로 전송합니다. 이 옵션을 사용하는 경우 지원 티켓에서 이 옵션을 사용하고 만약 필요한 경우 PHZ를 업데이트할 DNS 이름 디렉터리을 제공합니다.

GitLab은 당신이 제공하는 서비스 이름을 기반으로 테넌트 인스턴스의 엔드포인트 인터페이스를 구성합니다. 테넌트 인스턴스에서 수행된 일치하는 아웃바운드 연결은 프라이빗링크를 통해 당신의 VPC로 연결됩니다.

사용자 정의 인증서

어떤 경우에는 GitLab Dedicated 인스턴스가 내부 서비스에 액세스할 수 없을 수 있습니다. 왜냐하면 해당 서비스가 공인 인증 기관(CA)을 통해 확인할 수 없는 인증서를 노출하기 때문입니다. 이러한 경우에는 사용자 정의 인증서가 필요합니다.

Switchboard를 사용하여 사용자 정의 인증서 추가

  1. Switchboard에 로그인합니다.
  2. 페이지 상단에서 Configuration을 선택합니다.
  3. Custom Certificate Authorities를 확장합니다.
  4. + Add Certificate을 선택합니다.
  5. 인증서를 텍스트 상자에 붙여넣습니다.
  6. Save를 선택합니다.
  7. 페이지 상단으로 스크롤하여 변경 사항을 즉시 적용할지 또는 다음 유지 보수 창으로 적용할지 선택합니다.

Support 요청을 통한 사용자 정의 인증서 추가

GitLab Dedicated 인스턴스가 PrivateLink를 통해 귀사의 서비스와 통신할 때 GitLab에게 사용자 정의 인증서를 추가해달라고 요청하려면, 사용자 정의 공개 인증서 파일을 귀사의 지원 티켓에 첨부하세요.

GitLab Dedicated는 리버스 PrivateLink 연결 개수를 10개로 제한합니다.

인스턴스에 사용자 추가

관리자는 GitLab Dedicated 인스턴스에 Switchboard 사용자를 추가할 수 있습니다. 사용자 유형은 두 가지가 있습니다:

  • 읽기 전용: 사용자는 인스턴스 데이터만 볼 수 있습니다.
  • 관리자: 사용자는 인스턴스 구성을 편집하고 사용자를 관리할 수 있습니다.

GitLab Dedicated 인스턴스에 새 사용자를 추가하려면:

  1. 테넌트 페이지에서 테넌트 인스턴스 옆의 관리를 선택합니다.
  2. 페이지 상단에서 사용자를 선택합니다.
  3. 새 사용자를 선택합니다.
  4. 이메일을 입력하고 사용자의 역할을 선택합니다.
  5. 생성을 선택합니다.

Switchboard 사용을 위한 초대장이 사용자에게 전송됩니다.

알림 설정 관리

Switchboard에서 이메일 알림을 수신할 지 여부를 지정할 수 있습니다.

자체 이메일 알림 설정을 관리하려면:

  1. 모든 페이지에서 사용자 이름 옆의 드롭다운을 엽니다.
  2. 이메일 알림을 받지 않으려면 이메일 알림 끄기를 선택합니다.
  3. 이메일 알림을 다시 받으려면 이메일 알림 켜기를 선택합니다.

알림 설정이 업데이트되었음을 확인하는 경고가 표시됩니다.

Switchboard 테넌트 관리자는 자신의 조직 테넌트에 액세스 권한이 있는 다른 사용자의 이메일 알림도 관리할 수 있습니다:

  1. 사용자 페이지에서 해당 사용자 이메일 옆의 이메일 알림 열을 엽니다.
  2. 해당 사용자의 이메일 알림을 해제하려면 아니요를 선택합니다.
  3. 해당 사용자의 이메일 알림을 켜려면 예를 선택합니다.

알림 설정이 업데이트되었음을 확인하는 경고가 표시됩니다.

애플리케이션 로그 액세스

GitLab 애플리케이션 로그는 GitLab 테넌트 계정의 S3 버킷으로 전송되어 여러분과 공유될 수 있습니다. S3 버킷에 저장된 로그는 1년 보존 정책이 완전히 시행될 때까지 무기한 유지됩니다. GitLab 팀원들은 이 비밀 문제에서 더 많은 정보를 볼 수 있습니다: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/483.

이 버킷의 읽기 전용 액세스를 얻으려면:

  1. “고객 로그 액세스”라는 제목의 지원 티켓을 엽니다. 티켓 내용에는 S3에서 로그를 가져오는 IAM 주요 ARN(사용자 또는 역할) 디렉터리을 포함하십시오.
  2. GitLab에서 여러분에게 S3 버킷 이름을 알려드립니다. 여러분이 지명한 사용자/역할은 이후에 S3 버킷에서 모든 객체를 나열하고 가져올 수 있게 됩니다.

여러분은 AWS CLI를 사용하여 S3 버킷에 대한 액세스가 예상대로 작동하는지 확인할 수 있습니다.

버킷 내용 및 구조

S3 버킷에는 GitLab 로그 시스템의 인프라 로그와 애플리케이션 로그가 혼합되어 있습니다. 버킷에 저장된 로그는 GitLab에서 관리하는 AWS KMS 키를 사용하여 암호화됩니다. BYOK를 활성화하는 경우, 제공하는 키로 애플리케이션 로그가 암호화되지 않습니다.

S3 버킷의 로그는 YYYY/MM/DD/HH 형식으로 날짜별로 구성됩니다. 예를 들어 2023/10/12/13과 같은 디렉터리는 2023년 10월 12일 13시의 로그를 포함합니다. 로그는 Amazon Kinesis Data Firehose를 통해 버킷으로 스트리밍됩니다.