GitLab 아키텍처 개요

소프트웨어 전달

GitLab에는 두 가지 소프트웨어 배포가 있습니다.

오픈 소스 Community Edition (CE).
오픈 코어 Enterprise Edition (EE). 참고: EE 리포지터리는 보관되었습니다. GitLab은 이제 단일 코드베이스에서 운영합니다.

GitLab은 다양한 구독으로 제공됩니다.

GitLab의 새로운 버전은 안정적인 브랜치에서 출시되며 main 브랜치는 초심자를 대상으로 한 최신 개발에 사용됩니다.

두 배포 모두 추가 컴포넌트가 필요합니다. 이러한 컴포넌트는 컴포넌트 세부 정보 섹션에서 설명되며 각각의 리포지터리를 갖고 있습니다. 각 종속 컴포넌트의 새 버전은 일반적으로 태그이지만 GitLab 코드베이스의 main 브랜치에 머무르면 해당 컴포넌트의 최신 안정화된 버전을 제공합니다. 새 버전은 일반적으로 GitLab 릴리스와 동시에 출시됩니다. 예외적으로 중요한 비공식적인 보안 업데이트가 있을 때에는 다릅니다.

컴포넌트

일반적으로 GitLab의 설치는 GNU/Linux에서 이루어지지만, 점점 더 많은 배포가 Kubernetes 플랫폼을 사용하고 있습니다. 알려진 최대 규모의 GitLab 인스턴스는 GitLab.com에서 공식 GitLab Helm 차트와 공식 Linux 패키지를 사용하여 배포됩니다.

일반적인 설치는 NGINX 또는 Apache를 웹 서버로 사용하여 GitLab Workhorse를 프록시로 사용하고 Puma 응용 프로그램 서버로 진입됩니다. GitLab은 웹 페이지와 GitLab API를 Puma 응용 프로그램 서버를 통해 제공합니다. Job Queue로 Sidekiq를 사용하며, 이는 작업 정보, 메타데이터 및 들어오는 작업에 대한 비영구 데이터베이스 백엔드인 Redis를 사용합니다.

기본적으로 Puma와 Workhorse 사이의 통신은 Unix 도메인 소켓을 통해 이루어지지만 TCP를 통한 요청 전달도 지원됩니다. Workhorse는 gitlab/public 디렉터리에 액세스하여 정적 페이지, 업로드(예: 아바타 이미지 또는 첨부 파일), 사전 컴파일된 에셋을 제공하고 Puma 응용 프로그램 서버를 우회합니다.

GitLab 애플리케이션은 PostgreSQL을 사용하여 영구 데이터베이스 정보(예: 사용자, 권한, 이슈 또는 다른 메타데이터)를 저장합니다. GitLab은 구성 파일의 repositories: 섹션에 정의된 위치에 베어 Git 리포지터리를 보관하며, 기본 브랜치 및 후크 정보를 베어 리포지터리에 유지합니다.

HTTP/HTTPS를 통해 리포지터리를 제공할 때, GitLab은 권한 및 액세스를 확인하고 Git 객체를 제공하기 위해 GitLab API를 사용합니다.

애드온 컴포넌트인 GitLab Shell은 SSH를 통해 리포지터리를 제공하며, GitLab Shell 섹션에 정의된 위치에서 SSH 키를 관리합니다. 해당 위치의 파일을 매뉴얼으로 편집해서는 안 됩니다. GitLab Shell은 작업을 제출하고 GitLab에서 처리하기 위해 Redis와 통신하며, Gitaly를 통해 베어 리포지터리에 액세스합니다. GitLab Shell은 인가 및 액세스를 결정하기 위해 GitLab API에 쿼리를 수행합니다.

Gitaly는 GitLab Shell 및 GitLab 웹 애플리케이션에서 Git 작업을 실행하고, Git에서 속성(예: 제목, 브랜치, 태그 또는 다른 메타데이터)을 가져오고 blobs(예: diffs, 커밋, 파일)을 얻기 위한 API를 제공합니다.

또한, GitLab.com의 프로덕션 아키텍처에 관심이 있을 수 있습니다.

기존 구성을 적응시키고 새 컴포넌트 도입하기

전통적인 Linux 머신 또는 Kubernetes와 같은 컨테이너화된 플랫폼에 설치될 때 응용 프로그램의 동작에는 근본적인 차이가 있습니다.

공식 설치 방법과 비교해 보면, 주목할 만한 몇 가지 차이점은 다음과 같습니다.

공식 Linux 패키지는 기본적으로 다른 서비스와 동일한 파일 시스템의 파일에 액세스할 수 있습니다. Kubernetes 플랫폼에서 실행 중인 응용 프로그램에 대해 공유 파일은 옵션이 아닙니다.
공식 Linux 패키지는 기본적으로 공유되는 구성 및 네트워크에 액세스하는 서비스를 갖고 있습니다. 하지만 Kubernetes에서 실행 중인 서비스는 완전히 격리되어 있거나 특정 포트를 통해서만 접근할 수 있는 경우가 있습니다.

