데이터베이스 지원

이 문서는 Omnibus GitLab 구성 요소에 데이터베이스 지원을 구현하는 방법에 대한 세부 정보와 예제를 제공합니다. 아키텍처 청사진은 설계와 정의를 제공합니다.

  1. 레벨 1
  2. 레벨 2
    1. 예제
      1. 예제 1: 레지스트리 데이터베이스 객체
      2. 예제 2: 레지스트리 데이터베이스 마이그레이션
      3. 예제 3: 레지스트리의 데이터베이스 객체와 마이그레이션 사용
      4. 예제 4: 레일즈용 매개변수화된 데이터베이스 객체 리소스
  3. 레벨 3
  4. 레벨 4
  5. 고려 사항
  6. 갭을 메꾸다
    1. 기존 데이터베이스 작업 재구성
    2. 데이터베이스용 전용 PgBouncer 사용 지원
    3. PgBouncer 데이터베이스 구성의 지연된 생성
    4. 데이터베이스용 구성 가능한 Consul 감시
    5. 일반 데이터베이스 마이그레이션 요구 사항을 위한 도우미 클래스

레벨 1

  1. gitlab.rb에 새로운 데이터베이스 관련 구성 속성을 추가합니다. gitlab.rb.template를 업데이트하는 것을 잊지 마세요.
  2. Chef 레시피를 업데이트하여 구성 속성을 사용하도록 합니다. 이 단계에서 요구 사항은 구성 파일 또는 명령행 인수를 통해 일반적으로 해당 구성 요소로 속성을 전달하는 것입니다.

예를 들어 registry 쿡북에서:

레벨 2

  1. postgresql 및 pgbouncer 쿡북에 종속성을 추가합니다. metadata.rb에서 depends를 사용합니다. 이렇게 하면 요구 사항이 충족되고 해당 Chef 커스텀 리소스가 쿡북에서 사용 가능해집니다.

  2. resources/ 디렉토리에 database_objects 커스텀 리소스를 생성합니다. 기본 nothing 동작(아무것도 하지 않는 동작)과 create 동작을 사용합니다. create 동작은 해당 구성 요소의 필요한 데이터베이스 객체를 설정하기 위해 기존의 postgresql 커스텀 리소스를 활용할 수 있습니다.

    참조: - postgresql_user - postgresql_database - postgresql_schema - postgresql_extension - postgresql_query

    database_objects 리소스는 구성 요소의 모든 필요한 데이터베이스 객체를 생성해야 합니다. 다른 쿡북이 필요한 일부 객체를 생성한다고 가정해서는 안 됩니다.

  3. resources/ 디렉토리에 database_migrations 커스텀 리소스를 생성합니다. 기본 nothing 동작과 run 동작을 사용합니다. run 동작은 구성 요소의 데이터베이스 마이그레이션을 실행합니다.

    마이그레이션이 실행될 때 필요한 모든 데이터베이스 객체가 사용 가능하다고 가정할 수 있습니다. 따라서 해당 리소스는 database_objects 리소스의 성공적인 create 동작에 종속되어야 합니다.

  4. 쿡북의 default 레시피에서 database_objects 리소스를 사용하여 database_migrations 리소스를 run하도록 알립니다. 마이그레이션은 데이터베이스 객체 준비 후 즉시 실행될 수 있지만, 구성 요소가 즉시 트리거를 사용하지 않도록 선택할 수 있습니다.

예제

다음은 모든 코드 블록이 예제로 제공됩니다. 요구 사항을 충족하기 위해 조정이 필요할 수 있습니다.

예제 1: 레지스트리 데이터베이스 객체

다음 예제는 registry 쿡북의 database_objects 리소스를 정의한 것입니다. (registry/resources/database_objects.rb).

그것이 필요한 데이터베이스 객체를 생성하기 위해 postgresql 쿡북에서 커스텀 리소스를 사용하는 방법에 주목해주세요. 

# registry/resources/database_objects.rb

unified_mode true

property :pg_helper, [GeoPgHelper, PgHelper], required: true, sensitive: true

default_action :nothing

action :nothing do
end

action :create do
  host = node['registry']['database']['host']
  port = node['registry']['database']['port']
  database_name = node['registry']['database']['database_name']
  username = node['registry']['database']['username']
  password = node['registry']['database']['password']

  postgresql_user username do
    password "md5#{password}" unless password.nil?

    action :create
  end

  postgresql_database database_name do
    database_socket host
    database_port port
    owner username
    helper new_resource.pg_helper

    action :create
  end

  postgresql_extension 'btree_gist' do
    database database_name

    action :enable
  end
end

예제 2: 레지스트리 데이터베이스 마이그레이션

다음 예제는 registry 쿡북의 database_migrations 리소스를 정의한 것입니다. (registry/resources/database_objects.rb).

