Omnibus GitLab에 새로운 서비스 추가하기

GitLab에 새로운 서비스를 추가하기 위해서는 다음 단계를 따라야 합니다:

  1. 빌드 중 소프트웨어 가져오고 컴파일하기
  2. 서비스를 위한 최상위 구성 오브젝트 추가하기
  3. 서비스 디렉터리에 서비스 포함하기
  4. 서비스를 위한 활성화 및 비활성화 레시피 생성하기
  5. 로그 회전 처리 방식 결정하고 문서화하기

선택적으로 다른 일반적인 작업으로는 서비스를 위한 추가 구성 구문 분석 이 있습니다.

빌드 중 소프트웨어 가져오고 컴파일하기

프로젝트에 이미 포함되어 있지 않은 경우, 서비스에 대한 새로운 소프트웨어 정의를 추가해야 합니다. 자세한 내용은 새로운 소프트웨어 정의를 참조하세요.

서비스를 위한 최상위 구성 오브젝트 추가하기

files/gitlab-cookbooks에 있는 쿡북 및 레시피는 Omnibus GitLab 패키지가 설치된 경우 gitlab-ctl reconfigure 중에 실행되는 내용입니다. 여기에 새로운 서비스의 설정을 추가해야 합니다.

기본 속성 정의하기

기존 쿡북 중 하나를 선택하거나, 서비스가 독자적인 쿡북을 필요로 하는 경우 새로운 쿡북을 만들어야 합니다.

쿡북 내에는 attributes/default.rb 파일이 있어야 합니다. 여기에는 기본 속성 을 정의해야 합니다. 서비스에 대한 속성을 정의할 때는 기본적으로 enable 옵션을 정의해야 합니다.

default['gitlab']['best_service']['enable'] = false
default['gitlab']['best_service']['dir'] = '/var/opt/gitlab/best-service'
default['gitlab']['best_service']['log_directory'] = '/var/log/gitlab/best-service'
  • default은 기본 쿡북 속성을 정의하는 방법입니다.
  • ['gitlab']은 쿡북 이름을 포함합니다.
  • ['best_service']는 서비스의 이름입니다.
  • enable, dir, 그리고 log_directory는 설정입니다.
  • /var/opt/gitlab는 서비스의 작업 디렉터리 및 설정 파일이 위치하는 곳입니다.
  • /var/log/gitlab은 GitLab 패키지의 로그가 기록되는 위치입니다.

여기에 패키지에서 구성할 수 있는 모든 설정을 정의하세요. 지금은 기본적으로 nil로 설정하고, 나중에 필요에 따라 기본값을 계산해야 합니다.

네이밍 규칙

서비스 이름은 주로 다음 세 가지 시나리오에서 참조됩니다.

  1. 서비스에 해당하는 Chef 속성에 액세스
  2. 사용자, 그룹 및 해당 서비스에 대한 경로와 같은 항목 참조
  3. 서비스 이름을 해당하는 속성을 찾는 메서드에 전달
    • “서비스가 활성화되어 있는가?”
    • “이 서비스에 해당하는 로그 소유권 세부 정보를 가져오기”
    • “이 서비스에 대한 runit 구성 생성하기”

위에서 언급한 첫 번째 경우에 대해, 서비스 이름의 단어를 구분하기 위해 밑줄을 사용합니다. 다른 두 경우에는 단어를 구분하기 위해 하이픈을 사용합니다. 설정은 주로 루비 객체로 사용되므로, 하이픈 대신 밑줄을 사용하는 것이 더 유연합니다 (예: 밑줄을 사용하면 구성 해시에서 심볼을 더 깔끔하게 사용할 수 있습니다).

예를 들어, GitLab Pages를 살펴보면 속성은 Gitlab['gitlab_pages']node['gitlab_pages']로 사용할 수 있으며, 기본 디렉터리와 경로는 /var/log/gitlab/gitlab-pages/var/opt/gitlab/gitlab-pages와 같이 보입니다. 비슷하게 메서드 호출은 service_enabled?("gitlab-pages")로 보입니다.

서비스를 위한 구성 Mash 생성하기

사용자가 /etc/gitlab/gitlab.rb에서 서비스를 구성할 수 있도록 하려면, 서비스를 위한 최상위 Mash를 추가해야 합니다.

files/gitlab-cookbooks/package/libraries/config/gitlab.rb에서는 attribute 메서드 디렉터리을 찾을 수 있습니다.

만약 서비스가 GitLab 쿡북의 속성에 포함되어 있는 경우, attribute_block('gitlab') 블록 내에 서비스를 속성으로 추가해야 합니다. 그렇지 않으면, 서비스에 대한 새로운 쿡북이 있다면 위에 추가해야 합니다.

