GitLab 아키텍처 개요

GitLab의 소프트웨어 배포 방식, 주요 구성 요소 및 각 컴포넌트의 역할과 상호작용 구조를 설명합니다.

소프트웨어 배포 # GitLab에는 두 가지 소프트웨어 배포판이 있습니다: 오픈 소스 Community Edition (CE). 오픈 코어 Enterprise Edition (EE). EE 리포지터리는 보관(archived) 처리되었습니다. GitLab은 현재 단일 코드베이스 로 운영됩니다. GitLab은 다양한 구독 플랜 으로 이용할 수 있습니다. 새 버전의 GitLab은 안정(stable) 브랜치에서 릴리즈되며, main 브랜치는 최신 개발 버전에 사용됩니다. 자세한 내용은 GitLab 릴리즈 프로세스 를 참조하세요. 두 배포판 모두 추가 컴포넌트가 필요합니다. 이 컴포넌트들은 아래 컴포넌트 세부 정보 섹션에서 설명되며, 각각 독립적인 리포지터리를 갖습니다. 각 종속 컴포넌트의 새 버전은 보통 태그로 관리되지만, GitLab 코드베이스의 main 브랜치를 유지하면 해당 컴포넌트들의 최신 안정 버전을 사용할 수 있습니다. 새 버전은 일반적으로 GitLab 릴리즈와 거의 동시에 출시되며, 긴급 보안 업데이트는 예외일 수 있습니다. 컴포넌트 # GitLab의 일반적인 설치 환경은 GNU/Linux이지만, 쿠버네티스 플랫폼을 사용하는 배포 사례도 점점 증가하고 있습니다. 가장 큰 GitLab 인스턴스는 GitLab.com으로, 공식 GitLab Helm chart 와 공식 Linux 패키지 를 사용하여 배포됩니다. 일반적인 설치에서는 NGINX 또는 Apache를 웹 서버로 사용하여 GitLab Workhorse 를 통해 Puma 애플리케이션 서버로 요청을 프록시합니다. GitLab은 Puma 애플리케이션 서버를 사용하여 웹 페이지와 GitLab API 를 제공합니다. job 큐로는 Sidekiq을 사용하며, Sidekiq은 Redis를 job 정보, 메타데이터, 수신 job의 비영속(non-persistent) 데이터베이스 백엔드로 사용합니다. 기본적으로 Puma와 Workhorse 간의 통신은 Unix 도메인 소켓을 통해 이루어지지만, TCP를 통한 요청 전달도 지원됩니다. Workhorse는 gitlab/public 디렉터리에 접근하여 Puma 애플리케이션 서버를 거치지 않고 정적 페이지, 업로드(예: 아바타 이미지나 첨부 파일), 사전 컴파일된 에셋을 직접 제공합니다. GitLab 애플리케이션은 영속적인 데이터베이스 정보(예: 사용자, 권한, 이슈, 기타 메타데이터)를 저장하기 위해 PostgreSQL을 사용합니다. GitLab은 베어(bare) Git 리포지터리를 설정 파일의 repositories: 섹션 에 정의된 위치에 저장합니다. 또한 기본 브랜치와 훅 정보도 베어 리포지터리에 함께 보관합니다. HTTP/HTTPS를 통해 리포지터리를 제공할 때 GitLab은 GitLab API를 사용하여 인가 및 접근을 처리하고 Git 오브젝트를 제공합니다. 애드온 컴포넌트인 GitLab Shell은 SSH를 통해 리포지터리를 제공합니다. 설정 파일의 GitLab Shell 섹션 에 정의된 위치 내에서 SSH 키를 관리합니다. 해당 위치의 파