• gitlab-ctl reconfigure 실행 시 발생하는 일
• 기본 레시피
  • config 레시피
    • gitlab.rb 파일에는 어떤 내용이 포함됩니까?
    • 기본 값 계산
    • 시크릿 처리
    • 최종 속성 디렉터리으로 노드 개체 업데이트
    • gitlab-cluster.json 파일

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

Omnibus GitLab은 Cinc를 내부에서 사용합니다. 이는 Chef Software Inc의 오픈 소스 소프트웨어의 무료 배포판입니다.

매우 기본적으로, gitlab-ctl reconfigure 실행 시 Cinc 클라이언트가 실행됩니다. 이 문서에서는 gitlab-ctl reconfigure 실행 중의 프로세스를 설명하고 제어의 흐름을 자세히 다룹니다.

gitlab-ctl reconfigure는 omnibus-ctl 프로젝트에서 정의되어 있으며, 앞서 언급한 바와 같이 로컬 모드에서 (-z 플래그를 사용하여) Cinc 클라이언트 실행을 수행합니다. 이 명령에는 두 개의 파일이 입력으로 사용됩니다:

• solo.rb라는 구성 파일
• 빌드 시 생성된 dna.json이라는 속성 파일이 로드됩니다. 이 파일은 다음을 로드합니다:
  • CE의 경우 gitlab 쿡북이 사용됩니다.
  • EE의 경우 gitlab-ee 쿡북이 사용됩니다.

그런 다음 Cinc는 선택한 쿡북에 대해 two-pass 실행 모델을 따릅니다.

로드 단계에서는 주 쿡북과 해당 의존 쿡북들(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 레시피는 /etc/gitlab/gitlab.rb 파일에서 정적 기본 값, 계산된 기본 값, 사용자가 지정한 값들을 Merge한 후 다양한 설정에 대한 최종 값을 node 객체에 채웁니다.

위 문에서 우리는 두 가지 유형의 기본 값에 대해 언급합니다:

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

예를 들어, gitlab_rails['gitlab_port']는 정적 기본 값인 80으로 기본 설정됩니다. 이는 GitLab Rails 리스너 포트를 구성하는 렌더링된 gitlab.yml 파일에서 production.gitlab.port로 변환됩니다. gitlab_rails['pages_host']와 gitlab_rails['pages-port'] 값은 GitLab Pages에 대한 정보를 전달하여 GitLab Rails가 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는 관련된 설정의 정적 기본 값 또는 사용자가 지정한 값에 따라 기본 값을 설정합니다. 이러한 관련 설정의 기본 값은 Cinc 실행의 로드 단계 이후에 node 객체에서 사용할 수 있습니다. 이 node 객체는 레시피에서 사용할 수 있지만 라이브러리에서는 사용할 수 없습니다. 정적 기본 값이 라이브러리에서 사용할 수 있도록 하기 위해 구성 레시피에서 아래의 코드를 사용하여 GitLab 객체에 node 객체를 연결합니다:

Gitlab[:node] = node

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

Gitlab 객체는 기본적으로 gitlab.rb에서 지정된 대로 키를 저장합니다. node은 정의된 중첩 속성 블록-속성 계층에 따라 키를 저장합니다.

따라서 gitlab_rails 설정은 gitlab.rb의 경우 Gitlab['gitlab_rails'][*]을 연달아 사용하며, 레시피 파일의 경우 Gitlab[:node]['gitlab']['gitlab_rails']에서 기본 값이 사용됩니다. gitlab_rails 키는 gitlab 속성 블록 아래에 지정되어 있으므로 레시피를 통해 액세스할 때 추가적인 중첩 계층이 존재합니다.

Gitlab 객체는 기술적으로 gitlab.rb에서 지정된 설정만을 보유해야 하지만, 일반적으로 다른 설정에 의존하는 설정의 기본 값을 계산할 때 이러한 설정을 주로 Gitlab 키 자체 아래에 둡니다. 이 동작을 변경하기 위해 이슈 #3932가 열려 있습니다.

시크릿 처리

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

이러한 시크릿은 /etc/gitlab/gitlab-secrets.json이라는 이름의 파일에 쓰여집니다(명시적으로 비활성화되지 않은 경우). 이 파일은 후속 재구성 실행에서 읽혀지며 시크릿은 모든 재구성 실행에서 지속됩니다.

최종 속성 디렉터리으로 노드 개체 업데이트

모든 라이브러리가 각자의 속성과 시크릿을 구문 분석한 후 최종 구성은 기본 node에 이미 존재하는 기본 속성과 Merge 준비가 됩니다. node.consume_attributes 메서드는 최종 구성을 로드 단계에서 채워진 기본 구성과 Merge합니다. gitlab.rb에서 읽은 구성 또는 라이브러리에서 계산된 어떠한 구성도 node 객체에서 키가 일치하는 값에 덮어씁니다. 이 시점에서 node 객체에 최종 속성 디렉터리이 포함됩니다.

gitlab-cluster.json 파일

사용자는 요구 사항과 일치하도록 gitlab.rb를 사용하여 시스템을 구성합니다. 그러나 특정 시나리오에서는 gitlab.rb 파일을 변경하지 않고 변경 사항을 수행해야 할 수 있습니다. Omnibus GitLab은 다른 파일, /etc/gitlab/gitlab-cluster.json에 기록하는데 사용자가 gitlab.rb에서 지정한 값을 덮어씁니다. gitlab-ctl 명령 또는 재구성은 동적으로 이 파일을 채우며 이는 구성 레시피의 끝에서 node 속성을 통해 읽혀지고 Merge됩니다.

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

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

EE Cookbook의 기본 레시피는 기본적으로 gitlab::default 레시피를 호출한 후에 EE별 컴포넌트를 별도로 처리합니다.