GitLab 아키텍처 개요

소프트웨어 제공

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

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

새로운 GitLab 버전은 안정적인 브랜치에서 출시되며, main 브랜치는 최신 안정 버전을 위한 bleeding-edge 개발에 사용됩니다.

두 배포 모두 추가 구성 요소가 필요합니다. 이러한 구성 요소에 대해 설명된 것은 구성 요소 세부 정보 섹션에 나와 있으며, 각각 별도의 저장소를 가지고 있습니다. 각 종속 구성 요소의 새 버전은 일반적으로 태그로 표시되지만, GitLab 코드베이스의 main 브랜치에 유지하면 해당 구성 요소의 최신 안정 버전을 얻을 수 있습니다. 일반적으로 GitLab 릴리스와 동시에 새 버전이 출시되지만 비공식 보안 업데이트는 중요하다고 판단될 경우를 제외하고는 발생하지 않습니다.

구성 요소

일반적으로 GitLab의 설치는 GNU/Linux 환경에 이루어지지만, Kubernetes 플랫폼을 사용하는 배포가 점점 더 늘어나고 있습니다. 가장 큰 알려진 GitLab 인스턴스는 GitLab.com에 있으며, 이는 공식 GitLab Helm 차트와 공식 Linux 패키지를 사용하여 배포되었습니다.

일반적인 설치에서는 NGINX 또는 Apache를 웹 서버로 사용하여 GitLab Workhorse를 프록시로 사용하고 Puma 응용 프로그램 서버로 연결합니다. GitLab은 웹 페이지 및 GitLab API를 Puma 응용 프로그램 서버를 사용하여 제공합니다. 이는 Sidekiq를 작업 대기열로 사용하며, 이는 다시 작업 정보, 메타데이터 및 수신 작업에 대한 비영구적 데이터베이스 백엔드로 Redis를 사용합니다.

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

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

HTTP/HTTPS를 통해 저장소를 제공할 때 GitLab은 권한 및 액세스를 해결하고 Git 객체를 제공하기 위해 GitLab API를 사용합니다.

추가 기능인 GitLab Shell은 SSH를 통해 저장소를 제공합니다. 이는 구성 파일의 GitLab Shell 섹션에서 정의된 위치에서 SSH 키를 관리합니다. 해당 위치의 파일은 절대로 수동으로 편집해서는 안 됩니다. GitLab Shell은 Git 객체를 제공하기 위해 Gitaly를 통해 베어 저장소에 액세스하고 GitLab에 작업을 제출하기 위해 Sidekiq와 통신합니다. GitLab Shell은 권한과 액세스를 결정하기 위해 GitLab API에 쿼리합니다.

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

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

기존 구성 요소 적응 및 새 구성 요소 도입

Linux 기반 기존 머신에 설치된 응용 프로그램과 Kubernetes와 같은 컨테이너화된 플랫폼에 설치된 응용 프로그램 간에 응용 프로그램이 작동하는 기본적인 차이점이 있습니다.

공식 설치 방법에 비교하여 주목할만한 차이 중 일부는 다음과 같습니다:

공식 Linux 패키지는 동일한 파일 시스템의 파일에 액세스할 수 있습니다. Kubernetes 플랫폼에서는 공유 파일을 사용할 수 없습니다.
공식 Linux 패키지는 기본적으로 동일한 구성 및 네트워크에 액세스하는 서비스를 가지고 있습니다. 그러나 Kubernetes에서는 서비스가 완전히 격리되어 있거나 특정 포트를 통해서만 액세스할 수 있는 경우가 있습니다.

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

API-first 철학에 따라 작성된 구성 요소는 두 방법 모두와 호환될 수 있으므로, 모든 새로운 기능 및 서비스는 먼저 Kubernetes 호환성을 고려하여 작성되어야 합니다.

이를 보증하는 가장 간단한 방법은 공식 GitLab Helm 차트에 귀하의 기능이나 서비스를 지원하도록 추가하거나 Distribution 팀에 문의하는 것입니다.

자세한 내용은 새 서비스 구성 요소 추가 프로세스를 참조하세요.

단순화된 구성 요소 개요

GitLab 아키텍처를 이해하는 데 사용할 수 있는 단순화된 아키텍처 다이어그램입니다.