다시 말하면, 서비스 간의 공유 상태는 새로운 기능을 설계하고 새 컴포넌트를 추가할 때 신중하게 고려해야 합니다. 동일한 파일에 액세스해야 하는 서비스는 적절한 API를 통해 정보를 교환할 수 있어야 합니다. 가능한 경우 파일을 사용하지 말아야 합니다.

API 우선 철학을 고려해 작성된 컴포넌트는 두 방법과 호환됩니다. 따라서 새로운 기능 및 서비스는 먼저 Kubernetes 호환성을 고려하여 작성되어야 합니다.

이를 보장하기 위한 가장 간단한 방법은 공식 GitLab Helm 차트에 기능 또는 서비스 지원을 추가하거나 배포 팀에 문의하는 것입니다.

자세한 내용은 새 서비스 컴포넌트 추가 프로세스를 참조하세요.

컴포넌트 설명서

✅ - 기본 설치
⚙ - 추가 구성 필요
⤓ - 매뉴얼 설치 필요
❌ - 지원되지 않거나 사용 설명서 없음
N/A - 해당 사항 없음

컴포넌트 상태는 각 컴포넌트의 구성 설명서에 연결되어 있습니다.

컴포넌트 디렉터리

컴포넌트	설명	Omnibus GitLab	GitLab 환경 도구킷 (GET)	GitLab 차트	minikube Minimal	GitLab.com	소스	GDK	CE/EE
인증서 관리	TLS 설정, Let’s Encrypt	✅	✅	✅	⚙	✅	⚙	⚙	CE & EE
Consul	데이터베이스 노드 검색, 장애 조치	⚙	✅	❌	❌	✅	❌	❌	EE Only
데이터베이스 마이그레이션	데이터베이스 마이그레이션	✅	✅	✅	✅	✅	⚙	✅	CE & EE
Elasticsearch	GitLab 내 개선된 검색기능	⤓	⚙	⤓	⤓	✅	⤓	⚙	EE Only
Gitaly	GitLab에서 발생한 모든 Git 호출을 처리하는 Git RPC 서비스	✅	✅	✅	✅	✅	⚙	✅	CE & EE
GitLab 내보내기	다양한 GitLab 지표 생성	✅	✅	✅	✅	✅	❌	❌	CE & EE
GitLab Geo	지리적으로 분산된 GitLab 사이트	⚙	⚙	❌	❌	✅	❌	⚙	EE Only
GitLab Pages	정적 웹사이트 호스트	⚙	⚙	❌	❌	✅	⚙	⚙	CE & EE
GitLab 에이전트	Kubernetes 클러스터를 클라우드 네이티브 방식으로 통합	⚙	⚙	⚙	❌	❌	⤓	⚙	EE Only
GitLab 자가 모니터링: Alertmanager	Prometheus에서 경고 중복 제거, 그룹화 및 경로 지정	⚙	⚙	✅	⚙	✅	❌	❌	CE & EE
GitLab 자가 모니터링: Grafana	메트릭 대시보드	✅	✅	⚙	⤓	✅	❌	⚙	CE & EE
GitLab 자가 모니터링: Jaeger	GitLab 인스턴스에서 생성된 추적 보기	❌	⚙	⚙	❌	❌	⤓	⚙	CE & EE
GitLab 자가 모니터링: Prometheus	시계열 데이터베이스, 메트릭 수집 및 쿼리 서비스	✅	✅	✅	⚙	✅	❌	⚙	CE & EE
GitLab 자가 모니터링: Sentry	GitLab 인스턴스에서 생성된 오류 추적	⤓	⤓	⤓	❌	✅	⤓	⤓	CE & EE
GitLab Shell	SSH 세션에서 `git` 처리	✅	✅	✅	✅	✅	⚙	✅	CE & EE
GitLab Workhorse	대용량 HTTP 요청 처리를 위한 스마트 리버스 프록시	✅	✅	✅	✅	✅	⚙	✅	CE & EE
수신 이메일 (SMTP)	이슈를 업데이트하기 위해 메시지 수신	⤓	⤓	⚙	⤓	✅	⤓	⤓	CE & EE
Jaeger 통합	배포된 앱을 위한 분산 추적	⤓	⤓	⤓	⤓	⤓	⤓	⚙	EE Only
LDAP 인증	중앙 집중식 LDAP 디렉터리에 대한 사용자 인증	⤓	⤓	⤓	⤓	❌	⤓	⚙	CE & EE
Mattermost	오픈소스 Slack 대체	⚙	⚙	⤓	⤓	⤓	❌	⚙	CE & EE
MinIO	오브젝트 스토리지 서비스	⤓	⤓	✅	✅	✅	❌	⚙	CE & EE
NGINX	요청을 적절한 컴포넌트로 라우팅하고 SSL을 종료	✅	✅	✅	⚙	✅	⤓	⚙	CE & EE
Node Exporter	시스템 메트릭이 있는 Prometheus 엔드포인트	✅	✅	N/A	N/A	✅	❌	❌	CE & EE
발신 이메일 (SMTP)	사용자에게 이메일 메시지 전송	⤓	⤓	⚙	⤓	✅	⤓	⤓	CE & EE
Patroni	PostgreSQL HA 클러스터 리더 선정 및 복제 관리	⚙	✅	❌	❌	✅	❌	❌	EE Only
PgBouncer Exporter	PgBouncer 메트릭이 있는 Prometheus 엔드포인트	⚙	✅	❌	❌	✅	❌	❌	CE & EE
PgBouncer	데이터베이스 연결 풀링, 장애 조치	⚙	✅	❌	❌	✅	❌	❌	EE Only
PostgreSQL Exporter	PostgreSQL 메트릭이 있는 Prometheus 엔드포인트	✅	✅	✅	✅	✅	❌	❌	CE & EE
PostgreSQL	데이터베이스	✅	✅	✅	✅	✅	⤓	✅	CE & EE
Praefect	Git 클라이언트와 Gitaly 리포지터리 노드 간의 투명한 프록시	✅	✅	⚙	❌	✅	⚙	✅	CE & EE
Puma (GitLab Rails)	웹 인터페이스 및 API 요청 처리	✅	✅	✅	✅	✅	⚙	✅	CE & EE
Redis Exporter	Redis 메트릭이 있는 Prometheus 엔드포인트	✅	✅	✅	✅	✅	❌	❌	CE & EE
Redis	캐싱 서비스	✅	✅	✅	✅	✅	⤓	✅	CE & EE
레지스트리	컨테이너 레지스트리, 이미지 푸시 및 풀링 허용	⚙	⚙	✅	✅	✅	⤓	⚙	CE & EE
러너(runner)	GitLab CI/CD 작업 실행	⤓	⤓	✅	⚙	✅	⚙	⚙	CE & EE
Sentry 통합	배포된 앱을 위한 오류 추적	⤓	⤓	⤓	⤓	⤓	⤓	⤓	CE & EE
Sidekiq	백그라운드 작업 프로세서	✅	✅	✅	✅	✅	✅	✅	CE & EE
토큰 폐기 API	유출된 비밀번호 수신 및 폐기	❌	❌	❌	❌	✅	❌	❌	EE Only