리소스가 추가 매개변수를 받는 방법에 주목해주세요. 추가 매개변수는 전개 전 또는 전개 후 마이그레이션의 분리와 같이 다양한 마이그레이션 시나리오를 지원하는 데 도움이 됩니다. 또한 MigrationHelper를 사용하여 마이그레이션을 실행할지 여부를 결정합니다. 

# registry/resources/database_migrations.rb

unified_mode true

property :name, name_property: true
property :direction, Symbol, default: :up
property :dry_run, [true, false], default: false
property :force, [true, false], default: false
property :limit, [Integer, nil], default: nil
property :skip_post_deployment, [true, false], default: false

default_action :nothing

action :nothing do
end

action :run do
  # MigrationHelper가 구현되지 않았습니다. 이것은 마이그레이션 관리를 위한 일반적인 용도의 도우미 메서드를 포함합니다. 예를 들어 특정 구성 요소의 마이그레이션이 실행할 수 있는지 여부 등입니다.
  #
  # 참조: "일반 데이터베이스 마이그레이션 요구 사항을 위한 도우미 클래스"
  migration_helper = MigrationHelper.new(node)

  account_helper = AccountHelper.new(node)
  logfiles_helper = LogfilesHelper.new(node)
  logging_settings = logfiles_helper.logging_settings('registry')  

  bash_hide_env "migrate registry database: #{new_resource.name}" do
    code <<-EOH
    set -e

    LOG_FILE="#{logging_settings[:log_directory]}/db-migrations-$(date +%Y-%m-%d-%H-%M-%S).log"

    umask 077
    /opt/gitlab/embedded/bin/registry \
      #{new_resource.direction} \
      #{"--dry-run" if new_resource.dry_run} \
      #{"--limit #{new_resource.limit}" unless new_resource.limit.nil?} \
      ... \
      #{working_dir}/config.yml \
      2>& 1 | tee ${LOG_FILE}

    STATUS=${PIPESTATUS[0]}

    chown #{account_helper.gitlab_user}:#{account_helper.gitlab_group} ${LOG_FILE}

    exit $STATUS
    EOH

    not_if { migration_helper.run_migration?('registry') }
  end
end

예시 3: 레지스트리의 데이터베이스 객체 및 마이그레이션 사용

이전 예시에서 정의된 리소스는 registry/recipes/enable.rb 레시피에서 사용됩니다.

only_if 및 not_if 가드가 언제 데이터베이스 객체를 생성하거나 마이그레이션을 실행할지 결정하는 방법을 확인하세요. 또한 notifies가 데이터베이스 객체의 성공적인 생성에 따라 마이그레이션에 대한 의존성을 표시하는 방법에 주목하세요. 

# registry/recipes/enable.rb

# ...

pg_helper = PgHelper.new(node)

registry_database_objects 'default' do
  pg_helper pg_helper
  action :create
  only_if { node['registry']['database']['enable'] }
  not_if { pg_helper.replica? }
  notifies :create, 'registry_database_migrations[up]', :immediately if pg_helper.is_ready?
end

registry_database_migrations 'up' do
  direction :up
  only_if { node['registry']['database']['enable'] }
  not_if { pg_helper.replica? }  
end

# ...

예시 4: Rails를 위한 매개변수화된 데이터베이스 객체 리소스

다음 예시에서는 레일즈 애플리케이션의 데이터베이스 객체의 단일 구현이 분해된 데이터베이스 모델의 요구 사항을 충족하는 방법을 보여줍니다.

이 예시에서는 논리적 데이터베이스가 _리소스 이름_으로 전달되며 각 데이터베이스의 설정을 구성에서 조회하는 데 사용됩니다. 설정은 postgresql 사용자 정의 리소스에 전달됩니다. 이는 특히 하나 이상의 리소스를 대체하기 위해 대부분의 구현이 재사용될 수 있는 경우에 유용합니다. 

# gitlab/resources/database_objects.rb

unified_mode true

property :pg_helper, [GeoPgHelper, PgHelper], required: true, sensitive: true

default_action :nothing

action :nothing do
end

action :create do
  global_database_settings = {
    # ...
    port: node['postgresql']['port']
    host: node['gitlab']['gitlab_rails']['db_host']
    # ...
  }
  database_settings = node['gitlab']['gitlab_rails']['databases'][new_resource.resource_name]

  database_settings = global_database_settings.merge(database_settings) unless database_settings.nil?

  username = database_settings[:username]
  password = database_settings[:password]
  database_name = database_settings[:database_name]
  host = database_settings[:host]
  port = database_settings[:port]

  postgresql_user username do
    password "md5#{password}" unless password.nil?

    action :create
  end

  postgresql_database database_name do
    database_socket host
    database_port port
    owner username
    helper new_resource.pg_helper

    action :create
  end

  postgresql_extension 'btree_gist' do
    database database_name

    action :enable
  end