완전한 아키텍처 다이어그램은 아래의 구성도에서 확인할 수 있습니다.

구성도

%%{init: {"flowchart": { "useMaxWidth": false } }}%% graph LR %% 적절한 하위 그래프에 앵커 요소 배치 %% 대상*이되는 곳에 연결합니다. subgraph Clients Browser((Browser)) Git((Git)) end %% 외부 구성 요소 / 응용 프로그램 Geo{{GitLab Geo}} -- TCP 80, 443 --> HTTP Geo -- TCP 22 --> SSH Geo -- TCP 5432 --> PostgreSQL Runner{{GitLab Runner}} -- TCP 443 --> HTTP K8sAgent{{GitLab Agent}} -- TCP 443 --> HTTP %% GitLab 응용 프로그램 스위트 subgraph GitLab subgraph Ingress HTTP[[HTTP/HTTPS]] SSH[[SSH]] NGINX[NGINX] GitLabShell[GitLab Shell] %% 수신 / 내부 Browser -- TCP 80,443 --> HTTP Git -- TCP 80,443 --> HTTP Git -- TCP 22 --> SSH HTTP -- TCP 80, 443 --> NGINX SSH -- TCP 22 --> GitLabShell end subgraph GitLab Services %% NGINX로부터 수신 NGINX --> GitLabWorkhorse NGINX -- TCP 8090 --> GitLabPages NGINX -- TCP 8150 --> GitLabKas NGINX --> Registry %% GitLabShell로부터 수신 GitLabShell --> GitLabWorkhorse %% 서비스 Puma["Puma (GitLab Rails)"] Puma <--> Registry GitLabWorkhorse[GitLab Workhorse] <--> Puma GitLabKas[GitLab Agent Server] --> GitLabWorkhorse GitLabPages[GitLab Pages] --> GitLabWorkhorse Mailroom Sidekiq end subgraph Integrated Services %% Mattermost Mattermost Mattermost ---> GitLabWorkhorse NGINX --> Mattermost %% Grafana Grafana NGINX --> Grafana end subgraph Metadata %% PostgreSQL PostgreSQL PostgreSQL --> Consul %% Consul 및 수신 Consul Puma ---> Consul Sidekiq ---> Consul Migrations --> PostgreSQL %% PgBouncer 및 수신 PgBouncer PgBouncer --> Consul PgBouncer --> PostgreSQL Sidekiq --> PgBouncer Puma --> PgBouncer end subgraph State %% Redis 및 수신 Redis Puma --> Redis Sidekiq --> Redis GitLabWorkhorse --> Redis Mailroom --> Redis GitLabKas --> Redis %% Sentinel 및 수신 Sentinel <--> Redis Puma --> Sentinel Sidekiq --> Sentinel GitLabWorkhorse --> Sentinel Mailroom --> Sentinel GitLabKas --> Sentinel end subgraph Git Repositories %% Gitaly / Praefect Praefect --> Gitaly GitLabKas --> Praefect GitLabShell --> Praefect GitLabWorkhorse --> Praefect Puma --> Praefect Sidekiq --> Praefect Praefect <--> PraefectPGSQL[PostgreSQL] %% Gitaly가 API 호출 %% 여기에 순서를 지정하여 배치합니다. Gitaly --> GitLabWorkhorse end subgraph Storage %% ObjectStorage 및 수신 트래픽 ObjectStorage["Object Storage"] Puma -- TCP 443 --> ObjectStorage Sidekiq -- TCP 443 --> ObjectStorage GitLabWorkhorse -- TCP 443 --> ObjectStorage Registry -- TCP 443 --> ObjectStorage GitLabPages -- TCP 443 --> ObjectStorage end subgraph Monitoring %% Prometheus Grafana -- TCP 9090 --> Prometheus[Prometheus] Prometheus -- TCP 80, 443 --> Puma RedisExporter[Redis Exporter] --> Redis Prometheus -- TCP 9121 --> RedisExporter PostgreSQLExporter[PostgreSQL Exporter] --> PostgreSQL PgBouncerExporter[PgBouncer Exporter] --> PgBouncer Prometheus -- TCP 9187 --> PostgreSQLExporter Prometheus -- TCP 9100 --> NodeExporter[Node Exporter] Prometheus -- TCP 9168 --> GitLabExporter[GitLab Exporter] Prometheus -- TCP 9127 --> PgBouncerExporter Prometheus --> Alertmanager GitLabExporter --> PostgreSQL GitLabExporter --> GitLabShell GitLabExporter --> Sidekiq %% Alertmanager Alertmanager -- TCP 25 --> SMTP end %% end subgraph GitLab end subgraph External subgraph External Services SMTP[SMTP Gateway] LDAP %% 외부 SMTP Sidekiq -- TCP 25 --> SMTP Puma -- TCP 25 --> SMTP Mailroom -- TCP 25 --> SMTP %% 외부 LDAP Puma -- TCP 369 --> LDAP Sidekiq -- TCP 369 --> LDAP %% Elasticsearch Elasticsearch Puma -- TCP 9200 --> Elasticsearch Sidekiq -- TCP 9200 --> Elasticsearch end subgraph External Monitoring %% Sentry Sidekiq -- TCP 80, 443 --> Sentry Puma -- TCP 80, 443 --> Sentry %% Jaeger Jaeger Sidekiq -- UDP 6831 --> Jaeger Puma -- UDP 6831 --> Jaeger Gitaly -- UDP 6831 --> Jaeger GitLabShell -- UDP 6831 --> Jaeger GitLabWorkhorse -- UDP 6831 --> Jaeger end %% end subgraph External end click Alertmanager "./architecture.html#alertmanager" click Praefect "./architecture.html#praefect" click Geo "./architecture.html#gitlab-geo" click NGINX "./architecture.html#nginx" click Runner "./architecture.html#gitlab-runner" click Registry "./architecture.html#registry" click ObjectStorage "./architecture.html#minio" click Mattermost "./architecture.html#mattermost" click Gitaly "./architecture.html#gitaly" click Jaeger "./architecture.html#jaeger" click GitLabWorkhorse "./architecture.html#gitlab-workhorse" click LDAP "./architecture.html#ldap-authentication" click Puma "./architecture.html#puma" click GitLabShell "./architecture.html#gitlab-shell" click SSH "./architecture.html#ssh-request-22" click Sidekiq "./architecture.html#sidekiq" click Sentry "./architecture.html#sentry" click GitLabExporter "./architecture.html#gitlab-exporter" click Elasticsearch "./architecture.html#elasticsearch" click Migrations "./architecture.html#database-migrations" click PostgreSQL "./architecture.html#postgresql" click Consul "./architecture.html#consul" click PgBouncer "./architecture.html#pgbouncer" click PgBouncerExporter "./architecture.html#pgbouncer-exporter" click RedisExporter "./architecture.html#redis-exporter" click Redis "./architecture.html#redis" click Prometheus "./architecture.html#prometheus" click Grafana "./architecture.html#grafana" click GitLabPages "./architecture.html#gitlab-pages" click PostgreSQLExporter "./architecture.html#postgresql-exporter" click SMTP "./architecture.html#outbound-email" click NodeExporter "./architecture.html#node-exporter"

