GitLab 아키텍처 개요

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

소프트웨어 배포 # GitLab에는 두 가지 소프트웨어 배포판이 있습니다. 오픈 소스 Community Edition (CE). 오픈 코어 Enterprise Edition (EE). EE 리포지터리는 보관 처리되었습니다. GitLab은 이제 단일 코드베이스 로 운영됩니다. GitLab은 다양한 구독 으로 제공됩니다. GitLab의 새 버전은 안정 브랜치에서 릴리스되며, main 브랜치는 최신 개발 용도로 사용됩니다. 자세한 내용은 GitLab 릴리스 프로세스 를 참고합니다. 두 배포판 모두 추가 컴포넌트가 필요합니다. 이러한 컴포넌트는 컴포넌트 세부 정보 섹션에서 설명하며, 모두 자체 리포지터리를 가지고 있습니다. 각 의존 컴포넌트의 새 버전은 대개 태그로 제공되지만, GitLab 코드베이스의 main 브랜치를 유지하면 해당 컴포넌트의 최신 안정 버전을 사용할 수 있습니다. 새 버전은 대체로 GitLab 릴리스와 비슷한 시기에 출시되며, 중요하다고 판단되는 비정기 보안 업데이트는 예외입니다. 컴포넌트 # 일반적인 GitLab 설치는 GNU/Linux 환경에서 이루어지지만, Kubernetes 플랫폼을 사용하는 배포도 늘고 있습니다. 알려진 가장 큰 GitLab 인스턴스는 GitLab.com이며, GitLab의 공식 GitLab Helm 차트 와 공식 Linux 패키지 로 배포됩니다. 일반적인 설치에서는 NGINX 또는 Apache를 웹 서버로 사용하여 요청을 GitLab Workhorse 를 거쳐 Puma 애플리케이션 서버로 전달합니다. GitLab은 Puma 애플리케이션 서버로 웹 페이지와 GitLab API 를 제공합니다. Sidekiq를 job 큐로 사용하며, Sidekiq는 다시 Redis를 job 정보, 메타데이터, 수신 job을 위한 비영구 데이터베이스 백엔드로 사용합니다. 기본적으로 Puma와 Workhorse 사이의 통신은 Unix 도메인 소켓을 통하지만, TCP로 요청을 전달하는 방식도 지원합니다. Workhorse는 gitlab/public 디렉터리에 접근하여 Puma 애플리케이션 서버를 거치지 않고 정적 페이지, 업로드(예: 아바타 이미지 또는 첨부 파일), 사전 컴파일된 에셋을 제공합니다. GitLab 애플리케이션은 영구 데이터베이스 정보(예: 사용자, 권한, 이슈 또는 기타 메타데이터)에 PostgreSQL을 사용합니다. GitLab은 bare Git 리포지터리를 설정 파일의 repositories: 섹션 에 정의된 위치에 저장합니다. 기본 브랜치와 훅 정보도 bare 리포지터리와 함께 보관합니다. HTTP/HTTPS로 리포지터리를 제공할 때 GitLab은 GitLab API를 사용하여 인가와 접근 권한을 확인하고 Git 객체를 제공합니다. 애드온 컴포넌트인 GitLab Shell은 SSH로 리포지터리를 제공합니다. SSH 키는 설정 파일의 GitLab Shell 섹션 에 정의된 위치에서 관리합니다. 해당 위치의 파일은 절대 수동으로 편집하면 안 됩니다. GitLab Shell은 Gitaly를 통해 bare 리포