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

다중 데이터베이스 지원

요약

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

아키텍처 페이지에서 이 주제에 대해 배경 정보를 얻을 수 있습니다.

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

목표

• 현재 및 새로운 컴포넌트에 대한 데이터베이스 요구 사항에 대한 더 높은 수준의 지원 제공
• 현재의 구성 옵션을 유지하면서 구현 리팩터링은 gitlab.rb에 이미 존재하는 현재 구성 옵션을 유지합니다.
• 일관되고 테스트 가능하며 확장 가능한 구현 모델을 사용하여 데이터베이스 코드의 파괴적인 변화와 리팩터링 최소화
• 코드를 더 최신의 구현 방법으로 마이그레이션

제안

용어

용어	정의
데이터베이스	예를 들어 gitlabhq_production과 같이 Rails 애플리케이션이 사용하는 논리 데이터베이스입니다. 컴포넌트는 하나 이상의 데이터베이스를 가질 수 있습니다.
데이터베이스 서버	PostgreSQL 데이터베이스 서비스를 제공하는 독립 프로세스 또는 _클러스터_입니다. 데이터베이스 객체 또는 데이터와 혼동해서는 안 됩니다.
데이터베이스 객체	DATABASE, SCHEMA, ROLE, 또는 FUNCTION과 같은 데이터 정의 언어(DDL)로 생성된 모든 것을 나타냅니다. 참조 데이터나 인덱스를 포함할 수도 있습니다. 이러한 객체는 Omnibus GitLab에서 일부가 생성되며 나머지는 애플리케이션별 _데이터베이스 마이그레이션_에 의해 생성될 수 있습니다.
독립형 데이터베이스 서버	단일 PostgreSQL 데이터베이스 서버로, PgBouncer 인스턴스를 통해 액세스할 수 있습니다.
데이터베이스 서버 클러스터	파트로니 서비스에 의해 관리되는 여러 PostgreSQL 데이터베이스 서버로 구성되며 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은 Patroni가 Consul 서비스를 등록하도록 구성합니다. 서비스의 이름은 범주 매개변수이며 태그는 노드의 역할로 master, primary, replica, 또는 standby-leader 중 하나일 수 있습니다. Patroni 클러스터의 범주와 동일한 이름인 이 서비스 이름을 사용하여 데이터베이스 클러스터를 식별하고 해당 클러스터가 제공하는 모든 논리적 데이터베이스에 연결합니다.

이는 Patroni 서비스를 추적하는 Consul 감시를 통해 수행됩니다. 이들은 클러스터 리더를 찾아서 PgBouncer에게 데이터베이스 클러스터 및 논리적 데이터베이스의 세부 정보를 알리는 역할을 합니다.

레벨 5

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

디자인 개요

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

이는 데이터베이스 사용자를 제외하는데, 원격 데이터베이스에 연결할 수 있는 사용자에게 SUPERUSER 또는 CREATEROLE 권한을 부여하지 않음으로 인해 있습니다. 따라서 원격 데이터베이스에 연결할 수 있는 컴포넌트들은 자체 사용자를 만들 권한을 가지지 않습니다.

결국 각 컴포넌트는 자체 데이터베이스 객체를 생성하지만, 그 데이터베이스 사용자를 제외하고요. postgresql 및 patroni 쿡북은 데이터베이스 사용자를 생성하지만, 각 컴포넌트는 나머지 데이터베이스 객체를 생성하게 됩니다. 데이터베이스 사용자는 컴포넌트가 자체 DATABASE 및 신뢰할 수 있는 EXTENSION을 만들 수 있도록 CREATEDB 권한이 있어야 합니다.

로컬성 및 제한된 재사용성과 같은 이러한 접근 방식의 일부 단점을 해결하고 구조를 강제하기 위해 Chef 리소스 모델을 사용하고 데이터베이스 구성 및 작업을 위한 사용자 정의 리소스를 활용합니다.

• 컴포넌트별 데이터베이스 객체의 라이프사이클 관리
• 응용 프로그램별 데이터베이스 마이그레이션 실행
• 응용 프로그램을 위해 PgBouncer 설정
• Patroni 클러스터를 추적하기 위한 Consul 감시 설정

중요한 관심사들인 자동 마이그레이션을 위한 중앙 ON/OFF 스위치, 로깅 제어, 그리고 사전 점검은 모든 컴포넌트에서 사용할 수 있는 도우미 클래스로 해결됩니다. 이러한 도우미 클래스는 이러한 역할을 위해 적합한 package 쿡북이 있습니다.

도우미 클래스는 이미 있는 사용자 구성 모델( gitlab.rb에)을 다중 데이터베이스 관리에 필요한 새로운 모델로 변환하는 데 필요합니다.

구현 세부 정보

개발 문서는 제안된 디자인에 대한 구현 세부 정보와 구체적인 예제를 제공합니다.