데이터베이스 지원

이 문서는 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. database_objects 사용자 정의 리소스를 만들어서 resources/ 디렉터리에 추가합니다. 여기에는 기본 nothing 동작(수행되지 않는 동작) 및 create 동작이 포함됩니다. create 동작은 컴포넌트의 필요한 데이터베이스 객체를 설정하기 위해 기존 postgresql 사용자 정의 리소스를 활용할 수 있습니다.

    다음을 참조하십시오: - postgresql_user - postgresql_database - postgresql_schema - postgresql_extension - postgresql_query

    컴포넌트를 위한 database_objects 리소스는 컴포넌트의 필요한 모든 데이터베이스 객체를 생성해야 합니다. 즉, 다른 쿡북이 필요로 하는 일부 객체를 생성한다고 가정해서는 안됩니다.

  3. database_migrations 사용자 정의 리소스를 만들어서 resources/ 디렉터리에 추가합니다. 여기에는 기본 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의 데이터베이스 객체 및 마이그레이션 사용

이전 예시에서 정의된 리소스는 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 애플리케이션을 위한 데이터베이스 객체의 단일 구현이 분해된 데이터베이스 모델의 요구 사항을 충족시키는 방법을 보여줍니다.

이 예시에서는 논리적 데이터베이스가 _리소스 이름_으로 전달되고 각 데이터베이스의 설정을 구성에서 조회하도록 사용됩니다. 설정은 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 사용자를 생성하는 데 사용됩니다.

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

  2. 이전 단계에서 설명한 속성을 사용하여 구성요소에 대한 전용 PgBouncer 사용자를 생성하는 데 pgbouncer 쿡북의 pgbouncer_user 사용자 정의 리소스를 사용하십시오.

레벨 4

  1. 컴포넌트에 데이터베이스 클러스터의 Consul 서비스 이름을 지정할 수 있는 새로운 속성을 추가하십시오. 이는 Patroni 클러스터의 자동 서비스 레지스트리인 patroni['register_service']가 활성화되어 있는 경우 영역의 이름(Consul 서비스의 이름)이거나 Omnibus GitLab 없이 매뉴얼으로 구성된 Consul 서비스의 이름입니다.

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

모든 database_watch 리소스들은 consul 쿡북에 위치시켜야 합니다. 이전 레벨과는 달리 여기서는 모든 데이터베이스 관련 리소스가 consul 쿡북에 집중되어 있으며 관련 구성요소의 쿡북과 동일한 쿡북에서 관리되지 않습니다.

이 예외의 이유는 watch가 pgbouncer_role이 사용되는 PgBouncer 노드에서 실행되기 때문이며 이 때문에 모든 구성요소(Consul과 PgBouncer 제외)가 비활성화됩니다. pgbouncer 노드에 대한 권장 구성과 일치합니다. gitlab.rb에 파괴적인 변화를 도입하고 싶지 않습니다.

고려 사항

  • 다른 리소스는 데이터베이스 설정에 연관되어서는 안 됩니다.

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

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

간극을 좁히다

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

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

이 모델은 postgresql, patroni, 및 gitlab 쿡북에서 일부 조정이 필요합니다. 예를 들어 gitlab 쿡북에서 정의된 database_objects는 동일한 쿡북에서 사용되어야 하며, postgresql 및 patroni 쿡북에서의 사용은 제거되어야 합니다.

데이터베이스 서비스 쿡북인 (postgresql 및 patroni)은 데이터베이스 오브젝트 및 마이그레이션에 관여해서는 안 되며, 해당 작업은 애플리케이션 쿡북(e.g. gitlab, registry, 및 praefect)으로 위임되어야 합니다. 그러나 이를 지원하기 위해서는 postgresql 쿡북의 사용자 정의 리소스가 모든 노드에서 작동할 수 있어야 합니다. 현재 이 리소스들은 PostgreSQL 노드에서 실행되고 데이터베이스 서버에 연결하기 위해 UNIX 소켓을 사용한다고 가정하고 있습니다. 이 가정으로 모든 데이터베이스 작업을 한 개의 쿡북에 배치해야 하는 상황을 야기합니다.

pgbouncer 쿡북에도 이와 같은 상황이 적용됩니다. 현재, 해당 쿡북의 users 레시피에서는 유일한 PgBouncer 사용자가 생성됩니다. 이것 또한 각 컴포넌트 쿡북이 자체 PgBouncer 사용자를 생성할 수 있도록 변경할 수 있습니다.

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

현재의 pgbouncer 쿡북은 대부분의 경우 다중 데이터베이스를 지원하는데, 유일하게 PgBouncer 사용자를 메인 Rails 데이터베이스를 위해 생성합니다. 따라서 Rails가 아닌 애플리케이션은 Rails를 위해 생성된 동일한 PgBouncer 사용자로 연결합니다.

현재는 하나의 사용자가 여러 데이터베이스에 연결되는 공유 사용자를 설정할 수 있습니다. 그러나 Praefect 또는 Registry의 경우 각각의 PgBouncer 사용자를 만들기 위해 추가 작업이 필요합니다.

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

PgBouncer 데이터베이스 구성의 지연

gitlab-ctl pgb-notify의 구현은 여러 데이터베이스를 지원합니다. 이것은 PgBouncer 사용자가 생성되는 한 databases.ini가 databases.json 파일에서 업데이트될 수 있을 정도로 충분히 범용적입니다.

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

데이터베이스용 Configurable Consul 감시

다중 Patroni 클러스터 간에 Consul 클러스터를 공유할 수 있지만 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 감시와 연관되어 있으며, 데이터베이스 이름은 변경할 수 없습니다.

현재 Omnibus GitLab의 기능을 확장하여 Consul 감시를 사용하여 Patroni 서비스를 추적하고 클러스터 리더를 찾아 parameterized failover 스크립트로 PgBouncer에 통지할 수 있도록 기능을 추가해야 합니다.

이를 위해 consul 쿡북에 database_watch 사용자 정의 리소스를 구현합니다. 이 리소스는 데이터베이스 클러스터 서비스에 대한 데이터베이스별 Consul 감시를 정의하고 parameterized failover 스크립트에 필요한 정보를 전달합니다.

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

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