루닛 (runit)

루닛

GitLab은 서비스 관리 및 감독을 위해 runit 레시피를 사용합니다. runit 레시피는 OS에서 사용하는 init 시스템을 식별하는 작업을 수행하고 GitLab에 필요한 서비스 파일 생성, 서비스 활성화, 서비스 재로딩과 같은 기본적인 서비스 관리 작업을 수행합니다. runit은 runit_service서비스와 상호 작용하기 위해 다른 레시피에서 사용할 수 있는 정의를 제공 /files/gitlab-cookbooks/runit 합니다. 자세한 내용은 를 참조하십시오.

서비스

서비스는 runit 프로세스 init/supervisor를 사용하여 실행하는 소프트웨어 프로세스입니다. gitlab-ctl명령 을 사용하여 상태를 확인하고 시작, 중지 및 다시 시작할 수 있습니다 . 레시피는 또한 프로세스 그룹과 GitLab 인스턴스에 대해 구성된 설정/역할을 기반으로 이러한 서비스를 비활성화하거나 활성화할 수 있습니다. 서비스 목록 및 이와 연결된 서비스 그룹은 에서 찾을 수 있습니다 files/gitlab-cookbooks/package/libraries/config/services.rb.

추가 gitlab-ctl명령

gitlab-ctl reconfigure Omnibus는 기본적으로 및 gitlab-ctl restartGitLab 인스턴스를 관리하기 위한 몇 가지 래퍼 명령을 제공 합니다. Omnibus GitLab 리포지토리에 정의된 일부 특정 사용 사례를 대상 으로 하는 몇 가지 추가 래퍼 명령 이 있습니다. 이러한 명령은 일반 gitlab-ctl명령과 함께 사용되어 데이터베이스 마이그레이션 실행 또는 휴면 계정 제거 및 일반적이지 않은 유사한 작업과 같은 특정 작업을 수행합니다.

테스트

Omnibus GitLab 리포지토리는 ChefSpec을 사용하여 제공 되는 요리 책과 레시피를 테스트합니다 . 일반적인 전략은 사용자가 해당 구성을 지정하지 않은 경우(즉, 기본값이 사용되는 경우)와 사용자가 지정한 구성이 사용되는 경우의 두 가지(또는 그 이상) 조건에서 올바르게 작동하는지 확인하기 위해 레시피를 확인하는 것입니다. 테스트에는 파일이 올바른 위치에서 생성되었는지, 서비스가 시작/중지/통지되었는지, 올바른 바이너리가 호출되었는지, 올바른 매개변수가 메서드 호출에 전달되었는지 확인하는 작업이 포함될 수 있습니다. 레시피 및 라이브러리 메소드에는 연관된 테스트가 있습니다. Omnibus GitLab은 또한 테스트 프로세스를 돕기 위해 몇 가지 지원 방법이나 매크로를 사용합니다. 테스트는 전체 테스트 제품군을 실행하는 데 필요한 시간을 줄이기 위해 가능한 경우 병렬화와 호환되도록 정의됩니다.

따라서 위에서 설명한 구성 요소 중 일부(예: 소프트웨어 정의, 프로젝트 메타데이터 및 테스트)는 패키지 빌드 중, 빌드 환경에서 사용하고 일부(예: Chef 요리 책 및 레시피, GitLab 구성 파일, runit 및 gitlab-ctl명령)은 사용자의 설치된 인스턴스를 구성하는 데 사용됩니다.

Omnibus GitLab의 작업 수명 주기

패키지 빌드 중에 일어나는 일

빌드되는 패키지 유형은 빌드 프로세스가 실행되는 OS에 따라 다릅니다. 데비안 환경에서 빌드하면 .deb패키지가 생성됩니다. 패키지 빌드 중에 일어나는 일은 다음 단계로 요약할 수 있습니다.

1. 종속성 소프트웨어 소스 가져오기:
   1. 해당 버전을 찾기 위해 소프트웨어 정의를 구문 분석합니다.
   2. 원격 또는 캐시에서 소스 코드를 가져옵니다.
2. 개별 소프트웨어 구성 요소 구축:
   1. 필요한 환경 변수 및 플래그 설정.
   2. 해당하는 경우 패치를 적용합니다.
   3. 적절한 위치(내부)에 설치하는 것과 관련된 구성 요소의 빌드 및 설치를 수행합니다 /opt/gitlab.
3. 외부 소프트웨어, Ruby gem 및 JS 모듈을 포함한 모든 번들 구성 요소의 라이선스 정보 생성. 여기에는 각 종속성에 대한 정의와 구성 요소에서 제공하는 추가 라이선스 문서(예 licenses.csv: GitLab Rails에서 제공하는 파일) 분석이 포함됩니다.
4. 호환되지 않는 라이선스가 있는 구성 요소를 배송하지 않도록 구성 요소의 라이선스 확인
5. 패키지에서 상태 확인을 실행하여 바이너리가 사용 가능한 라이브러리에 연결되어 있는지 확인합니다. 번들 라이브러리의 경우 바이너리는 전역적으로 사용 가능한 라이브러리가 아니라 해당 라이브러리에 대해 링크되어야 합니다.
6. 의 내용으로 패키지를 빌드합니다 /opt/gitlab. 이것은 파일 내부에 제공된 메타데이터를 사용 gitlab.rb합니다. 여기에는 패키지 이름, 버전, 관리자, 홈페이지 및 다른 패키지와의 충돌 정보가 포함됩니다.

캐싱

Omnibus는 빌드 프로세스를 최적화하기 위해 두 가지 유형의 캐시를 사용합니다. 하나는 소프트웨어 아티팩트(종속 소프트웨어의 소스)를 저장하는 것이고 다른 하나는 각 소프트웨어 구성 요소가 빌드된 후 프로젝트 트리를 저장하는 것입니다.