컴포넌트 세부 정보

이 문서는 GitLab 내부 및 작동 방식에 대해 자세히 이해하고자 하는 시스템 관리자 및 GitLab 지원 엔지니어들이 사용하도록 설계되었습니다.

GitLab을 배포하면 아래 프로세스의 융합으로 간주해야 합니다. 문제 해결 또는 디버깅 시 참조하는 컴포넌트를 가능한 한 구체적으로 지정하십시오. 이는 명확성을 높이고 혼란을 줄일 것입니다.

계층

프로세스 관점에서 GitLab은 두 개의 계층으로 간주될 수 있습니다.

모니터링: 이 계층에서 나오는 모든 것은 GitLab 애플리케이션을 제공하는 데 필요하지 않지만, 시스템 관리자들에게 인프라에 대한 더 깊은 통찰력을 제공하고 전반적인 서비스를 파악할 수 있습니다.
코어(Core): 플랫폼인 GitLab을 제공하는 데 중요한 모든 프로세스입니다. 이러한 프로세스 중지 시 GitLab 장애가 발생합니다. 코어 계층에서 더 나누면:
- 프로세서: 이러한 프로세스는 실제 작업을 수행하고 서비스를 제공합니다.
- 데이터: 이러한 서비스는 GitLab 서비스를 위해 구조화된 데이터를 저장하고 노출합니다.

알림 관리자

프로젝트 페이지
구성:
- Omnibus
- Charts
계층: 모니터링
프로세스: alertmanager
GitLab.com: GitLab.com 모니터링

알림 관리자는 Prometheus에서 제공하는 도구로, “Prometheus 서버와 같은 클라이언트 애플리케이션이 보내는 경보를 처리합니다. 중복 제거, 그룹화 및 이메일, PagerDuty 또는 Opsgenie 등 올바른 수신 통합으로 경로를 지정합니다. 또한 경보 음소거 및 억제를 처리합니다.” issue #45740에서 자세한 내용을 확인할 수 있습니다.

인증서 관리

프로젝트 페이지:
- Omnibus
- Charts
구성:
계층: 코어 서비스(프로세서)
GitLab.com: 시크릿 관리

Consul

프로젝트 페이지
구성:
- Omnibus
- Charts
계층: 코어 서비스(데이터)
GitLab.com: Consul

Consul은 서비스 발견 및 구성을 위한 도구로, 분산되어 있으며 고가용성이 높고 매우 확장 가능합니다.

데이터베이스 마이그레이션

구성:
계층: 코어 서비스(데이터)

Elasticsearch

프로젝트 페이지
구성:
계층: 코어 서비스(데이터)
GitLab.com: GitLab.com에서 고급 검색 활성화하기 (종료됨) 에픽

Elasticsearch는 클라우드용으로 만들어진 분산 RESTful 검색 엔진입니다.

Gitaly

프로젝트 페이지
구성:
계층: 코어 서비스(데이터)
프로세스: gitaly

