GitLab 아키텍처 개요

소프트웨어 배포

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

GitLab은 다양한 구독 아래에서 제공됩니다.

GitLab의 새로운 버전은 안정적인 브랜치에서 릴리즈되며, main 브랜치는 bleeding-edge 개발에 사용됩니다.

자세한 내용은 GitLab 릴리즈 프로세스를 참조하세요.

두 배포 모두 추가 구성 요소가 필요합니다. 이러한 구성 요소는 구성 요소 세부정보 섹션에 설명되어 있으며, 각 구성 요소는 자체 저장소를 가지고 있습니다.

각 의존 구성 요소의 새로운 버전은 일반적으로 태그로 제공되지만, GitLab 코드베이스의 main 브랜치를 사용하면 이러한 구성 요소의 최신 안정 버전을 얻을 수 있습니다. 새로운 버전은 일반적으로 GitLab 릴리즈와 거의 동시에 릴리즈되며, 중요한 비공식 보안 업데이트는 제외됩니다.

구성 요소

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

일반적인 설치에서는 NGINX 또는 Apache를 웹 서버로 사용하여 GitLab Workhorse를 통해 프록시를 설정하고 Puma 애플리케이션 서버로 전달합니다. GitLab은 Puma 애플리케이션 서버를 사용하여 웹 페이지와 GitLab API를 제공합니다. Sidekiq를 작업 큐로 사용하며, 이는 다시 Redis를 비영속적인 데이터베이스 백엔드로 사용하여 작업 정보, 메타데이터 및 수신 작업을 처리합니다.

기본적으로 Puma와 Workhorse 간의 통신은 유닉스 도메인 소켓을 통해 이루어지지만, TCP를 통한 요청 전달도 지원됩니다. Workhorse는 gitlab/public 디렉터리에 접근하여 정적 페이지, 업로드(예: 아바타 이미지 또는 첨부 파일) 및 사전 컴파일된 자산을 제공하기 위해 Puma 애플리케이션 서버를 우회합니다.

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

HTTP/HTTPS를 통해 저장소를 제공할 때 GitLab은 GitLab API를 사용하여 인증 및 접근을 확인하고 Git 개체를 제공합니다.

부가 구성 요소인 GitLab Shell은 SSH를 통해 저장소를 제공합니다. GitLab Shell은 구성 파일의 GitLab Shell 섹션에서 정의된 위치 내에서 SSH 키를 관리합니다. 해당 위치의 파일은 수동으로 편집해서는 안 됩니다. GitLab Shell은 Gitaly를 통해 베어 저장소에 접근하여 Git 개체를 제공하고, Redis와 통신하여 GitLab이 처리할 작업을 Sidekiq에 제출합니다. GitLab Shell은 GitLab API를 쿼리하여 인증 및 접근을 확인합니다.

Gitaly는 GitLab Shell 및 GitLab 웹 앱에서의 Git 작업을 실행하며, GitLab 웹 앱에 Git 속성(예: 제목, 브랜치, 태그 또는 기타 메타데이터)을 가져오고 블롭(예: diff, 커밋 또는 파일)을 가져오도록 API를 제공합니다.

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

기존 구성 요소 조정 및 새로운 구성 요소 도입

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

공식 설치 방법과 비교할 때 몇 가지 주목할 만한 차이점은 다음과 같습니다:

  • 공식 리눅스 패키지는 서로 다른 서비스와 동일한 파일 시스템의 파일에 접근할 수 있습니다.

    공유 파일은 Kubernetes 플랫폼에서 실행되는 애플리케이션의 선택 사항이 아닙니다.

  • 공식 리눅스 패키지는 기본적으로 공유 구성 및 네트워크에 접근할 수 있는 서비스를 가지고 있습니다. 그러나 이는 Kubernetes에서 실행되는 서비스에 해당되지 않으며, 서비스는 완전한 격리 상태에서 실행되거나 특정 포트를 통해서만 접근이 가능할 수 있습니다.

즉, 서비스를 아키텍처할 때 서비스 간의 공유 상태를 신중하게 고려해야 하며, 동일한 파일에 접근해야 하는 서비스는 적절한 API를 통해 정보를 교환할 수 있어야 합니다. 가능하면, 이는 파일을 통해 수행되어서는 안 됩니다.

API 우선 철학으로 작성된 구성 요소는 두 가지 방법과 호환되므로 모든 새로운 기능과 서비스는 Kubernetes 호환성을 먼저 고려하여 작성해야 합니다.

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

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

간소화된 구성 요소 개요

이것은 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

모든 연결은 별도로 명시되지 않는 한 유닉스 소켓을 사용합니다.

구성 요소 다이어그램