컴포넌트 범례

✅ - 기본으로 설치됨
⚙ - 추가 구성이 필요함
⤓ - 수동 설치가 필요함
❌ - 지원되지 않거나 지침이 없음
N/A - 해당 없음

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

컴포넌트 목록

컴포넌트	설명	Omnibus GitLab	GitLab Environment Toolkit (GET)	GitLab chart	minikube Minimal	GitLab.com	소스	GDK	CE/EE
인증서 관리	TLS 설정, Let’s Encrypt	✅	✅	✅	⚙	✅	⚙	⚙	CE & EE
콘설	데이터베이스 노드 발견, 장애 조치	⚙	✅	❌	❌	✅	❌	❌	EE 전용
데이터베이스 마이그레이션	데이터베이스 마이그레이션	✅	✅	✅	✅	✅	⚙	✅	CE & EE
엘라스틱서치	GitLab 내에서 향상된 검색	⤓	⚙	⤓	⤓	✅	⤓	⚙	EE 전용
지탈리	GitLab에서 수행된 모든 Git 호출을 처리하는 Git RPC 서비스	✅	✅	✅	✅	✅	⚙	✅	CE & EE
GitLab 익스포터	다양한 GitLab 메트릭을 생성합니다	✅	✅	✅	✅	✅	❌	❌	CE & EE
GitLab 지오	지리적으로 분산된 GitLab 사이트	⚙	⚙	❌	❌	✅	❌	⚙	EE 전용
GitLab 페이지	정적 웹사이트를 호스팅합니다	⚙	⚙	❌	❌	✅	⚙	⚙	CE & EE
GitLab 에이전트	클라우드 네이티브 방식으로 쿠버네티스 클러스터를 통합합니다	⚙	⚙	⚙	❌	❌	⤓	⚙	EE 전용
GitLab 자가 모니터링: Alertmanager	프로메테우스에서 경보를 중복 제거하고 그룹화하여 경로를 설정합니다	⚙	⚙	✅	⚙	✅	❌	❌	CE & EE
GitLab 자가 모니터링: Grafana	메트릭 대시보드	✅	✅	⚙	⤓	✅	❌	⚙	CE & EE
GitLab 자가 모니터링: Jaeger	GitLab 인스턴스에서 생성된 추적을 확인합니다	❌	⚙	⚙	❌	❌	⤓	⚙	CE & EE
GitLab 자가 모니터링: Prometheus	시계열 데이터베이스, 메트릭 수집 및 쿼리 서비스	✅	✅	✅	⚙	✅	❌	⚙	CE & EE
GitLab 자가 모니터링: Sentry	GitLab 인스턴스에서 생성된 오류를 추적합니다	⤓	⤓	⤓	❌	✅	⤓	⤓	CE & EE
GitLab 셸	SSH 세션에서 `git`을 처리합니다	✅	✅	✅	✅	✅	⚙	✅	CE & EE
GitLab Workhorse	대용량 HTTP 요청을 처리하는 스마트한 리버스 프록시	✅	✅	✅	✅	✅	⚙	✅	CE & EE
인바운드 이메일 (SMTP)	이슈를 업데이트하기 위해 메시지를 수신합니다	⤓	⤓	⚙	⤓	✅	⤓	⤓	CE & EE
Jaeger 통합	배포된 애플리케이션에 대한 분산 추적	⤓	⤓	⤓	⤓	⤓	⤓	⚙	EE 전용
LDAP 인증	중앙집중식 LDAP 디렉터리에 대한 사용자 인증	⤓	⤓	⤓	⤓	❌	⤓	⚙	CE & EE
Mattermost	오픈 소스 Slack 대체	⚙	⚙	⤓	⤓	⤓	❌	⚙	CE & EE
MinIO	오브젝트 저장소 서비스	⤓	⤓	✅	✅	✅	❌	⚙	CE & EE
NGINX	요청을 적절한 컴포넌트로 라우팅하고 SSL을 종료함	✅	✅	✅	⚙	✅	⤓	⚙	CE & EE
노드 익스포터	시스템 메트릭을 포함한 프로메테우스 엔드포인트	✅	✅	N/A	N/A	✅	❌	❌	CE & EE
아웃바운드 이메일 (SMTP)	사용자에게 이메일 메시지를 보냅니다	⤓	⤓	⚙	⤓	✅	⤓	⤓	CE & EE
Patroni	PostgreSQL HA 클러스터 리더 선정 및 복제를 관리	⚙	✅	❌	❌	✅	❌	❌	EE 전용
PgBouncer 익스포터	PgBouncer 메트릭이 포함된 프로메테우스 엔드포인트	⚙	✅	❌	❌	✅	❌	❌	CE & EE
PgBouncer	데이터베이스 연결 풀링, 장애 조치	⚙	✅	❌	❌	✅	❌	❌	EE 전용
PostgreSQL 익스포터	PostgreSQL 메트릭이 포함된 프로메테우스 엔드포인트	✅	✅	✅	✅	✅	❌	❌	CE & EE
PostgreSQL	데이터베이스	✅	✅	✅	✅	✅	⤓	✅	CE & EE
Praefect	Git 클라이언트와 지탈리 스토리지 노드 사이의 투명한 프록시	✅	✅	⚙	❌	✅	⚙	✅	CE & EE
퓨마 (GitLab Rails)	웹 인터페이스와 API에 대한 요청을 처리합니다	✅	✅	✅	✅	✅	⚙	✅	CE & EE
레디스 익스포터	레디스 메트릭이 포함된 프로메테우스 엔드포인트	✅	✅	✅	✅	✅	❌	❌	CE & EE
레디스	캐싱 서비스	✅	✅	✅	✅	✅	⤓	✅	CE & EE
레지스트리	컨테이너 레지스트리로 이미지를 푸시하고 풀링합니다	⚙	⚙	✅	✅	✅	⤓	⚙	CE & EE
런너	GitLab CI/CD 작업을 실행함	⤓	⤓	✅	⚙	✅	⚙	⚙	CE & EE
Sentry 통합	배포된 애플리케이션에 대한 오류를 추적함	⤓	⤓	⤓	⤓	⤓	⤓	⤓	CE & EE
사이드킥	백그라운드 작업 프로세서	✅	✅	✅	✅	✅	✅	✅	CE & EE
토큰 취소 API	유출된 시크릿을 받아들이고 취소함	❌	❌	❌	❌	✅	❌	❌	EE 전용