Gitaly는 GitLab에서 NFS를 분산 배포(예: GitLab.com 또는 고가용성 배포)에 대한 Git 리포지터리에 대한 필요성을 제거하기 위해 설계된 서비스입니다. 11.3.0부터 이 서비스는 GitLab의 모든 Git 수준 액세스를 처리합니다. 이 프로젝트에 대해 더 읽어보려면 프로젝트의 README에서 확인할 수 있습니다.

Praefect

프로젝트 페이지
구성:
- Omnibus
- 소스
계층: 코어 서비스(데이터)
프로세스: praefect

Praefect는 각 Git 클라이언트와 Gitaly 간의 투명한 프록시로, 리포지터리 업데이트의 복제를 조정하는 서비스입니다.

GitLab Geo

구성:
계층: 코어 서비스(프로세서)

Geo는 Premium 기능으로, 분산된 팀의 개발 속도를 높이기 위해 주요 GitLab 인스턴스의 하나 이상의 읽기 전용 미러를 제공합니다. 이 미러(Geo 보조 사이트)는 대형 리포지터리 및 프로젝트를 복제하거나 검색하는 시간을 줄이거나 재해 복구 솔루션의 일부가 될 수 있습니다.

GitLab Exporter

프로젝트 페이지
구성:
- Omnibus
- Charts
계층: 모니터링
프로세스: gitlab-exporter
GitLab.com: GitLab.com 모니터링

GitLab Exporter는 GitLab 애플리케이션 내부에 대한 메트릭을 Prometheus에 내보내기 위해 내부에서 설계된 프로세스입니다. 프로젝트의 README에서 자세한 내용을 확인할 수 있습니다.

GitLab 에이전트

프로젝트 페이지
구성:
- Omnibus
- Charts

GitLab 에이전트는 클러스터 내에서 활성인 컴포넌트로, GitLab 및 Kubernetes 통합 작업을 안전하고 클라우드 네이티브 방식으로 해결하는 데 사용됩니다.

Kubernetes 클러스터에 배포를 동기화하는 데 사용할 수 있습니다.

GitLab Pages

구성:
레이어: 코어 서비스 (프로세서)
GitLab.com: GitLab Pages

GitLab Pages는 GitLab의 리포지터리에서 정적 웹사이트를 직접 게시할 수 있는 기능입니다.

개인 또는 비즈니스 웹사이트에 사용할 수 있으며, 포트폴리오, 문서, 선언문 및 비즈니스 프레젠테이션 등 다양한 방식으로 활용할 수 있습니다. 콘텐츠에는 어떠한 라이선스도 적용할 수 있습니다.

GitLab Runner

프로젝트 페이지
구성:
레이어: 코어 서비스 (프로세서)
GitLab.com: Runners

GitLab Runner은 작업을 실행하고 결과를 GitLab에 보냅니다.

GitLab CI/CD는 테스트를 조정하는 GitLab에 포함된 오픈 소스 지속적 통합 서비스입니다. 이 프로젝트의 이전 이름은 GitLab CI Multi Runner였지만 이제는 GitLab Runner (CI 없이)를 사용해주세요.

GitLab Shell

프로젝트 페이지
문서
구성:
레이어: 코어 서비스 (프로세서)

GitLab Shell은 GitLab에서 SSH 기반 git 세션을 처리하고 인가된 키 디렉터리을 수정하기 위한 프로그램입니다. GitLab Shell은 Unix 셸이나 Bash 또는 Zsh를 대체하는 것은 아닙니다.

GitLab Workhorse

프로젝트 페이지
구성:
레이어: 코어 서비스 (프로세서)
프로세스: gitlab-workhorse

GitLab Workhorse는 Puma의 압력을 줄이기 위해 GitLab에서 설계된 프로그램입니다. 전체적으로 GitLab의 속도를 높이기 위해 스마트 리버스 프록시로 설계되었습니다.

Grafana

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 모니터링
GitLab.com: GitLab triage Grafana dashboard

Grafana는 Graphite, Elasticsearch, OpenTSDB, Prometheus 및 InfluxDB를 위한 오픈 소스이자 특징이 풍부한 메트릭 대시보드 및 그래프 편집기입니다.

Jaeger

프로젝트 페이지
구성:
레이어: 모니터링
GitLab.com: GitLab 인스턴스의 추적 활성화를 위한 구성 이슈

Dapper와 OpenZipkin에서 영감을 받은 Jaeger는 분산 추적 시스템입니다. 이는 마이크로서비스 기반 분산 시스템의 모니터링에 사용할 수 있습니다.

Logrotate

프로젝트 페이지
구성:
- Omnibus
레이어: 코어 서비스
프로세스: logrotate

GitLab은 모든 로그를 기록하기 위해 많은 서비스로 이뤄져 있습니다. 책임감 있게 로그를 기록하기 위해 우리만의 Logrotate를 번들로 제공합니다. 이는 일반 오픈 소스 오퍼링의 패키지 버전일 뿐입니다.

Mattermost

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 코어 서비스 (프로세서)
GitLab.com: Mattermost

Mattermost는 https://mattermost.com에서 오픈 소스로 제공되는, 개인 클라우드용 Slack 대체 솔루션입니다.

MinIO

