데이터베이스 지원

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

  1. 레벨 1
  2. 레벨 2
    1. 예제
      1. 예제 1: 레지스트리 데이터베이스 객체
      2. 예제 2: 레지스트리 데이터베이스 마이그레이션
      3. 예제 3: 레지스트리의 데이터베이스 객체 및 마이그레이션 사용
      4. 예제 4: Rails를 위한 매개변수화된 데이터베이스 객체 리소스
  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/ 디렉토리에 기본 nothing 동작(작동하지 않는 동작)과 create 동작을 가진 database_objects 사용자 정의 리소스를 생성합니다. create 동작은 필요한 데이터베이스 객체를 설정하기 위해 기존의 postgresql 사용자 정의 리소스를 활용할 수 있습니다.

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

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

  3. 요리책의 resources/ 디렉토리에 기본 nothing 동작(작동하지 않는 동작)과 run 동작을 가진 database_migrations 사용자 정의 리소스를 생성합니다. run 동작은 구성 요소의 데이터베이스 마이그레이션을 위한 명령을 실행합니다.

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

  4. 요리책의 default 레시피에서 database_objects 리소스를 사용하여 run 하도록 알림을 주는 database_migrations 리소스를 사용하십시오. 마이그레이션은 데이터베이스 객체의 준비 후에 즉시 실행될 수 있어야 하지만, 구성 요소는 즉각적인 트리거를 사용하지 않을 수 있습니다.

예시

다음의 모든 코드 블록은 예시로 제공됩니다. 요구 사항을 충족하도록 조정해야 할 수도 있습니다.

예시 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_migrations.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 "레지스트리 데이터베이스 마이그레이션: #{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의 매개변수화된 데이터베이스 객체 리소스

다음 예제는 Rails 애플리케이션을 위한 데이터베이스 객체의 단일 구현이 분해된 데이터베이스 모델의 요구 사항을 어떻게 충족할 수 있는지를 보여줍니다.

이 예제에서 logical 데이터베이스는 _resource name_으로 전달되며 구성에서 각 데이터베이스의 설정을 조회하는 데 사용됩니다. 설정은 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'] 설정에 매핑되고 이를 사용할 수 있도록 하세요. 이 속성은 기존 Rails 사용자를 재사용하는 대신 컴포넌트를 위한 전용 PgBouncer 사용자를 생성하는 데 사용됩니다. 현재 Praefect가 수행하는 것과 동일합니다.

    주의 노트: gitlab.rb에 대한 어떤 Breaking Change도 도입하지 않는 것이 매우 중요합니다. 현재 사용자 설정은 변경 없이 작동해야 합니다.

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

레벨 4

  1. 데이터베이스 클러스터의 Consul 서비스 이름을 지정하기 위한 새로운 속성을 컴포넌트에 추가합니다. 이는 자동 서비스 레지스트리가 활성화된 Patroni 클러스터의 범위 이름이거나(즉, patroni['register_service']), Omnibus GitLab 없이 수동으로 구성된 Consul 서비스 이름입니다.

  2. database_watch 사용자 정의 리소스(구현 필요)를 사용하여 데이터베이스 클러스터 서비스에 대한 새로운 Consul Watch를 정의합니다. 이는 클러스터의 리더가 변경될 때 PgBouncer에 논리 데이터베이스 엔드포인트를 업데이트하도록 알립니다. Consul 서비스 이름, 논리 데이터베이스 및 기타 PgBouncer 옵션을 매개변수로 Watch에 전달합니다.

모든 database_watch 리소스는 consul 요리법에 배치되어야 합니다. 이전 레벨과는 달리, 데이터베이스 관련 리소스가 하나의 요리법인 consul에 집중되어 있으며, 관련 컴포넌트와 동일한 요리법에서 관리되지 않습니다.

이 예외의 이유는 Watch가 pgbouncer_role이 사용되는 PgBouncer 노드에서 실행되기 때문입니다. PgBouncer와 Consul을 제외한 모든 컴포넌트는 비활성화됩니다. 이는 PgBouncer 노드에 대한 추천 구성과 일치하므로 gitlab.rb에 중단 변경 사항을 도입하고 싶지 않습니다.