구성 요소 세부 정보

이 문서는 GitLab 내부 및 구성 요소 간의 상호 작용에 대해 더 잘 이해하고자 하는 시스템 관리자 및 GitLab 지원 엔지니어들이 사용할 수 있도록 설계되었습니다.

GitLab이 배포되면 아래 프로세스의 결합으로 간주해야 합니다. 문제 해결 또는 디버깅 시 참조하는 구성 요소를 최대한 구체적으로 설명해야 합니다. 이렇게 하면 명확성이 높아지고 혼란이 줄어들 것입니다.

계층

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

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

Alertmanager

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

Alert manager는 Prometheus에서 제공하는 도구로 “Prometheus 서버와 같은 클라이언트 응용 프로그램에 의해 보내진 경보를 처리합니다. 경보를 중복 처리하고 그룹화하여 올바른 수신기 통합(이메일, PagerDuty 또는 Opsgenie와 같은)으로 라우팅합니다. 또한 경보를 조용히 하고 억제하는 역할도 합니다.” 이슈 #45740에서 경보 대상에 대해 더 읽어볼 수 있습니다.

인증서 관리

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

Consul

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

Consul은 서비스 탐지 및 구성을 위한 도구입니다. Consul은 분산형이며 고가용성이 높으며 매우 확장 가능합니다.

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

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