프로젝트 페이지
구성:
레이어: 코어 서비스 (데이터)
GitLab.com: 저장 아키텍처

MinIO는 GNU AGPL v3.0으로 출시된 오브젝트 스토리지 서버입니다. Amazon S3 클라우드 리포지터리 서비스와 호환됩니다. 사진, 동영상, 로그 파일, 백업, 컨테이너/VM 이미지 등의 비구조적 데이터를 저장하는 데 적합합니다. 객체의 크기는 몇 KB부터 최대 5TB까지 가능합니다.

NGINX

프로젝트 페이지:
- Omnibus
- 차트
구성:
레이어: 코어 서비스 (프로세서)
프로세스: nginx

NGINX는 모든 HTTP 요청에 대한 인그레스 포트를 보유하고, 이를 GitLab의 적절한 하위 시스템으로 라우팅합니다. 우리는 인기 있는 오픈 소스 웹 서버의 수정되지 않은 버전을 번들로 제공하고 있습니다.

노드 익스포터

프로젝트 페이지
구성:
- 옴니버스
- 차트
계층: 모니터링
프로세스: node-exporter
GitLab.com: GitLab.com의 모니터링

노드 익스포터는 프로메테우스 프로젝트의 일반 오픈 소스 제공물의 패키지화된 버전으로, 기계의 메트릭(예: CPU/Disk/부하)을 제공합니다.

패트로니

프로젝트 페이지
구성:
- 옴니버스
계층: 핵심 서비스 (데이터)
프로세스: patroni
GitLab.com: 데이터베이스 아키텍처

PgBouncer

프로젝트 페이지
구성:
- 옴니버스
- 차트
계층: 핵심 서비스 (데이터)
GitLab.com: 데이터베이스 아키텍처

PostgreSQL용 가벼운 연결 풀러입니다.

PgBouncer 익스포터

프로젝트 페이지
구성:
- 옴니버스
- Charts
계층: 모니터링
GitLab.com: GitLab.com의 모니터링

PgBouncer용 프로메테우스 익스포터로, 9127/metrics에서 메트릭을 노출합니다.

PostgreSQL

프로젝트 페이지
구성:
계층: 핵심 서비스 (데이터)
프로세스: postgresql
GitLab.com: 포스트그레SQL

인기 있는 데이터베이스를 제공하여, 응용 프로그램 메타데이터와 사용자 정보를 위한 리포지터리를 제공합니다.

PostgreSQL 익스포터

프로젝트 페이지
구성:
- 옴니버스
- 차트
계층: 모니터링
프로세스: postgres-exporter
GitLab.com: GitLab.com의 모니터링

postgres_exporter는 PostgreSQL에 대한 데이터를 프로메테우스에 제공하여, Grafana 대시보드에서 이러한 메트릭을 그래프로 나타낼 수 있도록 하는 커뮤니티 제공 프로메테우스 익스포터입니다.

프로메테우스

프로젝트 페이지
구성:
- 옴니버스
- 차트
계층: 모니터링
프로세스: prometheus
GitLab.com: 프로메테우스

프로메테우스는 GitLab 관리자가 GitLab 서비스 제공에 사용된 개별 프로세스에 대한 메트릭을 노출하는 데 도움이 되는 시계열 도구입니다.

레디스

프로젝트 페이지
구성:
계층: 핵심 서비스 (데이터)
프로세스: redis

레디스는 다음을 저장하는 곳을 제공하기 위해 패키지화되었습니다:

세션 데이터
임시 캐시 정보
백그라운드 작업 큐

GitLab이 레디스를 사용하는 방법에 대한 자세한 정보는 Redis 가이드라인을 참조하십시오.

레디스 익스포터

프로젝트 페이지
구성:
- 옴니버스
- 차트
계층: 모니터링
프로세스: redis-exporter
GitLab.com: GitLab.com의 모니터링

레디스 익스포터는 레디스 프로세스에 대한 구체적인 메트릭을 프로메테우스에 제공하여, 이러한 메트릭을 Grafana에서 그래프로 나타낼 수 있도록 설계되었습니다.

레지스트리

프로젝트 페이지
구성:
계층: 핵심 서비스 (프로세서)
GitLab.com: GitLab 컨테이너 레지스트리

레지스트리는 사용자가 자체 Docker 이미지를 저장하는 데 사용합니다. 번들로 제공되는 레지스트리는 NGINX를 로드 밸런서와 인증 관리자로 사용하는 GitLab을 사용합니다. 클라이언트가 레지스트리에서 이미지를 가져오거나 푸시하도록 요청하면, GitLab 인스턴스에서 인증 토큰을 얻는 방법에 대한 세부 정보가 포함된 401 응답과 함께 반환됩니다. 그런 다음 클라이언트는 GitLab에서 풀이나 푸시 인증 토큰을 요청하고, 레지스트리에서 원래 요청을 재시도합니다. 자세한 내용은 토큰 인증을 참조하십시오.

외부 레지스트리도 GitLab을 인증 엔드포인트로 사용하도록 구성할 수 있습니다.

센트리

프로젝트 페이지
구성:
계층: 모니터링
GitLab.com: 센트리 검색

