• 빌드 중 소프트웨어 가져오기 및 컴파일
• 서비스에 대한 최상위 구성 객체 추가
  • 기본 속성 정의
    • 명명 규칙
  • 서비스에 대한 구성 Mash 만들기
  • 서비스 구성을 설정 템플릿에 추가
• 서비스 목록에 서비스 포함
• 서비스에 대한 활성화 및 비활성화 레시피 만들기
  • 활성화 레시피
    • 로그 디렉토리
  • 비활성화 레시피
• 로그 순환 처리 방법 결정 및 문서화
• 서비스에 대한 추가 구성 파싱

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. 서비스 속성을 조회하는 메서드에 서비스 이름 전달

위에서 언급된 첫 번째 경우, 서비스 이름의 단어를 구분하기 위해 언더스코어를 사용합니다. 나머지 두 가지 경우에는 대시를 사용하여 서비스 이름의 단어를 구분합니다. 구성이 주로 Ruby 객체로 사용되기 때문에, 대시보다 언더스코어를 사용하는 것이 더 유연합니다 (예: 언더스코어를 사용하면 구성 해시에서 기호를 사용하는 것이 더 깔끔해집니다).

예를 들어, 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['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 파일에서,

서비스를 적절한 Config 클래스, Base 또는 EE에 추가해야 합니다.

서비스가 GitLab EE 전용인지에 따라 다릅니다.

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

그룹을 지정하면 관련 서비스 여러 개를 동시에 비활성화/활성화하기가 더 쉽습니다.

현재 귀하의 서비스와 일치하는 기존 그룹이 없고,

그룹을 사용하여 서비스를 활성화/비활성화할 필요가 없는 경우.

지금은 추가하지 마십시오.

사용할 수 있는 기존 그룹의 몇 가지 예:

• 서비스가 기본적으로 omnibus에서 활성화된 경우, DEFAULT_GROUP 그룹을 추가해야 합니다.
• 서비스가 거의 모든 시나리오에서 비활성화되지 않아야 하는 경우, SYSTEM_GROUP을 추가하십시오.
• 서비스가 GitLab Rails의 구성을 필요로 하는 경우, rails 그룹을 추가하십시오.
• 서비스가 새로운 Prometheus 수출업체인 경우, prometheus 그룹을 추가하십시오.

서비스에 대한 활성화 및 비활성화 레시피 만들기

활성화 레시피

활성화 레시피는 files/gitlab-cookbooks/<cookbook-name>/recipes/<service-name>.rb로 만들어야 하며

기존의 조리법에 추가하는 경우입니다. 서비스에 자체 조리법이 있는 경우,

활성화 레시피는 files/gitlab-cookbooks/<cookbook-name>/recipes/enable.rb로 생성할 수 있습니다.

레시피에서는 /var/opt/gitlab에서 귀하의 서비스에 대한 작업 디렉터리를 생성해야 합니다.

서비스를 실행하는 시스템 사용자가 생성되도록 해야 합니다.

서비스에 필요한 구성 파일을 작업 디렉터리로 렌더링하십시오.

레시피의 끝 부분 근처에서 runit 서비스 정의에 호출하여

귀하의 레시피를 정의해야 합니다. 이를 위해서는 cookbooks의 templates/default 디렉터리에

실행 파일을 생성해야 합니다. 이러한 파일 이름은 sv-로 시작하고,

그 다음에 서비스 이름, 그 다음에 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를 포함하여 LogfilesHelper 클래스를 사용하여 서비스 로그 디렉토리에 대한 구성 설정, 로그 디렉토리에 할당된 로그 그룹, 그리고 svlogd 실행에 사용되는 그룹에 대한 일관된 참조를 제공합니다.

이 설정을 사용하려면, 서비스의 enable.rb에 LogfilesHelper 클래스를 포함시키십시오. 예를 들면:

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

default_logdir_ownership 클래스 메서드에 로그 디렉토리 사용자/그룹에 사용될 기본 사용자/그룹과 함께 best-service를 서비스 목록에 추가하십시오. 특정 사용자/그룹이 필요하지 않으면 기본값인 { username: gitlab_user, group: gitlab_group }로 설정하십시오.

비활성화 레시피

비활성화 레시피는 files/gitlab-cookbooks/<cookbook-name>/recipes/<service-name>_disable.rb로 생성해야 하며, 기존의 요리책에 추가하는 경우입니다. 서비스에 자체 요리책이 있는 경우, 비활성화 레시피는 files/gitlab-cookbooks/<cookbook-name>/recipes/disable.rb로 생성할 수 있습니다.

레시피에는 서비스가 비활성화될 때 수행하고자 하는 정리 작업을 포함해야 하며, runit 서비스를 비활성화하는 호출이 있어야 합니다.

runit_service "best-service" do
  action :disable
end

로그 순환 처리 방법 결정 및 문서화

Omnibus에서 주어진 서비스에 대한 로그 순환은 logrotate, svlogd, 둘 다 또는 둘 다 아닐 수 있습니다. 새로운 서비스는 해당 서비스의 로그를 관리하고 순환하는 책임이 무엇인지에 대한 표시와 함께 로그 순환 표에 포함되어야 합니다. Omnibus GitLab에 서비스를 추가할 때 다음을 확인해야 합니다:

• 새로운 서비스에 대한 로그 순환이 설정되어 있는지 확인합니다.
• 새로운 서비스를 로그 순환 테이블에 추가하기 위한 병합 요청을 엽니다.

runit (svlogd)를 사용하지 않는 새 로그가 추가되는 경우, 로그는 수동으로 logrotate 구성에 추가되어야 합니다. 로그 회전 처리 개선 이슈에 더 많은 정보가 있습니다.

서비스에 대한 추가 구성 파싱

사용자가 설정한 다른 옵션에 따라 특정 구성 옵션을 채우고 싶다면, 해당 변수를 파싱하기 위한 서비스에 대한 라이브러리를 추가합니다.

라이브러리는 files/gitlab-cookbooks/<cookbook name>/libraries/<service-name>.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 }

변수 파싱 순서가 중요하다는 점에 유의하십시오. 따라서 라이브러리가 다른 서비스의 라이브러리 이후에 파싱되기를 기대하는 경우, 속성을 업데이트하여 나중에 오는 priority 값을 설정해야 합니다. (기본 priority 값은 20입니다.)

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