Elasticsearch

프로젝트 페이지
구성:
계층: 코어 서비스 (데이터)
GitLab.com: GitLab.com에서 고급 검색 작동시키기(Closed) 에픽.

Elasticsearch는 클라우드용으로 제작된 분산 RESTful 검색 엔진입니다.

Gitaly

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

Gitaly는 GitLab이 분산 배포(GitLab.com 또는 고가용성 배포와 같은)에서 NFS를 필요로하지 않도록 설계된 서비스입니다. 11.3.0부터 이 서비스는 GitLab의 모든 Git 수준 액세스를 처리합니다. 프로젝트에 대해 더 자세히 알아보려면 프로젝트의 README에서 읽어보세요.

Praefect

프로젝트 페이지
Configuration:
- Omnibus
- 소스
Layer: Core Service (Data)
Process: praefect

Praefect는 각 Git 클라이언트와 Gitaly 사이의 투명한 프록시로, 저장소 업데이트의 복제를 조정합니다.

GitLab Geo

Configuration:
Layer: Core Service (Processor)

Geo는 분산된 팀의 개발을 가속화하기 위해 만들어진 프리미엄 기능으로, 기본 GitLab 인스턴스의 하나 이상의 읽기 전용 미러를 제공합니다. 이 미러(지오 보조 사이트)는 대용량 저장소 및 프로젝트를 복제하거나 가져오는 데 걸리는 시간을 줄이거나, 재해 복구 솔루션의 일부가 될 수 있습니다.

GitLab Exporter

프로젝트 페이지
Configuration:
- Omnibus
- Charts
Layer: Monitoring
Process: gitlab-exporter
GitLab.com: GitLab.com 모니터링