end

이 예시는 gitlab/recipes/default.rb에서 다음과 같이 사용됩니다. 

gitlabe_database_objects 'main' do
  pg_helper pg_helper

  action :create
  only_if { node['gitlab']['gitlab_rails']['databases']['main']['enable'] ... }
end

gitlabe_database_objects 'ci' do
  pg_helper pg_helper

  action :create
  only_if { node['gitlab']['gitlab_rails']['databases']['ci']['enable'] ... }
end

레벨 3

  1. PgBouncer 사용자를 위한 새로운 속성을 추가하세요. 이 속성이 기존의 pgbouncer['databases'] 설정과 매핑되어 사용될 수 있도록 확인하세요. 이 속성은 Praefect가 현재 하는 것과 동일하게 기존 Rails 사용자를 재사용하는 대신 해당 컴포넌트를 위한 전용 PgBouncer 사용자를 생성하는 데 사용됩니다.

    참고: gitlab.rb에 어떤 파괴적인 변화도 발생하지 않도록 주의해야 합니다. 현재 사용자 설정은 변경 없이도 작동해야 합니다.

  2. 이전 단계에서 설명된 속성을 사용하여 컴포넌트에 대한 전용 PgBouncer 사용자를 생성하는 데 pgbouncer 쿡북의 pgbouncer_user 사용자 정의 리소스를 사용하세요.

레벨 4

  1. 컴포넌트를 통해 데이터베이스 클러스터의 Consul 서비스 이름을 지정하는 새로운 속성을 추가하세요. 이 속성은 자동 서비스 등록을 위해 Patroni, 즉 patroni['register_service']가 활성화된 경우 또는 Omnibus GitLab 없이 수동으로 구성된 Consul 서비스의 스코프 이름입니다.

  2. database_watch 사용자 정의 리소스 (구현이 필요함)를 사용하여 데이터베이스 클러스터 서비스에 대한 Consul 감시를 정의하세요. 클러스터 리더가 변경될 때 PgBouncer에게 논리적 데이터베이스 엔드포인트를 업데이트하도록하며, Consul 서비스 이름, 논리적 데이터베이스 및 기타 PgBouncer 옵션을 감시에 매개변수로 전달하세요.

모든 database_watch 리소스는 예전 단계와는 달리 consul 쿡북에 위치해야 합니다. 이는 모든 데이터베이스 관련 리소스가 하나의 쿡북인 consul에 집중되어 있고 PgBouncer 노드에서 실행되기 때문에 예외입니다. 모든 컴포넌트는 PgBouncer 및 Consul을 제외하고 비활성화됩니다. PgBouncer 노드에서 실행되는 감시가 pgbouncer_role를 사용하기 때문에 이것은 기존 사용자 구성과 일치합니다. PgBouncer 노드에서의 권장 구성을 따르기 때문에 gitlab.rb에 파괴적인 변화를 도입하고 싶지 않습니다.

고려 사항

  • 데이터베이스 설정에 다른 리소스가 관련되어 있으면 안 됩니다.

  • 모든 사용자 정의 리소스는 연산 유일성(idempotent)이어야 합니다. 예를 들어 이미 존재하는 객체에 대해 실패해서는 안 되며, 대신 새로운 사용자 입력에 따라 데이터베이스 객체, 구성 또는 마이그레이션의 현재 상태를 업데이트할 수 있어야 합니다.

  • HA 모드에서 여러 물리적 노드가 관련되어 있기 때문에 Omnibus GitLab은 구성의 완전한 자동화를 제공하는 데 일부 제약이 발생할 수 있습니다. 이는 허용되는 제약입니다.

간극을 좁히다

현재 모든 사용자 정의 리소스 또는 도우미 클래스가 제공되지 않습니다. 제공되더라도 지정된 요구 사항을 충족시키기 위해 일부 조정이 필요할 수 있습니다. 몇 가지 예시는 다음과 같습니다.

기존 데이터베이스 작업을 다시 구성하기

이 모델에는 postgresql, patroni, 그리고 gitlab 쿡북을 몇 가지 조정할 필요가 있습니다. 예를 들어, gitlab 쿡북에 정의된 database_objects는 동일한 쿡북에서 사용되어야 하며, postgresql 및 patroni 쿡북에서의 사용은 제거되어야 합니다.

