gitlab-ctl reconfigure 실행 시 발생하는 일

Omnibus GitLab은 하부에서 Chef Software Inc의 오픈 소스 소프트웨어의 무료 배포인 Cinc을 사용합니다.

매우 기본적으로 gitlab-ctl reconfigure가 실행될 때 Cinc 클라이언트 실행이 발생합니다. 이 문서에서는 gitlab-ctl reconfigure 실행 중의 프로세스를 상세히 다루고 흐름을 설명합니다.

gitlab-ctl reconfigure는 omnibus-ctl 프로젝트에 정의되어 있으며 앞에서 언급한대로 로컬 모드(-z 플래그를 사용)에서 하부에서 cinc-client 실행을 수행합니다. 이 호출은 두 개의 파일을 입력으로 사용합니다.

그런 다음 Cinc는 선택한 쿡북에 대해 이중 패스 실행 모델을 따릅니다.

로드 단계에서는 주 쿡북과 해당 의존 쿡북들(metadata.rb 파일에 언급됨)이 로드됩니다. 이러한 쿡북들의 기본 속성 파일에 언급된 속성들이 로드되며(따라서 해당 속성 파일에서 지정된 기본 값을 가진 node 객체가 채워집니다) 사용할 수 있는 사용자 정의 리소스가 모두 제공됩니다. 그런 다음 제어는 실행 단계로 이동합니다. dna.json 파일에서 run_list로 쿡북 이름을 지정하면 Cinc가 기본 레시피를 유일한 항목으로 사용합니다.

gitlab-ee 쿡북은 EE 전용 기능을 가진 gitlab 쿡북을 확장합니다. 설명을 위해 먼저gitlab 쿡북의 기본 레시피을 살펴보겠습니다.

기본 레시피

기본 레시피의 기능은 다음과 같이 요약할 수 있습니다:

  1. config 레시피를 호출하여 gitlab.rb에서 속성을 로드하고 node 객체를 완전히 채웁니다.
  2. 사용되지 않는 설정을 확인하고 조기 종료합니다.
  3. 실행 환경에서 문제가 있는지 확인합니다. 예를 들어, LD_LIBRARY_PATH가 정의되어 있으면 포함된 라이브러리와 소프트웨어의 링크 방식에 영향을 미칠 수 있으며 경고가 발생할 수 있습니다.
  4. 유효하지 않은 UTF-8 로케일을 확인하고 경고를 발생시킵니다.
  5. /etc/gitlab(명시적으로 비활성화되지 않은 경우), /var/opt/gitlab, /var/log/gitlab와 같이 필요한 기본 디렉토리를 생성하고 구성합니다.
  6. 다른 필요한 도우미 레시피를 호출하고 다른 서비스에 대해 레시피를 활성화하거나 비활성화합니다.

이 요약이 완전하지는 않음에 유의하세요. 자세한 내용은 기본 레시피 코드를 확인하세요.

config 레시피

config 레시피는 node 객체를 gitlab.rb 파일에서 정적 기본 값, 계산된 기본 값 및 사용자 값과 병합한 후의 최종 값으로 채웁니다.

위 명령문에서 두 가지 유형의 기본 값을 언급했습니다:

  • 정적: 정적 기본 값은 다른 쿡북의 여러 속성 파일에 지정되어 독립적으로 설정됩니다.
  • 계산된: 계산된 기본 값은 설정의 기본값이 다른 설정의 정적 기본 값 또는 사용자 지정 값에 따라 달라지는 경우에 사용됩니다.

예를 들어, gitlab_rails['gitlab_port']의 기본값은 정적 기본값인 80입니다. 이는 GitLab Rails 리스너 포트를 구성하는 렌더링된 gitlab.yml 파일에서 production.gitlab.port로 변환됩니다. gitlab_rails['pages_host'] 및 gitlab_rails['pages-port'] 값은 GitLab Rails에게 GitLab Pages에 대한 정보를 전달하는데, 이는 pages_external_url에서 사용자가 지정한 값에 따라 달라집니다. 이러한 기본값의 계산은 gitlab.rb 파일을 파싱한 후에만 발생할 수 있습니다.

gitlab.rb 파일에는 무엇이 포함됩니까?

Omnibus GitLab은 gitlab.rb에 지정된 설정을 저장하기 위해 Gitlab이라는 모듈을 사용합니다. 이 모듈은 Mixlib::Config 모듈을 확장하여 구성 해시로 작동할 수 있습니다. 이 모듈의 정의에서는 gitlab.rb에서 지정할 수 있는 다양한 역할, 속성 블록 및 최상위 속성을 등록합니다. 이러한 등록에 대한 코드는 SettingsDSL 모듈에 명시되었으며 GitLab 모듈에서 확장됩니다.

config 레시피에서 Gitlab.from_file이 호출되면 gitlab.rb의 설정이 구문 분석되어 Gitlab 객체로 로드되고 Gitlab['<setting_name>']를 통해 액세스할 수 있습니다.

한 번 gitlab.rb가 구문 분석되어 그 값이 Gitlab 객체에서 사용 가능하게 되면 다른 설정에 종속된 설정의 기본 값을 계산할 수 있습니다.

기본값의 계산

