GitLab 아키텍처 개요

소프트웨어 전달

GitLab의 두 가지 소프트웨어 배포가 있습니다:

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

GitLab의 새 버전은 안정 브랜치에서 릴리스되며, main 브랜치는 최신 안정 버전을 사용하기 위해 bleeding-edge 개발에 사용됩니다.

더 많은 정보는 GitLab 릴리스 프로세스에서 확인할 수 있습니다.

두 배포 모두 추가 구성 요소가 필요합니다. 이러한 구성 요소에 대한 설명은 구성 요소 세부 정보 섹션에 나와 있으며, 각각의 저장소를 갖고 있습니다. 각 종속 구성 요소의 새 버전은 일반적으로 태그가 되지만, GitLab 코드베이스의 main 브랜치에서 유지하면 해당 구성 요소의 최신 안정 버전을 얻을 수 있습니다. 새 버전은 일반적으로 GitLab 릴리스와 함께 약간의 보안 업데이트 빼고 동시에 릴리스됩니다.

구성 요소

GitLab의 전형적인 설치는 GNU/Linux에 있지만, Kubernetes 플랫폼을 사용하는 설치도 계속 증가하고 있습니다. 가장 큰 알려진 GitLab 인스턴스는 공식 GitLab Helm 차트 및 공식 Linux 패키지를 사용하여 배포된 GitLab.com에 있습니다.

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

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

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

HTTP/HTTPS를 통해 저장소를 제공하는 경우, GitLab은 권한 및 접근을 해결하고 Git 객체를 제공하기 위해 GitLab API를 사용합니다.

애드온 구성 요소인 GitLab Shell은 SSH를 통해 저장소를 제공합니다. 이는 SSH 키를 구성 파일의 GitLab Shell 섹션에 정의된 위치에서 관리합니다. 해당 위치의 파일을 수동으로 편집해서는 안 됩니다. GitLab Shell은 Git 객체를 제공하기 위해 bare 저장소에 접근하며, GitLab이 처리할 작업에 대한 Sidekiq에 작업을 제출하기 위해 Redis와 통신합니다. 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 TB %% 구성 요소 선언 및 서식 지정 HTTP((HTTP/HTTPS)) SSH((SSH)) GitLabPages(GitLab Pages) GitLabWorkhorse(GitLab Workhorse) GitLabShell(GitLab Shell) Gitaly(Gitaly) Puma("Puma (Gitlab Rails)") Sidekiq("Sidekiq (GitLab Rails)") PostgreSQL(PostgreSQL) Redis(Redis) HTTP -- TCP 80,443 --> NGINX SSH -- TCP 22 --> GitLabShell NGINX -- TCP 8090 --> GitLabPages NGINX --> GitLabWorkhorse GitLabShell --> Gitaly GitLabShell --> GitLabWorkhorse GitLabWorkhorse --> Gitaly GitLabWorkhorse --> Puma GitLabWorkhorse --> Redis Sidekiq --> PostgreSQL Sidekiq --> Redis Puma --> PostgreSQL Puma --> Redis Puma --> Gitaly Gitaly --> GitLabWorkhorse

모든 연결은 명시적으로 언급되지 않는 한 Unix 소켓을 사용합니다.

구성 요소 다이어그램