GitLab Exporter는 GitLab 응용 프로그램 내부의 지표를 Prometheus로 내보내는 데 사용되는 내부에서 디자인된 프로세스입니다. 프로젝트의 README에서 자세히 읽어볼 수 있습니다.

GitLab agent

프로젝트 페이지
Configuration:
- Omnibus
- Charts

GitLab agent는 안전하고 클라우드 네이티브 방식으로 GitLab과 Kubernetes 통합 작업을 해결하기 위한 액티브 인 클러스터 구성 요소입니다.

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

GitLab Pages

Configuration:
Layer: Core Service (Processor)
GitLab.com: GitLab Pages

GitLab Pages는 GitLab 저장소에서 직접 정적 웹사이트를 게시할 수 있는 기능입니다.

포트폴리오, 문서, 선언문, 비즈니스 프레젠테이션과 같은 개인 또는 비즈니스 웹사이트에 사용할 수 있으며, 콘텐츠에는 임의의 라이선스를 부여할 수 있습니다.

GitLab Runner

프로젝트 페이지
Configuration:
Layer: Core Service (Processor)
GitLab.com: Runners

GitLab Runner는 작업을 실행하고 결과를 GitLab으로 보냅니다.

GitLab CI/CD는 테스트를 조정하는 GitLab과 함께 제공되는 오픈 소스 지속적 통합 서비스입니다. 이 프로젝트의 이전 이름은 GitLab CI Multi Runner였지만 이제부터 GitLab Runner (CI 없음)을 사용해주시기 바랍니다.

GitLab Shell

프로젝트 페이지
문서
Configuration:
Layer: Core Service (Processor)

GitLab Shell은 GitLab에서 SSH 기반의 git 세션을 처리하고 인가된 키 목록을 수정하기 위해 설계된 프로그램입니다. GitLab Shell은 유닉스 쉘이나 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 클라우드 저장소 서비스와 호환됩니다. 사진, 동영상, 로그 파일, 백업 및 컨테이너/가상머신 이미지와 같은 구조화되지 않은 데이터를 저장하는 데 가장 적합합니다. 객체의 크기는 몇 KB부터 최대 5TB까지 가능합니다.

NGINX

프로젝트 페이지:
- Omnibus
- 차트
설정:
레이어: 핵심 서비스 (프로세서)
프로세스: nginx

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

노드 익스포터

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 모니터링
프로세스: node-exporter
GitLab.com: GitLab.com의 모니터링

노드 익스포터는 우리에게 기계의 지표(CPU/디스크/로드 등)를 제공하는 프로메테우스 도구입니다. 이는 프로메테우스 프로젝트의 일반 오픈 소스 오퍼링의 패키지 버전입니다.

Patroni

프로젝트 페이지
구성:
- Omnibus
레이어: 코어 서비스(데이터)
프로세스: patroni
GitLab.com: 데이터베이스 아키텍처

PgBouncer

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

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

PgBouncer 익스포터

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

PgBouncer를 위한 프로메테우스 익스포터입니다. 9127/metrics에서 메트릭을 익스포트합니다.

PostgreSQL

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

인기 있는 데이터베이스를 제공하여 애플리케이션 메타데이터와 사용자 정보의 저장 공간을 제공합니다.

PostgreSQL 익스포터

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 모니터링
프로세스: postgres-exporter
GitLab.com: GitLab.com의 모니터링

postgres_exporter는 PostgreSQL에 대한 데이터를 프로메테우스에 제공하여 Grafana 대시보드에서 사용하는 커뮤니티 제공 프로메테우스 익스포터입니다.

프로메테우스

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 모니터링
프로세스: prometheus
GitLab.com: 프로메테우스

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

레디스

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

Redis는 다음을 저장하기 위한 공간을 제공합니다:

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

GitLab이 Redis를 사용하는 방법에 대한 자세한 정보는 Redis 가이드라인을 참조하세요.

Redis Exporter

프로젝트 페이지
구성:
- Omnibus
- 차트
레이어: 모니터링
프로세스: redis-exporter
GitLab.com: GitLab.com의 모니터링

Redis Exporter는 Prometheus에 Redis 프로세스에 대한 특정 메트릭을 제공하여 이러한 메트릭을 Grafana에서 그래프로 표시할 수 있도록 설계되었습니다.

