• 기본 레시피
  • 구성 레시피
    • 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 프로젝트에 정의되어 있으며, 위에서 언급한 바와 같이, 로컬 모드에서 cinc-client 실행을 수행합니다(이를 위해 -z 플래그를 사용합니다). 이 호출은 두 개의 파일을 입력으로 받습니다:

• solo.rb라는 이름의 구성 파일.
• 빌드 시간에 생성된 속성 파일인 dna.json, 이 파일은 다음을 로드합니다:
  • CE의 경우, gitlab 요리책.
  • EE의 경우, gitlab-ee 요리책.

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. 다른 필수 도우미 레시피를 호출하고 서로 다른 서비스에 대한 레시피를 활성화하거나 비활성화합니다, 등.

이 요약은 완전하지 않습니다. 더 많은 정보를 얻으려면 기본 레시피 코드를 확인하세요.

구성 레시피

구성 레시피는 정적 기본 값, 계산된 기본 값 및 사용자가 /etc/gitlab/gitlab.rb 파일에 지정한 값들을 병합한 후에 다양한 설정에 대한 최종 값을 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 모듈에 의해 확장됩니다.

구성 레시피에서 Gitlab.from_file이 호출되면 gitlab.rb의 설정이 파싱되어 Gitlab 객체에 로드되며, Gitlab['<setting_name>']를 통해 접근할 수 있습니다.

한 번 gitlab.rb가 파싱되고 그 값이 Gitlab 객체에서 사용 가능해지면, 다른 설정에 의존하는 설정의 기본 값을 계산할 수 있습니다.

기본 값의 계산

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

위에서 언급했듯이, parse_variables는 정적 기본 값 또는 관련 설정의 사용자 제공 값에 따라 기본 값을 설정합니다. 이러한 관련 설정의 기본 값은 Cinc 실행의 로드 단계 후에 node 객체에서 사용 가능합니다. 이 node 객체는 레시피에서 사용 가능하지만 라이브러리에서는 사용 불가능합니다. 정적 기본 값을 라이브러리에서 사용 가능하게 하려면, 다음 코드로 구성 레시피에서 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 객체는 gitlab.rb에 지정된 설정만 보유해야 하지만, 다른 설정을 기반으로 한 설정의 기본 값을 계산할 때는 일반적으로 이를 Gitlab 키 그 자체에 두곤 합니다. 문제 #3932가 이 행동을 변경하기 위해 열려 있습니다.

비밀 관리

GitLab 기능에 필요한 많은 속성들은 영구적으로 유지되어야 하는 비밀입니다.

재구성 실행 사이에서, 그리고 다중 노드 설정에서는 서로 다른 노드 간에 유지되어야 합니다.

또한, 사용자가 이러한 비밀에 대한 값을 지정하지 않은 경우, Omnibus GitLab은 기능을 위해 이들을 생성해야 합니다.

이런 목적을 위해 각 라이브러리 파일은 parse_secrets 메소드를 명시합니다.

이는 parse_variables 메소드와 유사합니다.

이 메소드는 gitlab.rb 파일에 지정되지 않은 경우, 명시적으로 비활성화하지 않는 한 비밀을 생성합니다.

이 비밀들은 명시적으로 비활성화하지 않는 한 /etc/gitlab/gitlab-secrets.json라는 파일에 기록됩니다.

이 파일은 이후의 재구성 실행에서 읽히며, 비밀은 모든 재구성 실행 사이에서 유지됩니다.

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

모든 라이브러리가 각자의 속성과 비밀을 파싱한 후, 최종 구성은 노드에 이미 존재하는 기본 속성과 병합할 준비가 됩니다.

node.consume_attributes 메소드는 최종 구성을 로드 단계에서 채워진 기본 구성과 병합합니다.

gitlab.rb에서 읽은 구성이나 라이브러리에서 계산된 구성은 node 객체에서 일치하는 키의 값을 덮어씁니다.

이 시점에서 node 객체에는 최종 속성 목록이 포함됩니다.

gitlab-cluster.json 파일

사용자는 요구 사항에 맞게 gitlab.rb로 시스템을 구성합니다.

그러나 특정 시나리오에서는 gitlab.rb 파일 변경 없이 수정 작업을 수행해야 합니다.

Omnibus GitLab은 사용자 지정 값을 gitlab.rb에서 오버라이드하는 다른 파일인 /etc/gitlab/gitlab-cluster.json에 기록합니다.

gitlab-ctl 명령어 또는 재구성은 이 파일을 동적으로 채우며, 이 파일은 구성 레시피의 끝에서 node 속성 위로 읽히고 병합됩니다.

다중 노드 PostgreSQL 인스턴스에서 Patroni와 함께 사용할 때, gitlab-ctl geo promote 명령어는 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 전용 구성 요소를 별도로 처리합니다.