• 요약
• 목표
• 제안
  • 용어
  • 지원 수준
    • 레벨 1
    • 레벨 2
    • 레벨 3
    • 레벨 4
    • 레벨 5
  • 디자인 개요
  • 구현 세부 정보

다중 데이터베이스 지원

요약

이 문서는 컴포넌트를 하나 이상의 데이터베이스로 지원하는 방법을 설명합니다. 권장 배포 모델의 여러 도전을 극복하기 위해 각 수준에 대한 서로 다른 지원 수준을 설명하고 구현 모델을 제공합니다.

아키텍처 페이지에서는 이 주제에 대한 백그라운드 정보를 제공합니다.

개발 문서가 이 청사진을 돕습니다. 이 문서에서는 구현 모델을 상세히 설명하고 몇 가지 예시를 제시합니다.

목표

• 현재 및 새로운 컴포넌트에 대해 더 높은 수준의 지원을 제공합니다.
• 구현 리팩터는 현재 gitlab.rb에 이미 있는 구성 옵션을 유지하도록 합니다.
• 일관되고 테스트 가능하며 확장 가능한 구현 모델을 통해 데이터베이스 코드의 파괴적인 변경 및 리팩터를 최소화합니다.
• 코드를 새로운 구현 방법으로 이관합니다.

제안

용어

용어	정의
데이터베이스	Rails 애플리케이션과 같은 컴포넌트가 사용하는 gitlabhq_production과 같은 데이터베이스의 논리적 데이터베이스입니다. 컴포넌트는 하나 이상의 데이터베이스를 가질 수 있습니다.
데이터베이스 서버	포스트그레SQL 데이터베이스 서비스를 제공하는 독립 프로세스 또는 _클러스터_입니다. 데이터베이스 객체나 데이터와는 혼동해서는 안됩니다.
데이터베이스 객체	DATABASE, SCHEMA, ROLE, 또는 FUNCTION과 같은 데이터 정의 언어(DDL)로 생성된 모든 것을 의미합니다. 참조 데이터나 인덱스도 포함될 수 있습니다. 이러한 객체들은 일부가 Omnibus GitLab에 의해 생성되며 나머지는 컴포넌트별 _데이터베이스 마이그레이션_에 의해 생성됩니다.
독립 데이터베이스 서버	단일 포스트그레SQL 데이터베이스 서버입니다. PgBouncer 인스턴스를 통해 접근할 수 있습니다.
데이터베이스 서버 클러스터	여러 포스트그레SQL 데이터베이스 서버를 포괄하며, Patroni 서비스에 의해 관리되며, Consul 클러스터에서 지원되며, 하나 이상의 PgBouncer 인스턴스를 통해 접근할 수 있으며, 프론트엔드로 HAProxy(일반적으로 TCP 모드)가 포함될 수 있습니다.

지원 수준

Omnibus GitLab 컴포넌트에는 다른 수준의 데이터베이스 지원이 있습니다. 높은 수준은 Omnibus GitLab과의 통합이 더 많음을 나타냅니다.

레벨 1

컴포넌트를 gitlab.rb의 사용자 제공 매개변수로 데이터베이스 서버와 작업하도록 구성합니다. 예를 들어, database.yml은 Rails 애플리케이션의 데이터베이스 서버 연결 세부 정보로 렌더링되거나 Container Registry의 데이터베이스 매개변수가 해당 config.yml로 전달됩니다.

레벨 2

컴포넌트의 데이터베이스 객체를 생성하고 마이그레이션을 실행합니다. 이 수준의 전체 지원은 Omnibus GitLab이 DATABASE 및 ROLE과 같은 필요한 데이터베이스 객체를 생성하는 것뿐만 아니라 컴포넌트를 위한 애플리케이션 마이그레이션도 실행해야 함을 의미합니다.

레벨 3

PgBouncer의 정적 구성. 이 수준에서 Omnibus GitLab은 컴포넌트를 위해 _전용 PgBouncer 사용자_를 만들고, 사용자가 제공한 것(gitlab.rb의 데이터)이나 애플리케이션에서 지정한 연결 설정으로 구성할 수 있습니다. 이것은 클러스터 데이터베이스 서버 설정과 특정한 것은 아니지만, 이에 필수적입니다. 일부 경우에는 PgBouncer가 독립 데이터베이스 서버와 구성됩니다. 그러나 모든 클러스터 데이터베이스 서버 설정은 PgBouncer 구성에 의존합니다.