레지스트리

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

레지스트리는 사용자가 자체 Docker 이미지를 저장하는 데 사용하는 것입니다. 번들된 레지스트리는 로드 밸런서로 NGINX를 사용하고 인증 관리자로 GitLab을 사용합니다. 클라이언트가 레지스트리에서 이미지를 끌거나 푸시하도록 요청하는 경우, GitLab 인스턴스에서 인증 토큰을 얻을 위치를 상세히 설명하는 헤더와 함께 401 응답을 반환합니다. 그런 다음 클라이언트는 GitLab에서 풀 또는 푸시 인증 토큰을 요청하고 레지스트리에 대한 원본 요청을 다시 시도합니다. 자세한 정보는 토큰 인증을 참조하세요.

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

Sentry

프로젝트 페이지
구성:
레이어: 모니터링
GitLab.com: Sentry 검색

Sentry는 본질적으로 실시간으로 충돌을 모니터링하고 수정하는 데 도움이 되는 서비스입니다. 서버는 Python으로 되어 있지만, 모든 언어의 모든 애플리케이션에서 이벤트를 보낼 수 있는 전체 API가 포함되어 있습니다.

배포된 앱을 모니터링하려면 Sentry 통합 문서를 참조하세요.

Sidekiq

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

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

Puma

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

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

Puma는 사용자 인터페이스 기능을 제공하는 핵심 Rails 애플리케이션을 실행하는 데 사용되는 Ruby 애플리케이션 서버입니다. 이는 GitLab 버전에 따라 bundle 또는 config.ru로 프로세스 출력에 표시됩니다.

#### LDAP 인증