센트리는 기본적으로 실시간으로 충돌을 모니터링하고 수정하는 데 도움이 되는 서비스입니다. 서버는 Python으로 되어 있지만, 어떤 응용 프로그램에서든 어떤 언어로 이벤트를 보내기 위한 완전한 API가 포함되어 있습니다.

배포된 애플리케이션을 모니터링하는 경우, 센트리 통합 문서를 참조하십시오.

Sidekiq

프로젝트 페이지
구성:
레이어: 핵심 서비스 (프로세서)
프로세스: sidekiq
GitLab.com: Sidekiq

Sidekiq는 루비 백그라운드 작업 프로세서로, Redis 대기열에서 작업을 가져와 처리합니다. 백그라운드 작업을 통해 GitLab은 작업을 백그라운드로 이동함으로써 더 빠른 요청/응답 주기를 제공합니다.

Puma

GitLab 13.0부터 Puma가 기본 웹 서버로 사용됩니다.

프로젝트 페이지
구성:
레이어: 핵심 서비스 (프로세서)
프로세스: puma
GitLab.com: Puma

Puma는 GitLab의 사용자를 대상으로 하는 핵심 Rails 애플리케이션을 실행하는 데 사용되는 루비 애플리케이션 서버입니다. GitLab 버전에 따라 프로세스 출력에 bundle 또는 config.ru로 표시됩니다.

LDAP 인증

구성:
레이어: 핵심 서비스 (프로세서)
GitLab.com: 제품 티어

발신 이메일

구성:
레이어: 핵심 서비스 (프로세서)
GitLab.com: 메일 구성

수신 이메일

구성:
레이어: 핵심 서비스 (프로세서)
GitLab.com: 메일 구성

요청 유형에 따른 GitLab

GitLab은 사용자가 서비스에 액세스할 수 있는 두 가지 “인터페이스”를 제공합니다:

웹 HTTP 요청 (UI/API 보기)
Git HTTP/SSH 요청 (Git 데이터 푸시/풀링)

일부 프로세스가 두 가지 유형에 모두 사용되고 다른 프로세스가 특정 요청 유형에만 사용되기 때문에 이 구별을 이해하는 것이 중요합니다.

GitLab 웹 HTTP 요청 주기

HTTP 엔드포인트(예: /users/sign_in)에 요청을 보낼 때, 요청은 GitLab 서비스를 통해 다음 경로를 따라갑니다:

NGINX - 최초의 역방향 프록시 역할을 합니다.
GitLab Workhorse - 이 요청이 Puma에게 라우팅되야 하는지 기타 곳으로 라우팅되어야 하는지를 결정합니다.
Puma - 이 웹 요청이므로 애플리케이션에 액세스해야 하며 Puma에 라우팅됩니다.
PostgreSQL/Gitaly/Redis - 요청 유형에 따라 데이터를 저장하거나 검색하기 위해 이러한 서비스에 액세스할 수 있습니다.

GitLab Git 요청 주기

HTTP 대 SSH Git 요청의 다른 경로에 대해 설명합니다. 웹 요청 주기와 일부 중복이 있지만 차이점도 있습니다.

웹 요청 (80/443)

HTTP를 통한 Git 작업은 상태가 없는 “스마트” 프로토콜을 사용하지만, 이러한 작업을 처리하는 책임은 여러 GitLab 컴포넌트로 분산됩니다.

여기 git fetch에 대한 순서도가 있습니다. 모든 요청은 NGINX 및 기타 HTTP 로드 밸런서를 통과하지만 이러한 요청은 아무런 변형이 없습니다. 모든 경로는 /namespace/project.git URL을 기준으로 표시됩니다.

sequenceDiagram participant Git on client participant NGINX participant Workhorse participant Rails participant Gitaly participant Git on server Note left of Git on client: git fetch<br/>info-refs Git on client->>+Workhorse: GET /info/refs?service=git-upload-pack Workhorse->>+Rails: GET /info/refs?service=git-upload-pack Note right of Rails: Auth check Rails-->>-Workhorse: Gitlab::Workhorse.git_http_ok Workhorse->>+Gitaly: SmartHTTPService.InfoRefsUploadPack request Gitaly->>+Git on server: git upload-pack --stateless-rpc --advertise-refs Git on server-->>-Gitaly: git upload-pack response Gitaly-->>-Workhorse: SmartHTTPService.InfoRefsUploadPack response Workhorse-->>-Git on client: 200 OK Note left of Git on client: git fetch<br/>fetch-pack Git on client->>+Workhorse: POST /git-upload-pack Workhorse->>+Rails: POST /git-upload-pack Note right of Rails: Auth check Rails-->>-Workhorse: Gitlab::Workhorse.git_http_ok Workhorse->>+Gitaly: SmartHTTPService.PostUploadPack request Gitaly->>+Git on server: git upload-pack --stateless-rpc Git on server-->>-Gitaly: git upload-pack response Gitaly-->>-Workhorse: SmartHTTPService.PostUploadPack response Workhorse-->>-Git on client: 200 OK