고려사항

  • 데이터베이스 설정과 관련된 다른 리소스는 포함되지 않아야 합니다.

  • 모든 사용자 정의 리소스는 아이돌포턴트(무효가 아닌) 여야 합니다. 예를 들어, 객체가 이미 존재하는 경우 생성되거나 다른 요리법에서 실행되더라도 실패해서는 안 됩니다. 대신 새로운 사용자 입력에 따라 데이터베이스 객체, 구성 또는 마이그레이션의 현재 상태를 업데이트할 수 있어야 합니다.

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

격차 해소

현재 모든 사용자 정의 리소스 또는 헬퍼 클래스가 사용 가능한 것은 아닙니다. 사용 가능하더라도 지정된 요구 사항을 충족하기 위해 일부 조정이 필요할 수 있습니다. 다음은 몇 가지 예입니다.

기존 데이터베이스 작업 재구성

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

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

pgbouncer 요리법도 마찬가지입니다. 현재 유일한 PgBouncer 사용자는 이 요리법의 users 레시피에서 생성됩니다. 이는 각 컴포넌트 요리법이 자체 PgBouncer 사용자를 만들 수 있도록 변경될 수 있습니다.

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

현재 pgbouncer 요리책은 주로 여러 데이터베이스를 지원합니다.

pgbouncer 요리책은 주요 Rails 데이터베이스에 대해서만 PgBouncer 사용자를 생성합니다.

이로 인해 비-Rails 애플리케이션은 Rails를 위해 생성된 동일한 PgBouncer 사용자로 연결됩니다.

현재로서 우리는 동일한 사용자를 공유하는 분해된 Rails 데이터베이스에 대한 PgBouncer 지원을 설정할 수 있습니다.

하지만 Praefect 또는 Registry의 경우에는 전용 PgBouncer 사용자를 생성하기 위해 추가 작업이 필요합니다.

참고:

공유 사용자는 각 데이터베이스에 대한 연결 설정이 동일해야 한다는 의미는 아닙니다.

단지 여러 데이터베이스가 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은 명시적으로 정의된 postgresql 서비스를 사용합니다. 이 서비스는 현재 PgBouncer에 알리기 위해 사용되고 있습니다.

    이는 RepMgr에서 Patroni로의 전환의 잔재입니다.

    이는 Patroni가 등록하는 Consul 서비스로 교체되어야 합니다.

    patroni['register_service']가 활성화되면 Patroni는 patroni['scope'] 매개변수와 master, primary, replica, 또는 standby-leader 태그로 Consul 서비스를 등록합니다.

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

현재 Omnibus GitLab의 기능을 확장하여 Consul 감시를 사용하여 Patroni 서비스를 추적하고, 클러스터 리더를 찾아내며, 매개변수화된 장애 조치 스크립트로 PgBouncer에 알리는 기능을 추가해야 합니다.

이를 위해 consul 요리책에 database_watch 사용자 정의 리소스를 구현합니다.

이는 데이터베이스 클러스터 서비스에 대해 데이터베이스별 Consul 감시를 정의하고, PgBouncer에 알리기 위해 필요 정보를 매개변수화된 장애 조치 스크립트로 전달합니다.

이 리소스의 주요 속성은 다음과 같습니다:

  1. 감시해야 하는 데이터베이스 클러스터를 지정하는 서비스 이름입니다.

    이는 patroni['register_service']가 활성화될 때 Patroni 클러스터의 범위일 수 있으며, 수동으로 구성된 Consul 서비스 이름일 수 있습니다.

  2. 데이터베이스 클러스터 리더가 변경될 때 다시 구성해야 하는 논리 데이터베이스를 지정하는 데이터베이스 이름입니다.

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

MigrationHelper(구현 필요)는 데이터베이스 마이그레이션의 일반 요구 사항을 구현하며, 자동 마이그레이션을 활성화 또는 비활성화 하기 위한 중앙 스위치를 포함합니다.

또한 기존 및 새로운 구성 속성 간의 매핑을 제공합니다.