레벨 4

높은 가용성(HA) 모드의 데이터베이스 서버 클러스터 구성. 이 수준에서 Omnibus GitLab은 하나의 클러스터로 모든 데이터베이스부터 데이터베이스당 하나의 클러스터까지 다양한 배포 모델을 지원합니다.

따라서 논리적 데이터베이스의 HA 구성은 배포 모델과 독립적이어야 합니다.

Consul services는 여러 건강 상태 검사와 watches를 가질 수 있습니다. 이 수준에서 Omnibus GitLab은 _데이터베이스 클러스터당 Consul 서비스_와 _논리적 데이터베이스당 서비스 감시_를 정의합니다.

Omnibus GitLab은 Patroni가 Consul 서비스를 등록하도록 구성합니다. 서비스의 이름은 범위 매개변수이며 태그는 노드의 역할인 master, primary, replica, 또는 standby-leader일 수 있습니다. Patroni 클러스터의 스코프와 동일한 서비스 이름을 사용하여 데이터베이스 클러스터를 지정하고 클러스터가 제공하는 모든 논리적 데이터베이스에 연결합니다.

이는 PgBouncer가 데이터베이스 클러스터와 논리적 데이터베이스의 세부 정보를 알리는 클러스터 리더를 찾고 PgBouncer에 알립니다.

레벨 5

이전 배포 모델에서의 자동 또는 보조적 전환. 모든 컴포넌트가 이 지원 수준을 필요로 하는 것은 아니지만, 권장되지만 폐기된 데이터베이스 구성이 사용되는 경우 Omnibus GitLab은 새로운 데이터베이스 모델로의 전환을 허용하는 특수 도구 또는 절차를 제공할 수 있습니다. 대부분의 경우 이것은 명시적으로 지정되지 않는 한 지원되지 않습니다.

디자인 개요

각 컴포넌트는 데이터베이스 사용자를 제외한 자체 데이터베이스 요구 사항의 모든 측면을 관리합니다. 즉, 각 데이터베이스에 대한 컴포넌트별 데이터베이스 작업은 해당 컴포넌트의 특정 쿡북에서 수행됩니다. 예를 들어, Rails나 Registry 데이터베이스 요구 사항은 gitlab 및 registry 쿡북에서만 주소 지정되며, postgresql, pgbouncer, 또는 patroni 쿡북에서는 절대 지정되지 않습니다.

데이터베이스 사용자는 SUPERUSER 또는 CREATEROLE 권한을 가진 사용자가 PostgreSQL 사용자를 생성할 수 있음을 의미합니다. 이로 인해 원격 데이터베이스에 연결할 수 있는 컴포넌트들은 이러한 권한을 부여받지 않습니다.

따라서 각 컴포넌트는 자체 데이터베이스 객체를 생성하지만, 데이터베이스 사용자를 제외합니다. postgresql 및 patroni 쿡북은 데이터베이스 사용자를 생성하지만 각 컴포넌트는 자체 데이터베이스 객체를 생성합니다. 데이터베이스 사용자는 컴포넌트가 자체의 DATABASE 및 신뢰할 수 있는 EXTENSION을 생성할 수 있도록 CREATEDB 권한을 가져야 합니다.

이러한 접근 방식의 구조와 일부 단점(예: 지역성 및 제한된 재사용성)을 해결하기 위해 Chef 리소스 모델을 사용하고 데이터베이스 구성 및 작업을 위해 사용자 정의 리소스를 활용합니다. 이는 다음을 포함합니다.

• 컴포넌트별 데이터베이스 객체의 라이프사이클 관리
• 애플리케이션별 데이터베이스 마이그레이션 실행
• 애플리케이션을 위해 PgBouncer 설정
• Patroni 클러스터를 추적하기 위해 Consul 감시 설정
• 자동 마이그레이션을 위한 중앙 온/오프 스위치
• 로깅 제어, 그리고 사전 체크를 위한 헬퍼 클래스

헬퍼 클래스는 package 쿡북에 정의되어 있으며 모든 컴포넌트에서 사용할 수 있는 기능을 제공합니다. 이 클래스는 기존의 사용자 구성 모델(gitlab.rb에)을 여러 데이터베이스를 관리하기 위해 필요한 새로운 모델로 변환하기 위한 곳을 제공합니다.

구현 세부 정보

Development document은 제안된 디자인의 구현 세부 정보와 구체적인 예시를 제공합니다.