git push에 대한 순서도도 유사하지만 git-receive-pack 대신에 git-upload-pack이 사용됩니다.

SSH 요청 (22)

SSH를 통한 Git 작업은 상태 지향 프로토콜을 사용할 수 있지만 이를 처리하는 책임은 여러 GitLab 컴포넌트로 분산됩니다.

모든 SSH 연결은 GitLab 컴포넌트 간에 직접 SSH로 이루어지지 않습니다. SSH 연결은 모두 클라이언트 머신에서 Git과 SSH 서버 간에 만들어지며 SSH 서버에서 연결이 종료됩니다. SSH 서버에게는 연결이 git 사용자로 인증됩니다. GitLab 사용자는 클라이언트에서 제시된 SSH 키에 의해 구별됩니다.

여기 git fetch에 대한 순서도가 있습니다. 이 과정은 빠른 SSH 키 조회가 활성화된 상황을 가정합니다. AuthorizedKeysCommand는 GitLab Shell에서 제공되는 실행 파일입니다.

sequenceDiagram participant Git on client participant SSH server participant AuthorizedKeysCommand participant GitLab Shell participant Rails participant Gitaly participant Git on server Note left of Git on client: git fetch Git on client->>+SSH server: ssh git fetch-pack request SSH server->>+AuthorizedKeysCommand: gitlab-shell-authorized-keys-check git AAAA... AuthorizedKeysCommand->>+Rails: GET /internal/api/authorized_keys?key=AAAA... Note right of Rails: Lookup key ID Rails-->>-AuthorizedKeysCommand: 200 OK, command="gitlab-shell upload-pack key_id=1" AuthorizedKeysCommand-->>-SSH server: command="gitlab-shell upload-pack key_id=1" SSH server->>+GitLab Shell: gitlab-shell upload-pack key_id=1 GitLab Shell->>+Rails: GET /internal/api/allowed?action=upload_pack&key_id=1 Note right of Rails: Auth check Rails-->>-GitLab Shell: 200 OK, { gitaly: ... } GitLab Shell->>+Gitaly: SSHService.SSHUploadPack request Gitaly->>+Git on server: git upload-pack request Note over Git on client,Git on server: 이동 가능한 통신이 Git 클라이언트와 서버 사이에서 이뤄집니다 Git on server-->>-Gitaly: git upload-pack response Gitaly -->>-GitLab Shell: SSHService.SSHUploadPack response GitLab Shell-->>-SSH server: gitlab-shell upload-pack response SSH server-->>-Git on client: ssh git fetch-pack response

git push 작업은 매우 유사하지만 git upload-pack 대신 git receive-pack이 사용됩니다.

빠른 SSH 키 조회가 비활성화된 경우, SSH 서버는 주어진 SSH 세션에 대해 어떤 명령을 실행해야 하는지를 결정하기 위해 ~git/.ssh/authorized_keys 파일에서 읽습니다. 이 파일은 사용자에 의해 변경된 SSH 키가 발견되면 Rails의 AuthorizedKeysWorker에 의해 업데이트됩니다.

SSH 인증서를 사용하여 키 대신에 사용할 수도 있습니다. 이 경우, AuthorizedKeysCommand는 AuthorizedPrincipalsCommand로 대체됩니다. 이는 내부 Rails API 대신에 SSH 인증서에 의해 사용자 이름을 추출하며, 나중의 /api/internal/allowed 호출에서 key_id 대신에 사용됩니다.

GitLab Shell에는 Gitaly와 관련이 없는 몇 가지 작업도 있습니다. 이러한 작업들은 Gitaly과 같은 곳을 경유하는 대신에 Rails에서 내부 API 호출의 일부로 동작하며, GitLab Shell은 응답을 사용자에게 직접 스트리밍합니다.

시스템 레이아웃

사진에서 ~git를 언급할 때, 일반적으로 /home/git인 Git 사용자의 홈 디렉터리를 의미합니다.

GitLab은 주로 git 사용자로 /home/git 사용자 홈 디렉터리에 설치됩니다. 홈 디렉터리 내에는 GitLab 서버 소프트웨어 및 리포지터리가 위치하며(단, 리포지터리 위치는 구성 가능), 내부 동작의 세부 정보는 Ruby on Rails 애플리케이션의 작동 방식을 연구함으로써 알 수 있습니다.

맨 뒤에 있는 참고: 다음은 git 사용자 홈 디렉터리의 디렉터리 구조입니다.

프로세스

ps aux | grep '^git'

GitLab에는 작동을 위한 여러 컴포넌트가 있습니다. 지속적인 데이터베이스(PostgreSQL)와 Redis 데이터베이스가 필요하며, Apache httpd 또는 NGINX를 사용하여 Puma를 proxypass하기 위해 필요합니다. 모든 이러한 컴포넌트는 GitLab과는 다른 시스템 사용자로 실행되어야 합니다(GitLab의 경우, git 대신 postgres, redis, www-data 등).

git 사용자로 시작하여 Sidekiq와 Puma(기본적으로 8080번 포트에서 실행되는 간단한 Ruby HTTP 서버)를 시작합니다. GitLab 사용자 아래에는 보통 4개의 프로세스가 있습니다. puma master (1개의 프로세스), puma cluster worker (2개의 프로세스), sidekiq (1개의 프로세스).