- 구성:
  - [Omnibus](../administration/auth/ldap/index.md)
  - [Charts](https://docs.gitlab.com/charts/charts/globals.html#ldap)
  - [Source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
  - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/ldap.md)
- 레이어: Core Service (Processor)
- GitLab.com: [상품 계층](https://about.gitlab.com/pricing/#gitlab-com)

#### 발신 이메일

- 구성:
  - [Omnibus](https://docs.gitlab.com/omnibus/settings/smtp.html)
  - [Charts](https://docs.gitlab.com/charts/installation/command-line-options.html#outgoing-email-configuration)
  - [Source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
  - [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
- 레이어: Core Service (Processor)
- GitLab.com: [메일 구성](../user/gitlab_com/index.md#mail-configuration)

#### 수신 이메일

- 구성:
  - [Omnibus](../administration/incoming_email.md)
  - [Charts](https://docs.gitlab.com/charts/installation/command-line-options.html#incoming-email-configuration)
  - [Source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
  - [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
- 레이어: Core Service (Processor)
- GitLab.com: [메일 구성](../user/gitlab_com/index.md#mail-configuration)

## 요청 유형별 GitLab

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

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

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

### GitLab Web HTTP 요청 주기

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

- NGINX - 첫 번째 라인 리버스 프록시 역할을 합니다.
- GitLab Workhorse - Puma에 대한 부하를 줄이기 위해 웹 요청이므로 응용 프로그램에 액세스해야 하므로 Puma로 라우팅됩니다.
- PostgreSQL/Gitaly/Redis - 요청 유형에 따라 이러한 서비스를 사용하여 데이터를 저장하거나 검색할 수 있습니다.

### GitLab Git 요청 주기

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

### 웹 요청 (80/443)

HTTP를 통한 Git 작업은 [Git 문서](https://git-scm.com/docs/http-protocol)에서 설명한 상태가 없는 "스마트" 프로토콜을 사용하지만, 이러한 작업을 처리하는 책임은 여러 GitLab 구성 요소에 분산됩니다.

여기 `git fetch`에 대한 순서도가 있습니다. 모든 요청이 NGINX와 기타 HTTP 로드 밸런서를 통과하지만 그들에게 의해 어떠한 방식으로든 변형되지는 않습니다. 모든 경로는 `/namespace/project.git` URL을 기준으로 표시됩니다.

The translation above keeps the Markdown format and adheres to the provided rules.

SSH 요청 (22)

SSH를 통한 Git 작업은 Git 문서에 설명된 stateful 프로토콜을 사용할 수 있지만, 이에 대한 처리 책임은 여러 GitLab 구성 요소에 분배됩니다.

GitLab 구성 요소 중 어느 것도 SSH를 직접적으로 처리하지 않으며, 모든 SSH 연결은 클라이언트 기기의 Git과 연결을 종료하는 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: Bidirectional communication between Git client and server 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 키를 수정할 때마다 실행되도록 예약된 AuthorizedKeysWorker에 의해 최신 상태로 유지됩니다.

키 대신 SSH 인증서를 사용할 수도 있습니다. 이 경우, AuthorizedKeysCommand 대신 AuthorizedPrincipalsCommand가 사용됩니다. 이는 나중에 /api/internal/allowed 호출에서 key_id 대신 사용되는 Rails 내부 API를 사용하지 않고, 인증서에서 사용자 이름을 추출합니다.

GitLab Shell에는 Gitaly와 관련이 없는 몇 가지 작업도 있습니다. 예를 들어 이중 인증 코드를 재설정하는 것도 이와 유사하게 처리되지만, Gitaly로의 왕복 통신이 없습니다. 이 경우, Rails는 내부 API 호출의 일부로 동작하며, GitLab Shell은 사용자에게 응답을 직접 스트리밍합니다.

시스템 레이아웃

그림에서 ~git을 참조할 때에는 일반적으로 /home/git인 Git 사용자의 홈 디렉터리를 의미합니다.

GitLab은 주로 git 사용자로 /home/git 사용자 홈 디렉터리에 설치됩니다. 홈 디렉터리에는 GitLab 서버 소프트웨어 및 저장소가 있으며(단, 저장소 위치는 구성할 수 있음), 빈 저장소는 /home/git/repositories에 위치합니다. GitLab은 루비 온 레일즈 애플리케이션이므로 내부 작업의 구체적인 내용은 루비 온 레일즈 애플리케이션 작동 방식을 공부함으로써 배울 수 있습니다.

SSH를 통해 저장소를 제공하기 위해 /home/git/gitlab-shell에 설치된 GitLab Shell라는 애드온 응용 프로그램이 있습니다.

설치 폴더 요약

요약하면, 여기에 git 사용자의 홈 디렉터리의 디렉터리 구조가 있습니다.

프로세스

ps aux | grep '^git'

GitLab에는 작동에 필요한 여러 구성 요소가 있습니다. 지속적인 데이터베이스(포스트그레스)와 레디스 데이터베이스가 필요하며, Apache httpd 또는 NGINX를 통해 Puma에 proxypass할 수 있습니다. 이러한 구성 요소는 GitLab과는 다른 시스템 사용자로 실행되어야 합니다(예: postgres, redis, www-data 대신에 git).

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

저장소 접근

저장소는 HTTP 또는 SSH를 통해 접근됩니다. HTTP 클론/푸시/풀은 GitLab API를 사용하며, SSH 클론은 GitLab 셸(이전에 설명함)에서 처리됩니다.

문제 해결

자세한 정보는 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 셸:

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

SSH:

/var/log/auth.log auth 로그 (Ubuntu).
/var/log/secure auth 로그 (RHEL).

NGINX:

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

Apache httpd:

Apache 로그의 설명.
/var/log/apache2/에는 에러 및 출력 로그가 포함됩니다 (Ubuntu).
/var/log/httpd/에는 에러 및 출력 로그가 포함됩니다 (RHEL).

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 셸에는 /home/git/gitlab-shell/config.yml에 구성 파일이 있습니다.

GitLab Rails에 새로운 설정 추가

gitlab.yml에 속하는 설정은 다음과 관련된 설정을 포함합니다:

여러 서비스 간의 애플리케이션이 연결된 방식. 예를 들어, Gitaly 주소, Redis 주소, Postgres 주소 및 Consul 주소.
분산 추적 구성 및 일부 가시성 구성. 예를 들어, 히스토그램 버킷 경계.
Rails 초기화 중에 구성해야 하는 모든 것들로, 아마도 Postgres 연결이 수립되기 전에 설정해야 하는 것들.

다른 많은 설정은 대부분 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 모델 게이트웨이를 사용할 수 있습니다.