데이터베이스 서비스 쿡북(postgresql 및 patroni)은 데이터베이스 객체 및 마이그레이션을 처리해서는 안 되며, 이를 애플리케이션 쿡북(예: gitlab, registry, praefect)에 위임해야 합니다. 그러나 이를 지원하기 위해서, postgresql 쿡북의 사용자 정의 리소스는 모든 노드에서 작동할 수 있어야 합니다. 현재 이 리소스들은 PostgreSQL 노드에서 실행되며 UNIX 소켓을 사용하여 데이터베이스 서버에 연결합니다. 이 가정으로 인해 모든 데이터베이스 작업이 하나의 쿡북에 위치하게 됩니다.

pgbouncer 쿡북도 마찬가지입니다. 현재 이 쿡북에서의 users 레시피에서는 PgBouncer 사용자만 생성합니다. 각 구성요소 쿡북이 자체 PgBouncer 사용자를 만들 수 있도록 변경할 수 있습니다.

데이터베이스를 위한 전용 PgBouncer 사용자 지원

현재 pgbouncer 쿡북은 주로 다중 데이터베이스를 지원합니다.

pgbouncer 쿡북은 주로 메인 Rails 데이터베이스에 대한 PgBouncer 사용자를 생성합니다. 이는 비-Rails 애플리케이션이 동일한 PgBouncer 사용자로 Rails에 연결될 수 있기 때문입니다.

우리는 현재 동일한 사용자를 공유하는 분해된 Rails 데이터베이스에 대한 PgBouncer 지원을 설정할 수 있습니다. 그러나 Praefect 또는 Registry의 경우, 전용 PgBouncer 사용자를 만들기 위해 추가 작업이 필요합니다.

NOTE 참고: 공유 사용자는 각 데이터베이스의 연결 설정이 동일해야 한다는 것을 의미하는 것은 아닙니다. 여러 데이터베이스가 PgBouncer 연결을 위해 동일한 사용자를 사용한다는 것만을 의미합니다.

PgBouncer 데이터베이스 구성의 지연적인 인원 증가

gitlab-ctl pgb-notify의 구현은 여러 데이터베이스를 지원합니다. PgBouncer 사용자가 생성된다면, databases.json 파일에서 databases.ini을 업데이트할 수 있습니다.

그러나 PgBouncer 사용자가 개별 쿡북으로 이동되면, gitlab-ctl reconfigure에서 생성 또는 업데이트된 초기 databases.ini은 아직 생성되지 않은 PgBouncer 사용자를 참조하기 때문에 유효하지 않을 수 있습니다. 이를 고치기 위해 gitlab-ctl pgb-notify를 호출하는 Chef 리소스의 작업을 지연시킬 수 있어야 합니다.

데이터베이스를 위한 구성 가능한 Consul 감시

Consul 클러스터는 여러 Patroni 클러스터 간에 공유될 수 있습니다(예: patroni['scope']와 같은 다양한 범위 사용). 그러나 PgBouncer 구성을 업데이트하는 것은 Consul 감시 스크립트가 완전히 구성 가능하지 않기 때문에 여전히 문제가 있습니다.

현재 구현에는 몇 가지 제한 사항이 있습니다:

  1. Omnibus GitLab는 consul 쿡북에 명시적으로 정의된 postgresql 서비스를 사용합니다. 현재 PgBouncer에 알림을 주는 데 사용되는 이 서비스는 RepMgr에서 Patroni로의 전환에서 남은 것입니다. 이것은 Patroni가 등록하는 Consul 서비스로 대체되어야 합니다. patroni['register_service']가 활성화되면 Patroni는 노드의 역할에 따라 patroni['scope'] 매개변수와 태그 master, primary, replica, standby-leader를 사용하여 Consul 서비스를 등록합니다.

  2. 현재의 장애 조치 스크립트는 postgresql 서비스에 대한 Consul 감시에 연관되어 있으며, 데이터베이스 이름을 수정할 수 없기 때문에, 여러 데이터베이스를 처리할 수 없습니다.

이를 해결하기 위해 Consul 감시를 통해 Patroni 서비스를 추적하여 클러스터 리더를 찾고, 매개변수화된 장애 조치 스크립트로 PgBouncer에 알림을 보낼 수 있도록 Omnibus GitLab의 현재 기능을 확장해야 합니다.

우리는 consul 쿡북에 database_watch 사용자 정의 리소스를 구현하여 이를 수행합니다. 이 리소스는 데이터베이스 클러스터 서비스를 위한 데이터베이스별 Consul 감시를 정의하고, 매개변수화된 장애 조치 스크립트에 필요한 정보를 전달합니다.

일반 데이터베이스 마이그레이션 요구 사항을 위한 도우미 클래스

MigrationHelper(구현 필요)는 자동 마이그레이션을 활성화 또는 비활성화할 수 있는 데이터베이스 마이그레이션의 일반 요구 사항을 구현합니다. 또한 기존 및 새 구성 속성 간의 매핑을 제공할 수도 있습니다.