%%{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 %% Gitaly는 개체 저장소에 리포지토리 백업을 수행할 수 있음. Gitaly --> 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 %% 끝 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 Elasticsearch --> Praefect %% Zoekt Zoekt --> Praefect 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 %% 끝 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](https://docs.gitlab.com/omnibus/) | [GitLab 환경 툴킷 (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) | [GitLab 차트](https://docs.gitlab.com/charts/) | [minikube 최소](https://docs.gitlab.com/charts/development/minikube/#deploying-gitlab-with-minimal-settings) | [GitLab.com](https://gitlab.com) | [소스](../install/installation.md) | [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) | [CE/EE](https://about.gitlab.com/install/ce-or-ee/) | |-------------------------------------------------------|---------------------------------------------------------------------|:--------------:|:--------------:|:------------:|:----------------:|:----------:|:------:|:---:|:-------:| | [인증서 관리](#certificate-management) | TLS 설정, Let's Encrypt | ✅ | ✅ | ✅ | ⚙ | ✅ | ⚙ | ⚙ | CE & EE | | [컨설](#consul) | 데이터베이스 노드 검색, 장애 조치 | ⚙ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | EE Only | | [데이터베이스 마이그레이션](#database-migrations) | 데이터베이스 마이그레이션 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE | | [엘라스틱서치](#elasticsearch) | GitLab 내에서 검색 개선 | ⤓ | ⚙ | ⤓ | ⤓ | ✅ | ⤓ | ⚙ | EE Only | | [기탈리](#gitaly) | GitLab에서 수행하는 모든 Git 호출을 처리하는 Git RPC 서비스 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE | | [GitLab Exporter](#gitlab-exporter) | 다양한 GitLab 메트릭 생성 | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE | | [GitLab Geo](#gitlab-geo) | 지리적으로 분산된 GitLab 사이트 | ⚙ | ⚙ | ❌ | ❌ | ✅ | ❌ | ⚙ | EE Only | | [GitLab Pages](#gitlab-pages) | 정적 웹사이트 호스팅 | ⚙ | ⚙ | ⚙ | ❌ | ✅ | ⚙ | ⚙ | CE & EE | | [GitLab 에이전트](#gitlab-agent) | 클라우드 네이티브 방식으로 Kubernetes 클러스터 통합 | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only | | [GitLab 자체 모니터링: Alertmanager](#alertmanager) | Prometheus에서 경고를 중복 제거하고 그룹화하며 라우팅 | ⚙ | ⚙ | ✅ | ⚙ | ✅ | ❌ | ❌ | CE & EE | | [GitLab 자체 모니터링: Grafana](#grafana) | 메트릭 대시보드 | ✅ | ✅ | ⚙ | ⤓ | ✅ | ❌ | ⚙ | CE & EE | | [GitLab 자체 모니터링: Jaeger](#jaeger) | GitLab 인스턴스에서 생성된 추적 보기 | ❌ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | CE & EE | | [GitLab 자체 모니터링: Prometheus](#prometheus) | 시계열 데이터베이스, 메트릭 수집 및 쿼리 서비스 | ✅ | ✅ | ✅ | ⚙ | ✅ | ❌ | ⚙ | CE & EE | | [GitLab 자체 모니터링: Sentry](#sentry) | GitLab 인스턴스에서 생성된 오류 추적 | ⤓ | ⤓ | ⤓ | ❌ | ✅ | ⤓ | ⤓ | CE & EE | | [GitLab 셸](#gitlab-shell) | SSH 세션에서 `git` 처리 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE | | [GitLab 워크호스](#gitlab-workhorse) | 스마트 리버스 프록시, 대용량 HTTP 요청 처리 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE | | [수신 이메일 (SMTP)](#inbound-email) | 문제를 업데이트하기 위해 메시지 수신 | ⤓ | ⤓ | ⚙ | ⤓ | ✅ | ⤓ | ⤓ | CE & EE | | [Jaeger 통합](#jaeger) | 배포된 앱을 위한 분산 추적 | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⚙ | EE Only | | [LDAP 인증](#ldap-authentication) | 중앙 집중식 LDAP 디렉터리에 대한 사용자 인증 | ⤓ | ⤓ | ⤓ | ⤓ | ❌ | ⤓ | ⚙ | CE & EE | | [Mattermost](#mattermost) | 오픈 소스 Slack 대안 | ⚙ | ⚙ | ⤓ | ⤓ | ⤓ | ❌ | ⚙ | CE & EE | | [MinIO](#minio) | 객체 저장 서비스 | ⤓ | ⤓ | ✅ | ✅ | ✅ | ❌ | ⚙ | CE & EE | | [NGINX](#nginx) | 요청을 적절한 구성 요소에 라우팅하고 SSL 종료 | ✅ | ✅ | ✅ | ⚙ | ✅ | ⤓ | ⚙ | CE & EE | | [노드 익스포터](#node-exporter) | 시스템 메트릭을 가진 Prometheus 엔드포인트 | ✅ | ✅ | N/A | N/A | ✅ | ❌ | ❌ | CE & EE | | [발신 이메일 (SMTP)](#outbound-email) | 사용자에게 이메일 메시지 발송 | ⤓ | ⤓ | ⚙ | ⤓ | ✅ | ⤓ | ⤓ | CE & EE | | [Patroni](#patroni) | PostgreSQL HA 클러스터 리더 선택 및 복제 관리 | ⚙ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | EE Only | | [PgBouncer Exporter](#pgbouncer-exporter) | PgBouncer 메트릭을 가진 Prometheus 엔드포인트 | ⚙ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | CE & EE | | [PgBouncer](#pgbouncer) | 데이터베이스 연결 풀링, 장애 조치 | ⚙ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | EE Only | | [PostgreSQL Exporter](#postgresql-exporter) | PostgreSQL 메트릭을 가진 Prometheus 엔드포인트 | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE | | [PostgreSQL](#postgresql) | 데이터베이스 | ✅ | ✅ | ✅ | ✅ | ✅ | ⤓ | ✅ | CE & EE | | [Praefect](#praefect) | Git 클라이언트와 Gitaly 저장소 노드 간의 투명한 프록시 | ✅ | ✅ | ⚙ | ❌ | ❌ | ⚙ | ✅ | CE & EE | | [Puma (GitLab Rails)](#puma) | 웹 인터페이스 및 API 요청 처리 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE | | [Redis Exporter](#redis-exporter) | Redis 메트릭을 가진 Prometheus 엔드포인트 | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE | | [Redis](#redis) | 캐싱 서비스 | ✅ | ✅ | ✅ | ✅ | ✅ | ⤓ | ✅ | CE & EE | | [Registry](#registry) | 컨테이너 레지스트리, 이미지 푸시 및 풀링 가능 | ⚙ | ⚙ | ✅ | ✅ | ✅ | ⤓ | ⚙ | CE & EE | | [러너](#gitlab-runner) | GitLab CI/CD 작업 실행 | ⤓ | ⤓ | ✅ | ⚙ | ✅ | ⚙ | ⚙ | CE & EE | | [Sentry 통합](#sentry) | 배포된 앱을 위한 오류 추적 | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | CE & EE | | [Sidekiq](#sidekiq) | 백그라운드 작업 프로세서 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | CE & EE | | [Token Revocation API](sec/token_revocation_api.md) | 유출된 비밀을 수신하고 취소 | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | EE Only | ### 구성 요소 세부정보 이 문서는 GitLab의 내부 구조와 그들이 어떻게 함께 작동하는지에 대해 이해하고자 하는 시스템 관리자 및 GitLab 지원 엔지니어를 위해 설계되었습니다. 배포될 때, GitLab은 아래 프로세스의 집합으로 간주되어야 합니다. 문제를 해결하거나 디버깅 할 때는 참조하는 구성 요소에 대해 가능한 한 구체적으로 설명해야 합니다. 이는 명확성을 높이고 혼란을 줄이는 데 도움이 됩니다. **계층** GitLab은 프로세스 관점에서 두 개의 계층으로 간주할 수 있습니다: - **모니터링**: 이 계층의 모든 것은 GitLab 애플리케이션을 제공하는 데 필요하지 않지만, 관리자에게 인프라와 전체 서비스가 수행하는 작업에 대한 통찰력을 제공합니다. - **코어**: GitLab 플랫폼 제공에 필수적인 모든 프로세스. 이러한 프로세스 중 하나라도 중단되면 GitLab 중단이 발생합니다. 코어 계층은 다음과 같이 추가로 나눌 수 있습니다: - **프로세서**: 이러한 프로세스는 실제로 작업을 수행하고 서비스를 제공하는 역할을 합니다. - **데이터**: 이러한 서비스는 GitLab 서비스에 대한 구조화된 데이터를 저장/공개합니다. #### Alertmanager - [프로젝트 페이지](https://github.com/prometheus/alertmanager/blob/master/README.md) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) - [차트](https://github.com/helm/charts/tree/master/stable/prometheus) - 계층: 모니터링 - 프로세스: `alertmanager` - GitLab.com: [GitLab.com 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) [Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/)는 Prometheus에서 제공하는 도구로서 _"Prometheus 서버와 같은 클라이언트 애플리케이션에서 전송된 알림을 처리합니다. 알림의 중복 제거, 그룹화 및 적절한 수신자 통합(예: 이메일, PagerDuty 또는 Opsgenie)으로 라우팅하는 역할을 합니다. 또한 알림의 무음 설정 및 억제를 처리합니다."_ 우리가 경고하는 내용에 대해서는 [이슈 #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740)를 읽어볼 수 있습니다. #### 인증서 관리 - 프로젝트 페이지: - [Omnibus](https://github.com/certbot/certbot/blob/master/README.rst) - [차트](https://github.com/jetstack/cert-manager/blob/master/README.md) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/ssl/index.html) - [차트](https://docs.gitlab.com/charts/installation/tls.html) - [소스](../install/installation.md#using-https) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/https.md) - 계층: 코어 서비스 (프로세서) - GitLab.com: [비밀 관리](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management) #### Consul - [프로젝트 페이지](https://github.com/hashicorp/consul/blob/master/README.md) - 구성: - [Omnibus](../administration/consul.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#postgresql) - 계층: 코어 서비스 (데이터) - GitLab.com: [Consul](../user/gitlab_com/index.md#consul) Consul은 서비스 검색 및 구성을 위한 도구입니다. Consul은 분산형, 고가용성 및 매우 확장 가능합니다. #### 데이터베이스 마이그레이션 - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/database.html#disabling-automatic-database-migration) - [차트](https://docs.gitlab.com/charts/charts/gitlab/migrations/) - [소스](../update/upgrading_from_source.md#10-install-libraries-migrations-etc) - 계층: 핵심 서비스 (데이터) #### Elasticsearch - [프로젝트 페이지](https://github.com/elastic/elasticsearch/) - 구성: - [Omnibus](../integration/advanced_search/elasticsearch.md) - [차트](../integration/advanced_search/elasticsearch.md) - [소스](../integration/advanced_search/elasticsearch.md) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/elasticsearch.md) - 계층: 핵심 서비스 (데이터) - GitLab.com: [GitLab.com에서 고급 검색 작동하기 (종료됨)](https://gitlab.com/groups/gitlab-org/-/epics/153) 에픽. Elasticsearch는 클라우드를 위해 제작된 분산 RESTful 검색 엔진입니다. #### Gitaly - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md) - 구성: - [Omnibus](../administration/gitaly/index.md) - [차트](https://docs.gitlab.com/charts/charts/gitlab/gitaly/) - [소스](../install/installation.md#install-gitaly) - 계층: 핵심 서비스 (데이터) - 프로세스: `gitaly` Gitaly는 GitLab이 설계한 서비스로, GitLab의 분산 배포(예: GitLab.com 또는 고가용성 배포)에서 Git 저장을 위한 NFS의 필요성을 제거합니다. 11.3.0부터 이 서비스는 GitLab에서 모든 Git 수준 접근을 처리합니다. 프로젝트에 대한 더 많은 정보는 [프로젝트의 README에서](https://gitlab.com/gitlab-org/gitaly) 읽을 수 있습니다. #### Praefect - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md) - 구성: - [Omnibus](../administration/gitaly/index.md) - [소스](../install/installation.md#install-gitaly) - 계층: 핵심 서비스 (데이터) - 프로세스: `praefect` Praefect는 각 Git 클라이언트와 Gitaly 간의 투명한 프록시로, 리포지토리 업데이트를 보조 노드로 복제하는 조정을 담당합니다. #### GitLab Geo - 구성: - [Omnibus](../administration/geo/setup/index.md) - [차트](https://docs.gitlab.com/charts/advanced/geo/) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md) - 계층: 핵심 서비스 (처리기) Geo는 주요 GitLab 인스턴스의 하나 이상의 읽기 전용 미러를 제공하여 분산 팀의 개발 속도를 높이는 데 도움을 주기 위해 구축된 프리미엄 기능입니다. 이 미러(Geo 보조 사이트)는 대규모 리포지토리와 프로젝트를 복제하거나 가져오는 시간을 줄이거나 재해 복구 솔루션의 일부가 될 수 있습니다. #### GitLab Exporter - [프로젝트 페이지](https://gitlab.com/gitlab-org/ruby/gems/gitlab-exporter) - 구성: - [Omnibus](../administration/monitoring/prometheus/gitlab_exporter.md) - [차트](https://docs.gitlab.com/charts/charts/gitlab/gitlab-exporter/index.html) - 계층: 모니터링 - 프로세스: `gitlab-exporter` - GitLab.com: [GitLab.com 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) GitLab Exporter는 GitLab 애플리케이션 내부에 대한 메트릭을 Prometheus로 내보낼 수 있도록 설계된 내부 프로세스입니다. 프로젝트에 대한 더 많은 정보는 [프로젝트의 README에서](https://gitlab.com/gitlab-org/ruby/gems/gitlab-exporter) 읽을 수 있습니다. #### GitLab 에이전트 - [프로젝트 페이지](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) - [차트](https://docs.gitlab.com/charts/charts/gitlab/kas/index.html) [GitLab 에이전트](../user/clusters/agent/index.md)는 GitLab과 Kubernetes 통합 작업을 안전하고 클라우드 네이티브 방식으로 해결하기 위한 클러스터 내의 능동적인 구성 요소입니다. 이를 사용하여 배포를 Kubernetes 클러스터에 동기화할 수 있습니다. #### GitLab Pages - 구성: - [Omnibus](../administration/pages/index.md) - [차트](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/37) - [소스](../install/installation.md#install-gitlab-pages) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/pages.md) - 레이어: 핵심 서비스(프로세서) - GitLab.com: [GitLab Pages](../user/gitlab_com/index.md#gitlab-pages) GitLab Pages는 GitLab의 리포지토리에서 정적 웹사이트를 직접 게시할 수 있는 기능입니다. 이를 개인 또는 비즈니스 웹사이트(예: 포트폴리오, 문서, 선언문 및 비즈니스 프레젠테이션)로 사용할 수 있습니다. 또한 콘텐츠에 대해 어떤 라이센스도 부여할 수 있습니다. #### GitLab Runner - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitlab-runner/blob/main/README.md) - 구성: - [Omnibus](https://docs.gitlab.com/runner/) - [차트](https://docs.gitlab.com/runner/install/kubernetes.html) - [소스](https://docs.gitlab.com/runner/) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/runner.md) - 레이어: 핵심 서비스(프로세서) - GitLab.com: [러너](../ci/runners/index.md) GitLab Runner는 작업을 실행하고 결과를 GitLab에 전송합니다. GitLab CI/CD는 GitLab에 포함된 오픈 소스 지속적 통합 서비스로, 테스트를 조정합니다. 이 프로젝트의 이전 이름은 `GitLab CI Multi Runner`였으나 이제부터는 `GitLab Runner` (CI 없이)로 사용해 주세요. #### GitLab Shell - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitlab-shell/) - [문서](gitlab_shell/index.md) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) - [차트](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/) - [소스](../install/installation.md#install-gitlab-shell) - [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example) - 레이어: 핵심 서비스(프로세서) [GitLab Shell](gitlab_shell/index.md)은 GitLab에서 SSH 기반 `git` 세션을 처리하도록 설계된 프로그램으로, 허가된 키 목록을 수정합니다. GitLab Shell은 유닉스 셸이나 Bash 또는 Zsh의 대체물이 아닙니다. #### GitLab Workhorse - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/workhorse/index.md) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) - [차트](https://docs.gitlab.com/charts/charts/gitlab/webservice/) - [소스](../install/installation.md#install-gitlab-workhorse) - 레이어: 핵심 서비스(프로세서) - 프로세스: `gitlab-workhorse` [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/workhorse)는 GitLab에서 Puma의 부담을 줄이기 위해 설계된 프로그램입니다. [개발의 역사적 이유](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/)에 대해 더 읽어볼 수 있습니다. GitLab 전체의 속도를 높이는 스마트 리버스 프록시로 작동하도록 설계되었습니다. #### Grafana - [프로젝트 페이지](https://github.com/grafana/grafana/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/performance/grafana_configuration.md) - [차트](https://docs.gitlab.com/charts/charts/globals#configure-grafana-integration) - 레이어: 모니터링 - GitLab.com: [GitLab triage Grafana 대시보드](https://dashboards.gitlab.com/d/RZmbBr7mk/gitlab-triage?refresh=30s) Grafana는 Graphite, Elasticsearch, OpenTSDB, Prometheus 및 InfluxDB를 위한 오픈 소스, 풍부한 기능의 메트릭 대시보드 및 그래프 편집기입니다. #### Jaeger - [프로젝트 페이지](https://github.com/jaegertracing/jaeger/blob/master/README.md) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4104) - [차트](https://docs.gitlab.com/charts/charts/globals#tracing) - [출처](../development/distributed_tracing.md#enabling-distributed-tracing) - [GDK](../development/distributed_tracing.md#using-jaeger-in-the-gitlab-development-kit) - 레이어: 모니터링 - GitLab.com: [GitLab 인스턴스에 대한 추적 활성화를 위한 구성](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4104) 문제. Jaeger는 Dapper 및 OpenZipkin에서 영감을 받은 분산 추적 시스템입니다. 마이크로서비스 기반 분산 시스템을 모니터링하는 데 사용할 수 있습니다. #### Logrotate - [프로젝트 페이지](https://github.com/logrotate/logrotate/blob/master/README.md) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/logs.html#logrotate) - 레이어: 코어 서비스 - 프로세스: `logrotate` GitLab은 모두 로그를 남기는 많은 서비스로 구성됩니다. 우리는 책임감 있게 로그를 기록하기 위해 자체 Logrotate를 번들로 만듭니다. 이는 일반적인 오픈 소스 제공의 패키지 버전입니다. #### Mattermost - [프로젝트 페이지](https://github.com/mattermost/mattermost-server/blob/master/README.md) - 구성: - [Omnibus](../integration/mattermost/index.md) - [차트](https://docs.mattermost.com/install/install-mmte-helm-gitlab-helm.html) - 레이어: 코어 서비스 (프로세서) - GitLab.com: [Mattermost](../user/project/integrations/mattermost.md) Mattermost는 <https://mattermost.com>에서 제공하는 오픈 소스, 개인 클라우드, Slack 대안입니다. #### MinIO - [프로젝트 페이지](https://github.com/minio/minio/blob/master/README.md) - 구성: - [Omnibus](https://min.io/download) - [차트](https://docs.gitlab.com/charts/charts/minio/) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/object_storage.md) - 레이어: 코어 서비스 (데이터) - GitLab.com: [스토리지 아키텍처](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) MinIO는 GNU AGPL v3.0 라이선스 하에 배포되는 객체 저장 서버입니다. Amazon S3 클라우드 스토리지 서비스와 호환됩니다. 사진, 비디오, 로그 파일, 백업 및 컨테이너/VM 이미지와 같은 비구조적 데이터를 저장하는 데 가장 적합합니다. 객체의 크기는 몇 KB에서 최대 5TB까지 가능합니다. #### NGINX - 프로젝트 페이지: - [Omnibus](https://github.com/nginx/nginx) - [차트](https://github.com/kubernetes/ingress-nginx/blob/master/README.md) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/) - [차트](https://docs.gitlab.com/charts/charts/nginx/) - [소스](../install/installation.md#10-nginx) - 레이어: 코어 서비스 (프로세서) - 프로세스: `nginx` NGINX는 모든 HTTP 요청을 위한 Ingress 포트를 가지고 있으며, 이를 GitLab 내의 적절한 서브 시스템으로 라우팅합니다. 우리는 인기 있는 오픈 소스 웹 서버의 수정되지 않은 버전을 번들로 제공합니다. #### Node Exporter - [프로젝트 페이지](https://github.com/prometheus/node_exporter/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/prometheus/node_exporter.md) - [차트](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1332) - 레이어: 모니터링 - 프로세스: `node-exporter` - GitLab.com: [GitLab.com 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) [Node Exporter](https://github.com/prometheus/node_exporter)는 기본 머신의 메트릭을 제공하는 Prometheus 도구입니다 (CPU/Disk/Load를 생각해보세요). 이는 Prometheus 프로젝트의 일반적인 오픈 소스 제공물을 패키징한 버전입니다. #### Patroni - [프로젝트 페이지](https://github.com/zalando/patroni) - 구성: - [Omnibus](../administration/postgresql/replication_and_failover.md#patroni) - 레이어: 코어 서비스 (데이터) - 프로세스: `patroni` - GitLab.com: [데이터베이스 아키텍처](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#database-architecture) #### PgBouncer - [프로젝트 페이지](https://github.com/pgbouncer/pgbouncer/blob/master/README.md) - 구성: - [Omnibus](../administration/postgresql/pgbouncer.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#postgresql) - 레이어: 코어 서비스 (데이터) - GitLab.com: [데이터베이스 아키텍처](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#database-architecture) PostgreSQL을 위한 경량 연결 풀러입니다. #### PgBouncer Exporter - [프로젝트 페이지](https://github.com/prometheus-community/pgbouncer_exporter/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/prometheus/pgbouncer_exporter.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#postgresql) - 레이어: 모니터링 - GitLab.com: [GitLab.com 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) PgBouncer를 위한 Prometheus 익스포터입니다. 9127/metrics에서 메트릭을 내보냅니다. #### PostgreSQL - [프로젝트 페이지](https://github.com/postgres/postgres/) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/database.html) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#postgresql) - [소스](../install/installation.md#7-database) - 레이어: 코어 서비스 (데이터) - 프로세스: `postgresql` - GitLab.com: [PostgreSQL](https://handbook.gitlab.com/handbook/engineering/infrastructure/database/) GitLab은 애플리케이션 메타 데이터 및 사용자 정보를 저장하기 위해 인기 있는 데이터베이스를 패키징합니다. #### PostgreSQL Exporter - [프로젝트 페이지](https://github.com/wrouesnel/postgres_exporter/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/prometheus/postgres_exporter.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#postgresql) - 레이어: 모니터링 - 프로세스: `postgres-exporter` - GitLab.com: [GitLab.com의 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) [`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter)는 PostgreSQL에 대한 데이터를 Prometheus에 제공하여 Grafana 대시보드에서 사용할 수 있는 커뮤니티 제공 Prometheus exporter입니다. #### Prometheus - [프로젝트 페이지](https://github.com/prometheus/prometheus/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/prometheus/index.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#prometheus) - 레이어: 모니터링 - 프로세스: `prometheus` - GitLab.com: [Prometheus](../user/gitlab_com/index.md#prometheus) Prometheus는 GitLab 관리자가 GitLab 서비스를 제공하는 데 사용되는 개별 프로세스에 대한 메트릭을 노출하는 데 도움을 주는 시계열 도구입니다. #### Redis - [프로젝트 페이지](https://github.com/antirez/redis/blob/unstable/README.md) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/redis.html) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#redis) - [소스](../install/installation.md#8-redis) - 레이어: 핵심 서비스 (데이터) - 프로세스: `redis` Redis는 다음을 저장하는 장소로 포장되어 있습니다: - 세션 데이터 - 임시 캐시 정보 - 백그라운드 작업 큐 GitLab이 Redis를 사용하는 방법에 대한 자세한 내용은 [Redis 가이드라인](redis.md)을 참조하세요. #### Redis Exporter - [프로젝트 페이지](https://github.com/oliver006/redis_exporter/blob/master/README.md) - 구성: - [Omnibus](../administration/monitoring/prometheus/redis_exporter.md) - [차트](https://docs.gitlab.com/charts/installation/deployment.html#redis) - 레이어: 모니터링 - 프로세스: `redis-exporter` - GitLab.com: [GitLab.com의 모니터링](https://handbook.gitlab.com/handbook/engineering/monitoring/) [Redis Exporter](https://github.com/oliver006/redis_exporter)는 Redis 프로세스에 대한 특정 메트릭을 Prometheus에 제공하여 이러한 메트릭을 Grafana에서 그래프로 표시할 수 있도록 설계되었습니다. #### Registry - [프로젝트 페이지](https://gitlab.com/gitlab-org/container-registry) - 구성: - [Omnibus](../administration/packages/container_registry.md) - [차트](https://docs.gitlab.com/charts/charts/registry/) - [소스](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads) - [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/registry.md) - 레이어: 핵심 서비스 (프로세서) - GitLab.com: [GitLab 컨테이너 레지스트리](../user/packages/container_registry/build_and_push_images.md#use-gitlab-cicd) 레지스트리는 사용자가 자신의 Docker 이미지를 저장하는 데 사용하는 것입니다. 번들된 레지스트리는 로드 밸런서로 NGINX를 사용하고 인증 관리자로 GitLab을 사용합니다. 클라이언트가 레지스트리에서 이미지를 풀 또는 푸시 하도록 요청할 때마다 인증 토큰을 가져오는 위치에 대한 세부정보가 포함된 헤더와 함께 `401` 응답을 반환합니다. 이 경우 GitLab 인스턴스입니다. 클라이언트는 then GitLab에 풀 또는 푸시 인증 토큰을 요청하고 원래 요청을 다시 레지스트리에 요청합니다. 자세한 내용은 [토큰 인증](https://distribution.github.io/distribution/spec/auth/token/)을 참조하세요. 외부 레지스트리도 GitLab을 인증 엔드포인트로 사용하도록 구성할 수 있습니다. #### Sentry - [프로젝트 페이지](https://github.com/getsentry/sentry/) - 구성: - [Omnibus](https://docs.gitlab.com/omnibus/settings/configuration.html#error-reporting-and-logging-with-sentry) - [차트](https://docs.gitlab.com/charts/charts/globals#sentry-settings) - [소스](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) - 레이어: 모니터링 - GitLab.com: [Sentry 검색](https://handbook.gitlab.com/handbook/support/workflows/500_errors/#searching-sentry) Sentry는 기본적으로 충돌을 실시간으로 모니터링하고 수정하는 데 도움을 주는 서비스입니다. 서버는 Python으로 되어 있지만, 모든 언어와의 애플리케이션에서 이벤트를 전송하기 위한 완전한 API를 포함하고 있습니다. 배포된 앱을 모니터링하려면 [Sentry 통합 문서](../operations/error_tracking.md)를 참조하세요. #### Sidekiq - [프로젝트 페이지](https://github.com/mperham/sidekiq/blob/master/README.md) - 구성: - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template) - [차트](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/) - [minikube 최소형](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html) - [소스](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) - 레이어: 핵심 서비스 (프로세서) - 프로세스: `sidekiq` - GitLab.com: [Sidekiq](../user/gitlab_com/index.md#sidekiq) Sidekiq는 Redis 큐에서 작업을 가져와 처리하는 Ruby 배경 작업 프로세서입니다. 배경 작업은 GitLab이 작업을 배경으로 이동시켜 더 빠른 요청/응답 사이클을 제공할 수 있도록 합니다. #### Puma GitLab 13.0부터 Puma는 기본 웹 서버입니다. - [프로젝트 페이지](https://gitlab.com/gitlab-org/gitlab/-/blob/master/README.md) - 구성: - [Omnibus](../administration/operations/puma.md) - [차트](https://docs.gitlab.com/charts/charts/gitlab/webservice/) - [소스](../install/installation.md#configure-it) - [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example) - 레이어: 핵심 서비스 (프로세서) - 프로세스: `puma` - GitLab.com: [Puma](../user/gitlab_com/index.md#puma) [Puma](https://puma.io/)는 GitLab에서 사용자-facing 기능을 제공하는 핵심 Rails 애플리케이션을 실행하는 데 사용되는 Ruby 애플리케이션 서버입니다. 종종 이는 GitLab 버전에 따라 `bundle` 또는 `config.ru`로 프로세스 출력에 표시됩니다. #### LDAP 인증 - 구성: - [Omnibus](../administration/auth/ldap/index.md) - [차트](https://docs.gitlab.com/charts/charts/globals.html#ldap) - [소스](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) - 레이어: 핵심 서비스 (프로세서) - 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) - [소스](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) - 레이어: 코어 서비스(프로세서) - 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) - [소스](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) - 레이어: 코어 서비스(프로세서) - GitLab.com: [메일 구성](../user/gitlab_com/index.md#mail-configuration) ## 요청 유형에 따른 GitLab GitLab은 최종 사용자가 서비스를 액세스할 수 있는 두 가지 "인터페이스"를 제공합니다: - 웹 HTTP 요청(사용자 인터페이스/API 보기) - Git HTTP/SSH 요청(Git 데이터 푸시/풀) 일부 프로세스는 두 가지 모두에서 사용되고 다른 일부는 특정 요청 유형에만 사용되므로 구분하는 것이 중요합니다. ### GitLab 웹 HTTP 요청 사이클 HTTP 엔드포인트에 요청을 할 때(예: `/users/sign_in`) 요청은 GitLab 서비스 내에서 다음 경로를 따릅니다: - NGINX - 우리의 첫 번째 역방향 프록시 역할을 합니다. - GitLab Workhorse - 이 요청이 Rails 애플리케이션으로 가야 하는지 아니면 Puma의 부하를 줄이기 위해 다른 곳으로 가야 하는지를 결정합니다. - Puma - 이것은 웹 요청이므로 애플리케이션에 액세스해야 하며, Puma로 라우팅됩니다. - PostgreSQL/Gitaly/Redis - 요청 유형에 따라 데이터를 저장하거나 검색하기 위해 이 서비스에 접근할 수 있습니다. ### GitLab Git 요청 사이클 아래에서는 HTTP와 SSH Git 요청이 따르는 다양한 경로를 설명합니다. 웹 요청 사이클과 일부 중복이 있지만 몇 가지 차이점도 있습니다. ### 웹 요청 (80/443) HTTP를 통한 Git 작업은 [Git 문서](https://git-scm.com/docs/http-protocol)에서 설명된 무상태 "스마트" 프로토콜을 사용하지만 이러한 작업을 처리하는 책임은 여러 GitLab 구성 요소에 분산되어 있습니다. 다음은 `git fetch`에 대한 시퀀스 다이어그램입니다. 모든 요청은 NGINX와 기타 HTTP 로드 밸런서를 통과하지만, 그에 의해 어떤 방식으로도 변환되지 않습니다. 모든 경로는 `/namespace/project.git` URL에 상대적으로 제시됩니다. ```mermaid 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: 인증 확인 Rails-->>-Workhorse: Gitlab::Workhorse.git_http_ok Workhorse->>+Gitaly: SmartHTTPService.InfoRefsUploadPack 요청 Gitaly->>+Git on server: git upload-pack --stateless-rpc --advertise-refs Git on server-->>-Gitaly: git upload-pack 응답 Gitaly-->>-Workhorse: SmartHTTPService.InfoRefsUploadPack 응답 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: 인증 확인 Rails-->>-Workhorse: Gitlab::Workhorse.git_http_ok Workhorse->>+Gitaly: SmartHTTPService.PostUploadPack 요청 Gitaly->>+Git on server: git upload-pack --stateless-rpc Git on server-->>-Gitaly: git upload-pack 응답 Gitaly-->>-Workhorse: SmartHTTPService.PostUploadPack 응답 Workhorse-->>-Git on client: 200 OK

시퀀스는 git push에 대해서도 유사하지만, git-receive-pack이 대신 사용됩니다.

SSH 요청 (22)

SSH를 통한 Git 작업은 Git 문서에 설명된 상태 저장 프로토콜을 사용할 수 있지만, 이를 처리하는 책임은 여러 GitLab 구성 요소에 나눠져 있습니다.

GitLab 구성 요소는 SSH를 직접적으로 사용하지 않습니다. 모든 SSH 연결은 클라이언트 머신의 Git과 SSH 서버 간에 이루어지며, SSH 서버가 연결을 종료합니다. SSH 서버에게 모든 연결은 git 사용자로 인증됩니다. GitLab 사용자는 클라이언트가 제시한 SSH 키에 따라 구분됩니다.

여기 git fetch에 대한 시퀀스 다이어그램이 있습니다. Fast SSH key lookup이 활성화되어 있다고 가정합니다. 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: 키 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: 인증 확인 Rails-->>-GitLab Shell: 200 OK, { gitaly: ... } GitLab Shell->>+Gitaly: SSHService.SSHUploadPack 요청 Gitaly->>+Git on server: git upload-pack 요청 Note over Git on client,Git on server: Git 클라이언트와 서버 간의 양방향 통신 Git on server-->>-Gitaly: git upload-pack 응답 Gitaly -->>-GitLab Shell: SSHService.SSHUploadPack 응답 GitLab Shell-->>-SSH server: gitlab-shell upload-pack 응답 SSH server-->>-Git on client: ssh git fetch-pack 응답

git push 작업은 git upload-pack 대신 git receive-pack이 사용된다는 점을 제외하면 매우 유사합니다.

빠른 SSH 키 조회가 활성화되지 않은 경우, SSH 서버는 ~git/.ssh/authorized_keys 파일을 읽어 주어진 SSH 세션에 대해 실행할 명령을 결정합니다. 이는 사용자가 SSH 키를 수정할 때마다 실행되도록 Rails에서 AuthorizedKeysWorker에 의해 업데이트됩니다.

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

GitLab Shell은 Gitaly와 관련이 없는 몇 가지 작업도 수행합니다. 예를 들어, 이중 인증 코드 리셋과 같은 작업이 이에 해당합니다. 이러한 작업은 동일한 방식으로 처리되지만, Gitaly로의 왕복이 없고 Rails가 내부 API 호출의 일환으로 작업을 수행하며, GitLab Shell이 사용자의 응답을 직접 스트리밍합니다.

시스템 레이아웃

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

GitLab은 주로 /home/git 사용자 홈 디렉토리에 git 사용자로 설치됩니다. 홈 디렉토리 내에는 GitLab 서버 소프트웨어와 리포지토리가 있으며(리포지토리 위치는 구성 가능), 여기서 귀하의 리포지토리를 찾을 수 있습니다.

베어 리포지토리는 /home/git/repositories에 위치합니다. GitLab은 Ruby on Rails 애플리케이션이므로 내부 작업의 세부 사항은 Ruby on Rails 애플리케이션이 작동하는 방식을 연구하여 배울 수 있습니다.

SSH를 통해 리포지토리를 제공하기 위해 /home/git/gitlab-shell에 설치된 GitLab Shell이라는 추가 애플리케이션이 있습니다.

설치 폴더 요약

요약하자면, git 사용자 홈 디렉토리의 디렉토리 구조는 다음과 같습니다.

프로세스 

ps aux | grep '^git'

GitLab은 운영을 위해 여러 구성 요소가 필요합니다. 지속적인 데이터베이스(PostgreSQL)와 Redis 데이터베이스가 필요하며, Apache httpd 또는 NGINX를 사용하여 Puma에 proxypass를 설정합니다. 이러한 모든 구성 요소는 GitLab과 다른 시스템 사용자로 실행되어야 합니다(예: postgres, redis, www-data, git이 아님).

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
Usage: service gitlab {start|stop|restart|reload|status}

Redis (키-값 저장소/비지속적 데이터베이스):

/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:

  • /var/log/auth.log 인증 로그 (Ubuntu에서).
  • /var/log/secure 인증 로그 (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 Shell에는 /home/git/gitlab-shell/config.yml에 구성 파일이 있습니다.

GitLab Rails에 새 설정 추가하기

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

  • 여러 서비스에 걸쳐 애플리케이션이 어떻게 연결되는지에 대한 정보. 예를 들어, Gitaly 주소, Redis 주소, Postgres 주소 및 Consul 주소.
  • 분산 추적 구성 및 일부 관측 가능성 구성. 예를 들어, 히스토그램 버킷 경계.
  • Rails 초기화 중에 구성해야 할 모든 것, Postgres 연결이 설정되기 전에 필요할 수 있습니다.

대부분의 다른 설정은 애플리케이션 자체인 ApplicationSetting에 배치하는 것이 더 좋습니다. UI에서 설정을 관리하는 것이 구성 파일을 관리하는 것보다 일반적으로 더 나은 사용자 경험을 제공합니다. 개발 비용과 관련하여, gitlab.yml을 수정하는 것이 종종 더 빠른 반복처럼 보이지만, 아래의 모든 배포 방법을 고려할 때 이는 불리한 거래일 수 있습니다.

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

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

GitLab.com

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

AI 아키텍처

AI 기반 기능을 활성화하기 위한 SaaS 모델 게이트웨이가 제공됩니다.