• 요약
• 목표
• 제안
  • 용어
  • 지원 수준
    • 수준 1
    • 수준 2
    • 수준 3
    • 수준 4
    • 레벨 5
  • 설계 개요
  • 구현 세부 사항

여러 데이터베이스 지원

요약

이 문서는 하나 이상의 데이터베이스를 지원하는 구성 요소를 지원하는 방법을 설명합니다.

다양한 지원 수준을 설명하고 여러 도전 과제를 극복하기 위한 각 수준의 구현 모델을 제공합니다.

권장 배포 모델에 대한 도전 과제를 극복하는 데 도움이 됩니다.

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

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

목표

• 데이터베이스 요구 사항이 있는 현재 및 새로운 구성 요소에 대해 높은 수준의 지원을 제공합니다.

• 구현 리팩토링은 gitlab.rb에 이미 존재하는 현재 구성 옵션을 유지합니다.

• 일관되고 테스트 가능하며 확장 가능한 구현 모델로 데이터베이스 코드의 중단 변경 및 리팩토링을 최소화합니다.

• 코드를 최신 구현 방법으로 마이그레이션합니다.

제안

용어

용어	정의
데이터베이스	구성 요소가 사용하는 논리 데이터베이스입니다. 예를 들어, gitlabhq_production입니다. 구성 요소는 하나 이상의 데이터베이스를 가질 수 있습니다.
데이터베이스 서버	PostgreSQL 데이터베이스 서비스를 제공하는 독립 프로세스 또는 _클러스터_입니다. 데이터베이스 개체나 데이터와 혼동하지 마세요.
데이터베이스 개체	DATABASE, SCHEMA, ROLE, FUNCTION과 같은 데이터 정의 언어(DDL)로 생성된 모든 것입니다. 참조 데이터나 인덱스가 포함될 수 있습니다. 이들은 Omnibus GitLab에 의해 일부 생성되고 나머지는 애플리케이션 특정의 _데이터베이스 마이그레이션_에 의해 생성됩니다.
독립형 데이터베이스 서버	단일 PostgreSQL 데이터베이스 서버입니다. PgBouncer 인스턴스를 통해 접근할 수 있습니다.
데이터베이스 서버 클러스터	여러 PostgreSQL 데이터베이스 서버로 구성되며, 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 서비스는 여러 헬스 체크 및 감시를 가질 수 있습니다.

이 수준에서 Omnibus GitLab은 _데이터베이스 클러스터당 하나의 Consul 서비스_와 _논리 데이터베이스당 하나의 서비스 감시_를 정의합니다.

Omnibus GitLab은 Consul 서비스를 등록하기 위해 Patroni를 구성합니다. 서비스의 이름은 스코프 매개변수이며 태그는 노드의 역할로 master, primary, replica, standby-leader 중 하나일 수 있습니다.

이 서비스 이름은 Patroni 클러스터의 스코프와 동일하여 데이터베이스 클러스터를 지정하고 클러스터가 제공하는 모든 논리 데이터베이스와 연결합니다.

이것은 Patroni 서비스를 추적하는 Consul 감시로 수행됩니다. 이는 클러스터 리더를 찾고 PgBouncer에 데이터베이스 클러스터 및 논리 데이터베이스의 세부 정보를 알립니다.

레벨 5

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

설계 개요

각 구성 요소는 자체 데이터베이스 요구 사항의 모든 측면을 관리합니다. _단, 데이터베이스 사용자_는 제외됩니다. 이는 데이터베이스 작업의 구성 요소별 구현이 각 구성 요소의 특정 요리책에서 수행됨을 의미합니다. 예를 들어, Rails 또는 Registry 데이터베이스 요구 사항은 gitlab 및 registry 요리책에서만 다루어지며 postgresql, pgbouncer 또는 patroni 요리책에서는 다루어지지 않습니다.

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

따라서 각 구성 요소는 자체 데이터베이스 객체를 생성합니다. _단, 데이터베이스 사용자_는 제외됩니다. postgresql 및 patroni 요리책이 데이터베이스 사용자를 생성하지만, 각 구성 요소는 나머지 데이터베이스 객체를 생성합니다. 데이터베이스 사용자는 구성 요소가 자신의 DATABASE와 신뢰할 수 있는 EXTENSION을 생성할 수 있도록 CREATEDB 특권을 가져야 합니다.

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

• 구성 요소별 데이터베이스 객체의 수명 주기 관리
• 애플리케이션별 데이터베이스 마이그레이션 실행
• 애플리케이션을 제공하기 위한 PgBouncer 설정
• Patroni 클러스터를 추적하기 위한 Consul 감시 설정

자동 마이그레이션을 위한 중앙화 스위치, 로그 제어 및 사전 비행 검사와 같은 교차 절단 문제는 모든 구성 요소에서 사용할 수 있는 헬퍼 클래스를 통해 해결됩니다. package 요리책은 이러한 헬퍼를 위한 적절한 장소입니다.

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

구현 세부 사항

개발 문서는 제안된 설계에 대한 구현 세부 사항 및 구체적인 예를 제공합니다.