계산이 필요한 속성을 가진 각 구성 요소는 등록 시 라이브러리 파일을 지정합니다. 이 파일의 하나의 메서드인 parse_variables는 사용자가 제공한 입력을 유효성 검사하고 일반적으로 사용 시 사용자가 값을 이미 지정하지 않았다면 기본 값을 설정합니다. 이 코드는 잘못된 구성을 감지하고 오류를 발생시킵니다.

위에서 언급했듯이, parse_variables는 관련 설정의 정적 기본값 또는 레시피에서 로드 단계 이후에 node 객체에서 사용자가 제공한 값에 기초하여 기본 값을 설정합니다. 이러한 관련 설정의 기본값은 Cinc 실행의 로드 단계 이후 node 객체에서 사용 가능합니다. 이 node 객체는 레시피에서 사용 가능하지만 라이브러리에서는 사용할 수 없습니다. 라이브러리에서 정적 기본값을 사용할 수 있도록 하려면 다음 코드를 사용하여 config 레시피에서 node 객체를 GitLab 객체에 첨부합니다. 

Gitlab[:node] = node

이로써 속성의 정적 기본 값에 Gitlab[:node]['<top-level-key>'][<setting>]를 사용하여 라이브러리에서 액세스할 수 있습니다.

여기서 주의할 점은:

  • Gitlab 객체는 gitlab.rb에 언급된대로 키 값을 저장합니다.
  • node은 정의된 중첩 속성-블록-속성 계층 구조에 기반하여 값들을 저장합니다.

그래서 gitlab.rb의 gitlab_rails 설정은 Gitlab['gitlab_rails'][*]로 사용 가능하며, 해당 설정의 기본값은 Gitlab[:node]['gitlab']['gitlab_rails']로 액세스할 수 있습니다. gitlab_rails 키는 gitlab 속성 블록 아래에 지정되어 있으므로 node를 통해 액세스할 때 추가적인 중첩 레벨이 있습니다.

이후 설정의 기본값을 계산할 때 Gitlab 객체 자체에 넣는 것이 일반적입니다. Issue #3932에서 이 동작을 변경하려는 것이 열려 있습니다.

Secrets 처리

GitLab 기능을 위해 필요한 많은 속성은 다시 구성 실행 간과, 다중 노드 설정에서 다른 노드 간에 지속되어야 하는 비밀입니다. 또한, 사용자가 이러한 비밀에 대한 값들을 지정하지 않은 경우 Omnibus GitLab은 기능을 위해 이를 생성해야 합니다. 이를 위해 각 라이브러리 파일은 parse_variables 방법과 유사한 parse_secrets 방법을 지정합니다. 이 방법은 gitlab.rb 파일에 지정된 비밀이 없는 경우 (명시적으로 비활성화되지 않은 경우) 비밀을 생성합니다.

이러한 비밀은 (명시적으로 비활성화되지 않은 경우) /etc/gitlab/gitlab-secrets.json이라는 파일에 작성됩니다. 이 파일은 후속 다시 구성 실행에서 읽히며, 비밀은 각 다시 구성 실행에서 지속됩니다.

노드 객체를 최종 속성 목록으로 업데이트

모든 라이브러리가 해당 속성 및 비밀을 구문 분석한 후 최종 구성은 node에 이미 존재하는 기본 속성과 병합할 준비가 됩니다. node.consume_attributes 방법은 최종 구성을 로드 단계에서 채워진 기본 구성과 병합합니다. gitlab.rb에서 읽힌 구성 또는 라이브러리에서 계산된 모든 구성은 node 객체에서 일치하는 키의 값에 덮어씁니다. 이 시점에 node 객체에는 최종 속성 목록이 포함됩니다.

gitlab-cluster.json 파일

사용자는 gitlab.rb로 시스템을 구성하고 요구 사항에 맞게 조정합니다. 그러나 특정 시나리오에서는 gitlab.rb 파일을 변경하지 않고 변경을 수행해야 할 수 있습니다. Omnibus GitLab은 /etc/gitlab/gitlab-cluster.json이라는 다른 파일에 사용자가 gitlab.rb에서 지정한 값들을 재정의합니다. gitlab-ctl 명령 또는 다시 구성은 이 파일을 동적으로 채워서 구성 레시피의 끝에서 node 속성들에 대해 읽고 병합합니다.

gitlab-ctl geo promote 명령은 Patroni를 사용하는 다중 노드 PostgreSQL 인스턴스에서 Patroni 스탠바이 서버를 비활성화해야 합니다. 이 예제에서는 스탠바이 서버가 일반적으로 gitlab.rb의 patroni['standby_cluster']['enable']을 통해 비활성화됩니다. gitlab.rb 파일은 Cinc 실행 기간 동안 읽기 전용으로 유지되어야 하므로 이 설정은 gitlab-cluster.json 파일에서 변경됩니다. 향후 다시 구성 실행에서 gitlab-cluster.json 파일이 구문 분석되며 node['patroni']['standby_cluster']['enable']은 false로 평가될 것입니다.

Cinc 실행은 구성 레시피 이후에 도우미 및 서비스별 레시피를 실행합니다. 이들이 완료되면 노드 객체는 완전히 채워지고 레시피 및 리소스에서 사용할 수 있습니다.

EE 쿡북의 기본 레시피는 기본적으로 gitlab::default 레시피를 호출하고 EE별 구성요소를 별도로 처리합니다.