리포지터리 접근

리포지터리는 HTTP 또는 SSH를 통해 접근됩니다. HTTP 클론/푸시/풀은 GitLab API를 사용하며, SSH 클론은 이전에 설명한 GitLab Shell에 의해 처리됩니다.

문제 해결

추가 정보는 README를 참조하십시오.

서비스의 초기화 스크립트

GitLab 초기화 스크립트는 Puma 및 Sidekiq를 시작하고 중지합니다.

/etc/init.d/gitlab
사용법: service gitlab {start|stop|restart|reload|status}

Redis (키-값 리포지터리/비영구 데이터베이스):

/etc/init.d/redis
사용법: /etc/init.d/redis {start|stop|status|restart|condrestart|try-restart}

SSH 데몬:

/etc/init.d/sshd
사용법: /etc/init.d/sshd {start|stop|restart|reload|force-reload|condrestart|try-restart|status}

웹 서버 (다음 중 하나):

/etc/init.d/httpd
사용법: httpd {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}

$ /etc/init.d/nginx
사용법: nginx {start|stop|restart|reload|force-reload|status|configtest}

지속적인 데이터베이스:

$ /etc/init.d/postgresql
사용법: /etc/init.d/postgresql {start|stop|restart|reload|force-reload|status} [version ..]

서비스의 로그 위치

GitLab (Puma 및 Sidekiq 로그 포함):

/home/git/gitlab/log/에는 application.log, production.log, sidekiq.log, puma.stdout.log, git_json.log, puma.stderr.log 등이 일반적으로 포함됩니다.

GitLab Shell:

/home/git/gitlab-shell/gitlab-shell.log

SSH:

Ubuntu의 경우 /var/log/auth.log 인증 로그, RHEL의 경우 /var/log/secure 인증 로그.

NGINX:

/var/log/nginx/에는 오류 및 액세스 로그가 포함됩니다.

Apache httpd:

Apache 로그 설명.
Ubuntu의 경우 /var/log/apache2/에 오류 및 출력 로그가 포함됩니다.
RHEL의 경우 /var/log/httpd/에 오류 및 출력 로그가 포함됩니다.

Redis:

/var/log/redis/redis.log에 또한 로그가 회전됩니다.

PostgreSQL:

/var/log/postgresql/*

GitLab 특정 구성 파일

GitLab의 구성 파일은 /home/git/gitlab/config/*에 있습니다. 자주 언급되는 구성 파일로는:

gitlab.yml: GitLab Rails 구성
puma.rb: Puma 웹 서버 설정
database.yml: 데이터베이스 연결 설정

GitLab Shell에는 /home/git/gitlab-shell/config.yml에 구성 파일이 있습니다.

GitLab Rails에 새로운 설정 추가

gitlab.yml에 포함되어야 하는 설정은 다음과 관련이 있습니다:

여러 서비스 간에 애플리케이션이 어떻게 연결되는가. 예를 들어, Gitaly 주소, Redis 주소, Postgres 주소, Consul 주소 등.
분산 추적 구성 및 일부 관측 가능한 구성. 예를 들어, 히스토그램 버킷 경계.
Postgres 연결이 설정되기 전에 초기화 중에 구성해야 하는 것들.

기타 많은 설정은 일반적으로 ApplicationSetting에 더 잘 배치됩니다. 설정을 UI에서 관리하는 것은 일반적으로 구성 파일을 관리하는 것보다 사용자 경험이 더 좋습니다. 개발 비용에 대해 고려할 때, gitlab.yml을 수정하는 것은 종종 더 빠른 반복인 것처럼 보이지만 아래의 모든 배포 방법을 고려할 때는 효율적이지 않을 수 있습니다.

gitlab.yml에 설정을 추가할 때:

Omnibus에도 추가되는지 확인하십시오.
필요한 경우 Charts에도 추가되는지 확인하십시오.
필요한 경우 GDK에도 추가되는지 확인하십시오.

유지 관리 작업

GitLab은 Rake 작업을 제공하여 응용 프로그램 내에서의 버전 정보를 확인하고 구성이 올바르게 설정되었는지 빠르게 확인할 수 있습니다. 유지 보수 Rake 작업을 참조하십시오. 요약하면 다음을 실행하십시오:

sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
bundle exec rake gitlab:check RAILS_ENV=production

일반적으로 sudo -i -u git 또는 sudo su - git을 사용하여 git 사용자로 로그인하는 것이 좋습니다. GitLab에서 제공하는 sudo 명령은 Ubuntu에서는 작동하지만 항상 RHEL에서는 작동하지는 않을 수 있습니다.

GitLab.com

GitLab.com 아키텍처는 참고용으로 자세히 설명되어 있지만, 이 아키텍처는 수백만 명의 사용자가 있는 경우에만 유용합니다.

AI 아키텍처

AI 기능을 활성화하는 SaaS 모델 게이트웨이를 사용하여 AI 기반 기능을 활성화할 수 있습니다.