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

다중 데이터베이스 지원

요약

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

아키텍처 페이지에서는 이 주제에 대한 배경 정보를 제공합니다.

개발 문서는 이 청사진을 동반합니다. 구현 모델을 자세히 설명하고 몇 가지 예를 제공합니다.

목표

• 현재와 새로운 구성 요소에 대한 데이터베이스 요구 사항에 대한 보다 높은 지원 수준 제공
• 구현 리팩터는 현재 gitlab.rb에 이미 존재하는 현재 구성 옵션을 유지합니다.
• 일관된, 테스트 가능한, 확장 가능한 구현 모델로 데이터베이스 코드의 파괴적 변경과 리팩터 최소화
• 코드를 더 최근의 구현 방법으로 이관

제안

용어

용어	정의
데이터베이스	레일즈 응용프로그램과 같은 구성 요소가 사용하는 논리적 데이터베이스. 예: gitlabhq_production. 구성 요소는 하나 이상의 데이터베이스를 가질 수 있습니다.
데이터베이스 서버	포스트그리스 데이터베이스 서비스를 제공하는 독립 프로세스 또는 클러스터. 데이터베이스 개체나 데이터와 혼동해서는 안 됩니다.
데이터베이스 개체	데이터 정의 언어로 생성된 모든 것, 예: 데이터베이스, 스키마, 역할, 또는 기능. 참조 데이터나 색인을 포함할 수도 있습니다. 이러한 것들은 Omnibus GitLab에 의해 부분적으로 생성되며 나머지는 응용프로그램 특정 _데이터베이스 마이그레이션_에 의해 생성됩니다.
독립 데이터베이스 서버	단일 포스트그리스 데이터베이스 서버. PgBouncer 인스턴스를 통해 액세스할 수 있습니다.
데이터베이스 서버 클러스터	Patroni 서비스로 관리되는 여러 포스트그리스 데이터베이스 서버를 포함하며 Consul 클러스터에 백업되고 하나 이상의 PgBouncer 인스턴스를 통해 액세스할 수 있으며 프론트엔드로 HAProxy(프로토콜의 모드)를 포함할 수 있습니다.

지원 수준

Omnibus GitLab 컴포넌트에는 다양한 데이터베이스 지원 수준이 있습니다. 높은 수준은 Omnibus GitLab에 더 많은 통합을 의미합니다.

수준 1

구성 요소를 사용자가 제공한 매개변수로 gitlab.rb에서 데이터베이스 서버와 함께 작동하도록 구성합니다. 예: database.yml은 레일즈 응용프로그램의 데이터베이스 서버 연결 세부 정보를 렌더링하거나 Container Registry의 데이터베이스 매개변수가 config.yml에 전달됩니다.

수준 2

구성 요소의 데이터베이스 개체를 생성하고 마이그레이션을 실행합니다. 이 수준의 완전한 지원을 위해서는 Omnibus GitLab이 데이터베이스나 역할과 같은 필요한 데이터베이스 개체를 생성하는 것 뿐만 아니라 구성 요소의 응용프로그램 마이그레이션도 실행해야 합니다.

수준 3

PgBouncer의 정적 구성. 이 수준에서 Omnibus GitLab은 구성 요소를 위해 _전용 PgBouncer 사용자_를 만들고 사용자가 제공한(프롬 gitlab.rb) 또는 응용프로그램에서 필요로 하는 연결 설정으로 이를 구성할 수 있습니다.

이것은 클러스터화된 데이터베이스 서버 설정에 특정한 것은 아니지만 이것이 필수 조건입니다. PgBouncer가 독립 데이터베이스 서버에서 구성된 경우가 있습니다. 그러나 모든 클러스터화된 데이터베이스 서버 설정은 PgBouncer 구성에 의존합니다.

수준 4

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

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

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

Omnibus GitLab은 Patroni가 Consul 서비스를 등록하도록 구성합니다. 서비스의 이름은 Patroni 클러스터의 스코프 매개변수입니다. 태그는 노드의 역할일 수 있으며 master, primary, replica, 또는 standby-leader 중 하나일 수 있습니다. 이 서비스 이름은 Patroni 클러스터의 스코프와 동일하며 클러스터가 제공하는 논리적 데이터베이스에 연결합니다.

이는 Patroni 서비스를 추적하는 Consul watches를 이용하여 수행됩니다. 이들은 클러스터 리더를 찾아 PgBouncer에게 데이터베이스 클러스터 및 논리적 데이터베이스의 세부 정보를 알립니다.

수준 5

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

디자인 개요

각 구성 요소는 데이터베이스 사용자를 제외하고는 자신의 데이터베이스 요구 사항을 모두 관리합니다. 이는 각 구성 요소의 데이터베이스 작업에 대한 구체적인 구현이 각 구성 요소의 특정 cookbooks에서 수행됨을 의미합니다. 예: 레일즈나 레지스트리 데이터베이스 요구 사항은 gitlab 및 registry 쿡북에서만 처리되며 postgresql, pgbouncer, 또는 patroni 쿡북에서는 처리되지 않습니다.

데이터베이스 사용자는 SUPERUSER 또는 CREATEROLE 권한이 있는 사용자가 PostgreSQL 사용자를 생성할 수 있기 때문에 제외됩니다. 보안 상의 이유로 원격 데이터베이스에 연결할 수 있는 사용자에게 이 권한을 부여하지 않습니다. 따라서 원격 데이터베이스에 연결할 수 있는 구성 요소는 자체 사용자를 만들 수 없습니다.

따라서 각 구성 요소는 데이터베이스 개체를 생성하지만 자신의 데이터베이스 사용자를 생성하지는 않습니다. postgresql 및 patroni 쿡북은 데이터베이스 사용자를 생성하지만 각 구성 요소가 자신의 데이터베이스 개체를 생성합니다. 데이터베이스 사용자는 구성 요소가 자체 데이터베이스 및 신뢰할 수 있는 확장을 생성할 수 있도록 CREATEDB 권한이 있어야 합니다.

이러한 접근 방식의 몇 가지 단점, 예: 지역성 및 제한된 재사용성, 일부 결점을 수정하고, Chef 리소스 모델을 사용하여 데이터베이스 구성 및 작업에 대한 사용자 정의 리소스를 활용합니다.

• 구성 요소별 데이터베이스 개체의 라이프사이클 관리
• 응용프로그램별 데이터베이스 마이그레이션 실행
• 응용프로그램의 PgBouncer 설정
• Patroni 클러스터를 추적하기 위한 Consul 감시 설정

로그 레벨 제어, 사전 점검, 자동 마이그레이션을 위한 중앙 스위치와 같은 교차 관심사는 모든 구성 요소에서 사용 가능한 도우미 클래스를 사용하여 처리됩니다. package 쿡북은 이러한 도우미들을 위한 적절한 장소입니다.

도우미 클래스는 또한 기존 사용자 구성 모델(gitlab.rb에)을 여러 데이터베이스의 관리에 필요한 새로운 모델로 변환하는 데 필요한 위치를 제공합니다.

실행 세부 정보

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