- 빌드 중 소프트웨어 가져오고 컴파일하기
- 서비스를 위한 최상위 구성 오브젝트 추가하기
- 서비스 디렉터리에 서비스 포함하기
- 서비스를 위한 활성화 및 비활성화 레시피 생성하기
- 로그 회전 처리 방법 결정 및 문서화
- 서비스를 위한 추가 구성 구문 분석
Omnibus GitLab에 새로운 서비스 추가하기
GitLab에 새로운 서비스를 추가하기 위해서는 다음 단계를 따라야 합니다:
- 빌드 중 소프트웨어 가져오고 컴파일하기
- 서비스를 위한 최상위 구성 오브젝트 추가하기
- 서비스 디렉터리에 서비스 포함하기
- 서비스를 위한 활성화 및 비활성화 레시피 생성하기
- 로그 회전 처리 방식 결정하고 문서화하기
선택적으로 다른 일반적인 작업으로는 서비스를 위한 추가 구성 구문 분석 이 있습니다.
빌드 중 소프트웨어 가져오고 컴파일하기
프로젝트에 이미 포함되어 있지 않은 경우, 서비스에 대한 새로운 소프트웨어 정의를 추가해야 합니다. 자세한 내용은 새로운 소프트웨어 정의를 참조하세요.
서비스를 위한 최상위 구성 오브젝트 추가하기
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
로 설정하고, 나중에 필요에 따라 기본값을 계산해야 합니다.
네이밍 규칙
서비스 이름은 주로 다음 세 가지 시나리오에서 참조됩니다.
- 서비스에 해당하는 Chef 속성에 액세스
- 사용자, 그룹 및 해당 서비스에 대한 경로와 같은 항목 참조
- 서비스 이름을 해당하는 속성을 찾는 메서드에 전달
- “서비스가 활성화되어 있는가?”
- “이 서비스에 해당하는 로그 소유권 세부 정보를 가져오기”
- “이 서비스에 대한 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.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 }
로 설정하십시오.
비활성화 레시피
기존 쿡북에 추가되는 경우 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 }
변수 구문 분석의 순서가 중요합니다. 따라서 라이브러리가 다른 서비스의 라이브러리 뒤에 구문 분석되기를 원한다면 기본값이 20
인 priority
값을 나중에 사용하도록 귀하의 속성을 업데이트해야합니다.
attribute('expected_service').use { ExpectedService }
attribute('best_service', sequence: 25).use { BestService }