%%{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 서비스 %% 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 통합된 서비스 %% Mattermost Mattermost Mattermost ---> GitLabWorkhorse NGINX --> Mattermost %% Grafana Grafana NGINX --> Grafana end subgraph 메타데이터 %% PostgreSQL PostgreSQL PostgreSQL --> Consul %% Consul 및 수신 Consul Puma ---> Consul Sidekiq ---> Consul Migrations --> PostgreSQL %% PgBouncer 및 수신 PgBouncer PgBouncer --> Consul PgBouncer --> PostgreSQL Sidekiq --> PgBouncer Puma --> PgBouncer end subgraph 상태 %% 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 저장소 %% Gitaly / Praefect Praefect --> Gitaly GitLabKas --> Praefect GitLabShell --> Praefect GitLabWorkhorse --> Praefect Puma --> Praefect Sidekiq --> Praefect Praefect <--> PraefectPGSQL[PostgreSQL] %% Gitaly는 API 호출 수행 %% 위치 설정을 보장하기 위해 여기에 순서대로 배치. Gitaly --> GitLabWorkhorse end subgraph 저장소 %% 오브젝트 스토리지 및 수신 트래픽 ObjectStorage["오브젝트 스토리지"] Puma -- TCP 443 --> ObjectStorage Sidekiq -- TCP 443 --> ObjectStorage GitLabWorkhorse -- TCP 443 --> ObjectStorage Registry -- TCP 443 --> ObjectStorage GitLabPages -- TCP 443 --> ObjectStorage %% Gitaly는 오브젝트 스토리지로 저장소 백업 수행 가능 Gitaly --> ObjectStorage end subgraph 모니터링 %% 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 %% GitLab 하위 그래프 종료 end subgraph 외부 subgraph 외부 서비스 SMTP[SMTP 게이트웨이] 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 Elasticsearch --> Praefect %% Zoekt Zoekt --> Praefect end subgraph 외부 모니터링 %% 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 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 차트 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 지오 지리적으로 분산된 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
노드 익스포터 시스템 메트릭이 있는 Prometheus 엔드포인트 ✅ ✅ N/A N/A ✅ ❌ ❌ CE & EE
나가는 이메일 (SMTP) 사용자에게 이메일 메시지를 보냄 ⤓ ⤓ ⚙ ⤓ ✅ ⤓ ⤓ CE & EE
Patroni PostgreSQL HA 클러스터 리더 선정 및 복제 관리 ⚙ ✅ ❌ ❌ ✅ ❌ ❌ EE Only
PgBouncer 익스포터 PgBouncer 메트릭을 가진 Prometheus 엔드포인트 ⚙ ✅ ❌ ❌ ✅ ❌ ❌ CE & EE
PgBouncer 데이터베이스 연결 풀링, 장애 극복 ⚙ ✅ ❌ ❌ ✅ ❌ ❌ EE Only
PostgreSQL 익스포터 PostgreSQL 메트릭을 가진 Prometheus 엔드포인트 ✅ ✅ ✅ ✅ ✅ ❌ ❌ CE & EE
PostgreSQL 데이터베이스 ✅ ✅ ✅ ✅ ✅ ⤓ ✅ CE & EE
Praefect Git 클라이언트와 Gitaly 저장소 노드 사이의 투명한 프록시 ✅ ✅ ⚙ ❌ ❌ ⚙ ✅ CE & EE
Puma (GitLab Rails) 웹 인터페이스 및 API 요청 처리 ✅ ✅ ✅ ✅ ✅ ⚙ ✅ CE & EE
Redis 익스포터 Redis 메트릭을 가진 Prometheus 엔드포인트 ✅ ✅ ✅ ✅ ✅ ❌ ❌ CE & EE
Redis 캐시 서비스 ✅ ✅ ✅ ✅ ✅ ⤓ ✅ CE & EE
레지스트리 컨테이너 레지스트리, 이미지 푸시 및 풀 허용 ⚙ ⚙ ✅ ✅ ✅ ⤓ ⚙ CE & EE
Runner GitLab CI/CD 작업 실행 ⤓ ⤓ ✅ ⚙ ✅ ⚙ ⚙ CE & EE
Sentry 통합 배포된 애플리케이션의 오류 추적 ⤓ ⤓ ⤓ ⤓ ⤓ ⤓ ⤓ CE & EE
Sidekiq 백그라운드 작업 프로세서 ✅ ✅ ✅ ✅ ✅ ✅ ✅ CE & EE
토큰 폐기 API 유출된 비밀을 수신 및 폐기하는 API ❌ ❌ ❌ ❌ ✅ ❌ ❌ EE Only

구성 요소 세부 정보

이 문서는 GitLab 및 해당 구성 요소의 내부 작동에 대해 자세히 알고 싶은 시스템 관리자 및 GitLab 지원 엔지니어들이 사용할 수 있도록 설계되었습니다.

GitLab이 배포될 때 다음 프로세스들의 융합체로 간주해야 합니다. 문제 해결 또는 디버깅 시 참조하는 구성 요소를 가능한 한 구체적으로 지정하십시오. 이렇게 하면 명확성이 높아지고 혼란이 줄어듭니다.

레이어

프로세스 관점에서 GitLab은 두 개의 레이어를 갖는 것으로 간주할 수 있습니다.

  • 모니터링: 이 레이어에서 나온 내용은 GitLab 애플리케이션을 제공하는 데 필요하지 않지만, 시스템 관리자가 인프라에 대한 더 많은 통찰력을 얻을 수 있도록 합니다.
  • 코어: 플랫폼으로서의 GitLab 제공에 중요한 프로세스들. 이러한 프로세스가 중단되면 GitLab 장애가 발생합니다. 코어 레이어는 다음과 같이 더 세분화할 수 있습니다:
    • 프로세서: 이러한 프로세스는 실제 작업을 수행하고 서비스를 표시하는 데 책임이 있습니다.
    • 데이터: 이러한 서비스는 GitLab 서비스를 위해 구조화된 데이터를 저장하거나 노출시킵니다.

Alertmanager

Alert manager는 Prometheus에서 제공하는 도구로, “Prometheus 서버와 같은 클라이언트 애플리케이션에서 전송된 경고를 처리합니다. 중복 제거, 그룹화 및 이를 이메일, PagerDuty, 또는 Opsgenie과 같은 올바른 수신기 통합으로 라우팅합니다. 또한 경고의 음소거 및 억제를 처리합니다.” issue #45740에서 우리가 무엇을 경고하는지에 대해 자세히 읽을 수 있습니다.

인증서 관리

Consul

Consul은 서비스 검색 및 구성을 위한 도구입니다. Consul은 분산, 고가용성 및 극도로 확장 가능합니다.

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

Elasticsearch

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

Gitaly

Gitaly는 GitLab에서 분산 배포(GitLab.com 또는 고가용성 배포 등)의 Git 저장소에 대한 NFS 필요성을 제거하기 위해 설계된 서비스입니다. 11.3.0부터 이 서비스는 GitLab에서 모든 Git 레벨 액세스를 처리합니다. 프로젝트에 대해 자세히 읽을 수 있습니다. 프로젝트의 README.

Praefect

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

GitLab Geo

Geo는 프라이머리 GitLab 인스턴스의 하나 이상의 읽기 전용 미러를 제공해 분산 팀의 개발 속도를 높이는 데 도움을 주도록 만들어진 프리미엄 기능입니다. 이 미러(지오 세컨더리 사이트)는 대형 저장소 및 프로젝트의 복제 또는 검색 시간을 줄이거나 재해 복구 솔루션에 포함될 수 있습니다.

GitLab Exporter

GitLab Exporter는 GitLab 애플리케이션 내부에 대한 메트릭을 Prometheus로 내보낼 수 있는 내부에서 설계된 프로세스입니다. 프로젝트의 README에서 자세히 읽을 수 있습니다.

GitLab 에이전트

GitLab 에이전트는 클러스터 내에서 활성화되는 구성 요소로, GitLab과 Kubernetes 통합 작업을 안전하고 클라우드 기반으로 해결할 수 있습니다.

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

GitLab 페이지

GitLab Pages는 GitLab 리포지토리에서 정적 웹사이트를 직접 발행할 수 있는 기능입니다.

개인이나 비즈니스 웹사이트 (포트폴리오, 문서, 선언문, 비즈니스 프레젠테이션 등)에 사용할 수 있습니다. 콘텐츠에는 라이선스를 지정할 수도 있습니다.

GitLab 러너

GitLab 러너는 작업을 실행하고 결과를 GitLab에 전송합니다.

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

GitLab Shell

GitLab Shell은 GitLab에서 SSH 기반 git 세션을 처리하고 인가된 키 목록을 수정하는 프로그램으로, 유닉스 셸이나 Bash 또는 Zsh의 대체품은 아닙니다.

GitLab Workhorse

GitLab Workhorse는 Puma의 압박을 완화하기 위해 GitLab에서 설계된 프로그램입니다. GitLab 전체의 속도를 높이도록 지원하는 스마트한 리버스 프록시 역할을 합니다. 개발에 관한 역사적 이유에 대해 자세히 읽을 수 있습니다.

Grafana

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

Jaeger

Jaeger는 Dapper 및 OpenZipkin에서 영감을 받아서 만들어진 분산 추적 시스템입니다. 마이크로서비스 기반 분산 시스템의 모니터링에 사용될 수 있습니다.

Logrotate

GitLab은 모든 로그를 기록하도록 Logrotate를 번들로 제공합니다. 우리는 책임감 있게 로그를 기록하기 위해 이 일반 오픈 소스 오퍼링을 패키지로 제공합니다.

Mattermost

Mattermost는 오픈 소스, 프라이빗 클라우드, Slack 대안입니다. https://mattermost.com.

MinIO

MinIO는 GNU AGPL v3.0으로 출시된 객체 저장 서버입니다. Amazon S3 클라우드 저장소 서비스와 호환됩니다. 사진, 비디오, 로그 파일, 백업 및 컨테이너/가상 머신 이미지와 같은 비구조화된 데이터를 저장하는 데 가장 적합합니다. 객체의 크기는 몇 KB에서 최대 5 TB까지 가능합니다.

NGINX

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

Node Exporter

Node Exporter는 기계의 메트릭을 제공하는 Prometheus 도구입니다 (CPU/디스크/로드 등). 이는 Prometheus 프로젝트의 일반적인 오픈 소스 오퍼링의 패키지 버전입니다.

Patroni

PgBouncer

PostgreSQL을 위한 가벼운 연결 풀러입니다.

PgBouncer Exporter

PgBouncer의 Prometheus 익스포터로 9127/metrics에서 메트릭을 익스포트합니다.

PostgreSQL

인기 있는 데이터베이스를 패키징하여 응용 프로그램 메타 데이터 및 사용자 정보의 저장 공간을 제공합니다.

PostgreSQL Exporter

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

프로메테우스

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

레디스

레디스는 다음을 저장하는 데 사용되는 패키지입니다:

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

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

레디스 익스포터

레디스 익스포터는 프로메테우스에게 레디스 프로세스에 대한 특정 메트릭을 제공하여 이러한 메트릭을 Grafana에서 그래프화할 수 있도록 설계되었습니다.

레지스트리

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

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

센트리

센트리는 기본적으로 실시간으로 충돌을 모니터링하고 수정하는 데 도움이 되는 서비스입니다. 서버는 Python으로 작성되었지만 모든 언어의 애플리케이션에서 이벤트를 전송하기 위한 완전한 API를 포함하고 있습니다.

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

Sidekiq

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

푸마

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

Puma는 GitLab에서 사용자 지향 기능을 제공하는 핵심 Rails 애플리케이션을 실행하는 데 사용되는 루비 응용 프로그램 서버입니다. 이것은 GitLab 버전에 따라 process 출력에 bundle 또는 config.ru로 표시됩니다.

LDAP 인증

아웃바운드 이메일

인바운드 이메일

요청 유형별 GitLab

GitLab은 서비스에 액세스하기 위한 끝 사용자용 두 가지 “인터페이스”를 제공합니다:

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

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

GitLab 웹 HTTP 요청 주기

HTTP 엔드포인트(예: /users/sign_in)로 요청할 때, 요청은 GitLab 서비스를 통해 다음 경로를 따릅니다:

  • NGINX - 첫 번째 라인 역방향 프록시 역할 수행.
  • GitLab Workhorse - Puma에 대한 부하를 줄이기 위해 Rails 애플리케이션으로 전달해야 하는지 여부를 결정.
  • Puma - 웹 요청이므로 응용 프로그램에 액세스해야 하며 Puma에 경로를 지정.
  • PostgreSQL/Gitaly/Redis - 요청 유형에 따라 데이터를 저장하거나 검색해야 할 수 있음.

GitLab Git 요청 주기

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

시스템 레이아웃

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

GitLab은 주로 git 사용자로 /home/git 사용자 홈 디렉터리에 설치됩니다. 홈 디렉터리 내에는 GitLab 서버 소프트웨어와 저장소가 있습니다(단, 저장소 위치는 구성 가능합니다).

베어 저장소는 /home/git/repositories에 위치합니다. GitLab은 루비 온 레일 응용 프로그램이므로 내부 작업의 세부 정보는 루비 온 레일 응용 프로그램 작동 방식을 연구하여 배울 수 있습니다.

설치 폴더 요약

여기에서 git 사용자 홈 디렉터리의 디렉터리 구조를 요약하였습니다.

프로세스 

ps aux | grep '^git'

GitLab에는 작동에 필요한 여러 구성 요소가 있습니다. 지속적인 데이터베이스(PostgreSQL)와 레디스 데이터베이스가 필요하며, Puma를 8080번 포트에서 실행하는 Apache httpd 또는 NGINX를 proxypass하는 등 다양한 요소들을 이용합니다. 이러한 구성 요소는 GitLab의 시스템 사용자와 다르게 실행되어야 합니다(예: postgres, redis, www-data, git 대신).

git 사용자로서, Sidekiq와 Puma(기본적으로 8080번 포트에서 실행되는 간단한 루비 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
Usage: service gitlab {start|stop|restart|reload|status}

레디스 (키-값 저장소/비영구 데이터베이스): 

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

SSH 데몬: 

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

웹 서버 (다음 중 하나): 

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

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

지속적인 데이터베이스: 

$ /etc/init.d/postgresql
Usage: /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 auth log.
  • RHEL의 경우 /var/log/secure auth log.

NGINX:

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

Apache httpd:

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

레디스:

  • /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 주소, PostgreSQL 주소 및 Consul 주소와 같이 응용 프로그램이 여러 서비스 간에 어떻게 묶이는지에 대한 것입니다. 분산 추적 구성 및 일부 관측성 구성, 예를 들어, 히스토그램 버킷 경계 등이 포함됩니다. 일반적으로 Rails 초기화 중에 구성해야 하는 것, 아마도 PostgreSQL 연결이 설정되기 전에 구성해야 하는 것입니다.

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

  1. Omnibus에도 추가되었는지 확인하세요.
  2. 필요한 경우 Charts에도 추가되었는지 확인하세요.
  3. 필요한 경우 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 아키텍처에는 AI 기반 기능을 활성화하는 SaaS 모델 게이트웨이가 제공됩니다.