attribute('best_service')

EE 전용 속성의 경우, ee_attribute을 대신 사용하세요.

ee_attribute('best_service')

서비스 구성을 설정 템플릿에 추가하기

우리는 전역 구성 템플릿을 유지합니다. 이곳에는 서비스를 구성하는 방법에 대한 예시가 주석 처리되어 있습니다.

이 파일은 패키지를 새로 설치한 경우 /etc/gitlab/gitlab.rb가 됩니다.

서비스의 구성을 사용자가 변경할 수 있도록 하려면, 이 파일에 추가해야 합니다. files/gitlab-config-template/gitlab.rb.template

### Best Service configuration
# best_service['enable'] = true
# best_service['dir'] = '/var/opt/gitlab/best-service'
# best_service['log_directory'] = '/var/log/gitlab/best-service'

제공된 값은 기본값을 반영하는 것이 아니라, 서비스를 사용할 수 있도록 주석 처리된 상태로 만들기 쉽게 하기 위한 목적입니다. 그게 불가능한 경우에는 YOURSECRET과 같이 명확히 대체해야 할 값이나, 알맞은 경우에 기본값을 사용하세요.

서비스 디렉터리에 서비스 포함하기

레시피에서 서비스를 쉽게 활성화/비활성화하기 위해서는 서비스 디렉터리에 서비스를 추가하고 적절한 그룹을 지정해야 합니다.

files/gitlab-cookbooks/package/libraries/config/services.rb 파일에서 해당 서비스를 추가하고, 서비스가 GitLab EE 전용인지 여부에 따라 Base 또는 EE Config 클래스에 서비스를 추가해야 합니다.

service 'best_service', groups: ['bestest']

그룹을 지정하면 한꺼번에 여러 관련 서비스를 비활성화/활성화하기가 더 쉽습니다. 새로운 서비스가 수행하는 작업과 일치하는 기존 그룹 중 하나에 해당하거나, 현재는 그룹을 사용하여 서비스를 활성화/비활성화할 필요가 없는 경우는 일단 넘어가셔도 됩니다.

다음은 사용할 수 있는 기존 그룹의 몇 가지 예시입니다:

  • 서비스가 기본적으로 Omnibus에서 활성화되는 경우, DEFAULT_GROUP 그룹을 추가해야 합니다.
  • 서비스가 거의 모든 시나리오에서 비활성화되어서는 안 되는 경우, SYSTEM_GROUP을 추가해야 합니다.
  • 서비스가 GitLab Rails가 구성된 상태에 의존하는 경우, rails 그룹을 추가해야 합니다.
  • 서비스가 새로운 프로메테우스 익스포터인 경우, prometheus 그룹을 추가해야 합니다.

서비스를 위한 활성화 및 비활성화 레시피 생성하기

활성화 레시피

활성화 레시피는 기존 쿡북에 추가되는 경우, files/gitlab-cookbooks/<cookbook-name>/recipes/<service-name>.rb로 생성해야 합니다. 서비스가 독자적인 쿡북을 가지고 있는 경우에는 files/gitlab-cookbooks/<cookbook-name>/recipes/enable.rb로 생성할 수 있습니다.

레시피에서는 서비스를 위한 작업 디렉터리를 /var/opt/gitlab에 생성해야 합니다. 서비스를 실행하는 시스템 사용자가 만들어져 있어야 합니다. 서비스에 필요한 구성 파일을 작업 디렉터리에 렌더링해야 합니다.

레시피의 끝 부분에는 runit 서비스 정의를 호출하여 레시피를 정의해야 합니다. 이를 위해서는 쿡북의 templates/default 디렉터리에 실행 파일이 있어야 합니다. 이 파일 이름은 서비스 이름으로 시작하고, runit 액션 이름이 뒤에 이어져야 합니다.

서비스에는 일반적으로 run, log-run, log-config이 필요합니다.

sv-best-service-log-config.erb:

<%= "s#@svlogd_size" if @svlogd_size %>
<%= "n#@svlogd_num" if @svlogd_num %>
<%= "t#@svlogd_timeout" if @svlogd_timeout %>
<%= "!#@svlogd_filter" if @svlogd_filter %>
<%= "u#@svlogd_udp" if @svlogd_udp %>
<%= "p#@svlogd_prefix" if @svlogd_prefix %>

sv-best-service-log-run.erb:

#!/bin/sh
exec chpst -P \
  -U root:<%= @options[:log_group] || 'root' %> \
  -u root:<%= @options[:log_group] || 'root' %> \
  svlogd -tt <%= @options[:log_directory] %>

sv-best-service-run.erb:

#!/bin/sh
exec 2>&1
<%= render("mount_point_check.erb") %>
cd <%= node['gitlab']['best-service']['dir'] %>
exec chpst -P /opt/gitlab/embedded/bin/best-service -config-flags -etc

실행 중인 것에 따라 어느 사용자가 실행해야 하는지에 따라 run 파일을 다르게 구성해야 합니다. 예를 들어, 다른 -run.erb 파일을 참조하세요.

레시피 내에서 runit 서비스를 호출하고 시작해야 합니다:

runit_service "best-service" do
  options({
    configItem: 'value',
    [...]
    log_directory: logging_settings[:log_directory],
    log_user: logging_settings[:runit_owner],
    log_group: logging_settings[:runit_group],
  }.merge(params))
  log_options logging_settings[:options]
end

if node['gitlab']['bootstrap']['enable']
  execute "/opt/gitlab/bin/gitlab-ctl start best-service" do
    retries 20
  end
end

로그 디렉터리

위에서 언급된 예제 설정은 logging_settings를 사용하여 서비스 로그 디렉터리, 로그 디렉터리에 할당된 로그 그룹 및 svlogd 실행에 사용되는 구성 설정에 일관된 참조를 제공하기 위해 LogfilesHelper 클래스를 활용합니다.

이러한 설정을 사용하려면 서비스의 enable.rbLogfilesHelper 클래스를 포함하십시오. 예를 들어:

[...]
logfiles_helper = LogfilesHelper.new(node)
logging_settings = logfiles_helper.logging_settings('best-service')
[...]

서비스 로그 디렉터리에 사용되는 기본 사용자/그룹을 나타내는 default_logdir_ownership 클래스 메서드의 서비스 디렉터리에 best-service를 추가하고자 합니다. 특정한 사용자/그룹이 필요하지 않은 경우에는 기본적으로 { username: gitlab_user, group: gitlab_group }로 설정하십시오.

비활성화 레시피

기존 쿡북에 추가되는 경우 disable 레시피는 files/gitlab-cookbooks/<쿡북 이름>/recipes/<서비스 이름>_disable.rb로 생성되어야 합니다. 서비스에 별도의 쿡북이있는 경우 disable 레시피는 files/gitlab-cookbooks/<쿡북 이름>/recipes/disable.rb로 생성할 수 있습니다.

레시피에는 서비스를 비활성화할 때 수행할 모든 정리 작업이 포함되어야하며, runit 서비스를 비활성화하기 위한 호출을 포함해야합니다.

runit_service "best-service" do
  action :disable
end

로그 회전 처리 방법 결정 및 문서화

Omnibus에서 특정 서비스의 로그 회전logrotate, svlogd, 둘 다 또는 어느 쪽도 담당하지 않을 수 있습니다. 새로운 서비스를 Omnibus GitLab에 추가할 때는 다음을 수행해야합니다:

  • 새로운 서비스에 대한 로그 회전이 제대로 이루어졌는지 확인하십시오.
  • 로그 회전 테이블에 새로운 서비스가 추가되도록 하는 Merge Request을 오픈하십시오.

runit(svlogd)를 사용하지 않는 새로운 로그가 추가되는 경우 logrotate 구성에 로그를 매뉴얼으로 추가해야합니다. 더 많은 정보는 Improve logrotate handling 이슈에서 확인할 수 있습니다.

서비스를 위한 추가 구성 구문 분석

사용자가 설정한 기타 옵션에 따라 특정 구성 옵션을 채우고자 하는 경우에는 서비스에 대한 라이브러리를 추가해야합니다.

라이브러리는 files/gitlab-cookbooks/<쿡북 이름>/libraries/<서비스 이름>.rb로 추가되어야 합니다.

라이브러리는 서비스 이름으로 명명된 모듈이어야하며 parse_variables 메서드를 가져야합니다.

module BestService
  class << self
    def parse_variables
      # 사용자가 제공한 구성 값에 기반하여 일부 추가 구성을 설정합니다.
    end
  end
end

그런 다음 GitLab 구성에서 귀하의 parse_variables 메서드를 호출해야합니다.

files/gitlab-cookbooks/package/libraries/config/gitlab.rb에 들어가 귀하의 속성을 라이브러리를 사용하도록 업데이트하십시오.

attribute('best_service').use { BestService }

변수 구문 분석의 순서가 중요합니다. 따라서 라이브러리가 다른 서비스의 라이브러리 뒤에 구문 분석되기를 원한다면 기본값이 20priority값을 나중에 사용하도록 귀하의 속성을 업데이트해야합니다.

attribute('expected_service').use { ExpectedService }
attribute('best_service', sequence: 25).use { BestService }