소프트웨어 아티팩트 캐시(GitLab Inc 빌드용)

소프트웨어 아티팩트 캐시는 Amazon S3 버킷을 사용하여 종속 소프트웨어의 소스를 저장합니다. 빌드 프로세스에서 이 캐시는 명령을 사용하여 채워집니다 bin/omnibus cache populate. 그러면 Amazon 버킷에서 필요한 모든 소프트웨어 소스를 가져와 필요한 위치에 저장합니다. 소프트웨어의 버전 요구 사항에 변경 사항이 있으면 옴니버스가 원래 업스트림에서 이를 가져와 아티팩트 캐시에 추가합니다. 이 프로세스는 옴니버스 내부에 있으며 리포지토리 루트에서 사용 가능한 omnibus.rb 파일에서 사용하도록 Amazon 버킷을 구성합니다. 이 캐시는 원래의 업스트림 리모컨이 다운되더라도 종속 소프트웨어의 가용성을 보장합니다.

캐시 빌드

빌드 프로세스에서 중요한 역할을 하는 두 번째 유형의 캐시는 빌드 캐시입니다. 빌드 캐시는 프로젝트 트리의 스냅샷으로 설명할 수 있습니다(프로젝트가 실제로 빌드되는 위치 -/opt/gitlab) 각 종속 소프트웨어가 빌드된 후. 5개의 종속 소프트웨어(A, B, C, D 및 E)가 있는 프로젝트를 생각해 보십시오. 이 순서대로 빌드되며 개별 종속성은 고려하지 않습니다. 빌드 캐시는 Git 태그를 사용하여 스냅샷을 만듭니다. 각 소프트웨어가 빌드된 후 Git 태그가 계산되고 커밋됩니다. 이제 소프트웨어 D. A, B, C 및 E의 정의를 일부 변경했다고 가정해 보겠습니다. 우리가 다시 빌드를 시도하면 옴니버스는 이전 빌드에서 D가 빌드되기 전에 만들어진 스냅샷을 재사용할 수 있습니다. 따라서 C가 빌드된 후 생성된 스냅샷을 간단히 확인할 수 있어 A, B, C 빌드에 소요되는 시간을 절약할 수 있습니다. Omnibus는 캐시를 "더티"한 소프트웨어 직전의 스냅샷을 사용합니다(더러움은 소프트웨어 정의 변경, 이전 구성 요소의 이름/버전 변경, 또는 현재 구성 요소의 버전 변경)이 빌드되었습니다. 마찬가지로 빌드에서 소프트웨어 A의 정의가 변경되면 캐시가 더러워지므로 A와 다음 모든 종속성이 처음부터 빌드됩니다. C가 캐시를 더럽히면 A와 B가 재사용되고 C, D, E가 처음부터 다시 빌드됩니다.

이 캐시는 빌드 간에 유지되는 경우에만 의미가 있습니다. 이를 위해 GitLab CI의 캐싱 메커니즘을 사용합니다. Amazon 버킷에 내부 캐시를 저장하도록 구성된 전용 실행기가 있습니다. 각 빌드 전에 이 캐시( restore_cache_bundleMakefile의 대상)를 가져와 적절한 위치로 이동하고 빌드를 시작합니다. 더러워지는 시점까지 옴니버스에서 사용합니다. 빌드 후 새 캐시를 포장하고 CI에 이를 Amazon 버킷( pack_cache_bundleMakefile에 있음)에 백업하도록 지시합니다.

두 가지 유형의 캐시는 GitLab의 전체 빌드 시간과 외부 요인에 대한 종속성을 줄입니다.

캐시 메커니즘은 다음과 같이 요약할 수 있습니다.

1. 각 소프트웨어 종속성:
   1. 버전 및 SHA256을 이해하기 위해 정의를 구문 분석합니다.
   2. Amazon 버킷의 아티팩트 캐시에서 사용 가능한 소스 파일 tarball이 버전 및 SHA256과 일치하는 경우 사용하십시오.
   3. 그렇지 않으면 업스트림 리모컨에서 올바른 tarball을 다운로드하십시오.
2. CI 캐시에서 빌드 캐시를 가져옵니다.
3. 각 소프트웨어 종속성:
   1. 캐시가 더러워지면 루프를 끊습니다.
   2. 그렇지 않으면 스냅샷을 확인하십시오.
4. 나머지 종속성이 있는 경우:
   1. 나머지 종속성 각각에 대해 다음을 수행합니다.
      1. 종속성을 구축합니다.
      2. 스냅샷을 만들고 커밋합니다.
5. 새 빌드 캐시를 CI 캐시로 다시 푸시합니다.

동안 일어나는 일 gitlab-ctl reconfigure

GitLab 인스턴스를 관리하는 동안 일반적으로 사용되는 명령 중 하나는 gitlab-ctl reconfigure. 간단히 말해서 이 명령은 구성 파일을 구문 분석하고 제공된 값으로 레시피를 실행합니다. 실행할 레시피 는 설치 디렉토리 내부 dna.json의 폴더에 있는 이라는 파일에 정의되어 있습니다 embedded(이 파일은 소프트웨어 정의에 정의된 소프트웨어 종속성에 의해 생성됨 gitlab-cookbooks). GitLab CE의 경우 이름 gitlab이 지정된 요리책이 마스터 레시피로 선택되어 차례로 runit을 포함한 다른 모든 필요한 레시피를 호출합니다. 간단히 말해서, 재구성은 기본적으로 구성 템플릿에 제공된 값으로 다양한 파일과 서비스를 구성하는 요리사-클라이언트 실행입니다.