GitLab 아키텍처 개요

소프트웨어 제공

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

GitLab은 다양한 구독으로 이용할 수 있습니다.

GitLab의 새로운 버전은 안정적인 브랜치에서 출시되며, main 브랜치는 개발 초기 단계에 사용됩니다.

자세한 정보는 GitLab 릴리스 프로세스를 참조하십시오.

두 배포 모두 추가 컴포넌트가 필요합니다. 이러한 컴포넌트에 대한 설명은 컴포넌트 세부 정보 섹션에 나와 있으며, 각각의 리포지터리가 있습니다. 각 종속 컴포넌트의 새 버전은 일반적으로 태그로 표시되지만, GitLab 코드베이스의 main 브랜치를 유지하면 이러한 컴포넌트의 최신 안정적 버전을 얻을 수 있습니다. 신규 버전은 일반적으로 GitLab 릴리스와 함께 출시되며 비공식 보안 업데이트의 예외를 제외하고는 이와 동일한 시기에 출시됩니다.

컴포넌트

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

전형적인 설치는 NGINX 또는 Apache를 사용하여 GitLab Workhorse를 프록시로 사용하고 Puma 애플리케이션 서버로 이동합니다. GitLab은 웹 페이지와 GitLab API를 Puma 애플리케이션 서버를 사용하여 제공합니다. 그리고 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 섹션에서 정의된 위치에서 SSH 키를 관리합니다. 해당 위치의 파일은 절대로 매뉴얼으로 편집해서는 안됩니다. GitLab Shell은 작업 정보 처리를 위해 Gitaly를 통해 베어 리포지터리에 액세스하며, GitLab이 처리할 작업을 Sidekiq에 제출하기 위해 Redis와 통신합니다. GitLab Shell은 권한 및 액세스를 결정하기 위해 GitLab API에 쿼리를 수행합니다.

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

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

기존 컴포넌트의 적응 및 새 컴포넌트 도입

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

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

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

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

API-first 철학을 고려하여 작성된 컴포넌트는 두 방법 모두와 호환되므로, 모든 새로운 기능과 서비스는 먼저 Kubernetes 호환성을 고려하여 작성되어야 합니다.

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

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

간소화된 컴포넌트 개요

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

전체 아키텍처 다이어그램은 아래의 컴포넌트 다이어그램에서 제공됩니다.

간소화된 컴포넌트 개요

컴포넌트 설명

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

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

컴포넌트 디렉터리

컴포넌트 설명 Omnibus GitLab GitLab 환경 도구킷 (GET) GitLab 차트 minikube 최소한 GitLab.com 소스 GDK CE/EE
인증서 관리 TLS 설정, Let’s Encrypt ✅ ✅ ✅ ⚙ ✅ ⚙ ⚙ CE & EE
Consul Database 노드 검색, 장애 조치 ⚙ ✅ ❌ ❌ ✅ ❌ ❌ EE Only
데이터베이스 마이그레이션 데이터베이스 마이그레이션 ✅ ✅ ✅ ✅ ✅ ⚙ ✅ CE & EE
Elasticsearch GitLab 내에서의 검색 개선 ⤓ ⚙ ⤓ ⤓ ✅ ⤓ ⚙ EE Only
Gitaly GitLab에서 수행된 모든 Git 호출을 처리하는 Git RPC 서비스 ✅ ✅ ✅ ✅ ✅ ⚙ ✅ CE & EE
GitLab Exporter 다양한 GitLab 메트릭 생성 ✅ ✅ ✅ ✅ ✅ ❌ ❌ CE & EE
GitLab Geo 지리적으로 분산된 GitLab 사이트 ⚙ ⚙ ❌ ❌ ✅ ❌ ⚙ EE Only
GitLab Pages 정적 웹 사이트 호스팅 ⚙ ⚙ ❌ ❌ ✅ ⚙ ⚙ CE & EE
GitLab 에이전트 클라우드 네이티브 방식으로 Kubernetes 클러스터를 통합함 ⚙ ⚙ ⚙ ❌ ❌ ⤓ ⚙ EE Only
GitLab 자가 모니터링: Alertmanager 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 유출된 비밀을 수신하고 취소하는 API ❌ ❌ ❌ ❌ ✅ ❌ ❌ EE Only

컴포넌트 세부 정보

이 문서는 시스템 관리자 및 GitLab 지원 엔지니어가 GitLab 내부 구조에 대해 더 잘 이해하고 서로 어떻게 작동하는지 이해하고자 하는 경우에 소비하도록 설계되었습니다.

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

계층

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

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

Alertmanager

Alert manager는 “Prometheus 서버와 같은 클라이언트 애플리케이션에서 전송된 경고를 처리합니다. 이는 중복 제거, 그룹화 및 이를 올바른 수신기 통합(예: 이메일, PagerDuty 또는 Opsgenie)으로 경로 지정합니다. 또한 경고의 알림 기능과 억제를 처리합니다.” 자세한 내용은 이슈 #45740에서 확인할 수 있습니다.

인증서 관리

Consul

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

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

Elasticsearch

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

Gitaly

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

Praefect

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

GitLab Geo

GitLab Exporter

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

GitLab 에이전트

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

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

GitLab Pages

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

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

GitLab Runner

GitLab Runner는 작업을 실행하고 결과를 GitLab으로 보내는 프로세스입니다.

GitLab과 함께 제공되는 오픈 소스 연속적 통합 서비스인 GitLab CI/CD에서 테스트를 조정합니다. 이 프로젝트의 이전 이름은 GitLab CI Multi Runner였지만 이제는 반드시 GitLab Runner (CI 없이)를 사용하세요.

GitLab Shell

GitLab Shell은 GitLab에서 SSH 기반의 git 세션을 처리하고 승인된 키 디렉터리을 수정하기 위해 설계된 프로그램입니다. GitLab Shell은 Unix 쉘이나 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부터 최대 5TB까지 범위가 있을 수 있습니다.

NGINX

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

Node Exporter

Node Exporter는 기계의 지표 (CPU/디스크/로드 등)를 제공하는 Prometheus 도구입니다. 이는 Prometheus 프로젝트의 흔히 사용되는 오픈 소스 오퍼링의 패키지 버전입니다.

Patroni

PgBouncer

PostgreSQL Lightweight 연결 풀러입니다.

PgBouncer Exporter

PgBouncer를 위한 Prometheus 익스포터로, 9127/metrics에서 메트릭을 내보냅니다.

PostgreSQL

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

PostgreSQL Exporter

postgres_exporter는 PostgreSQL에 대한 데이터를 Prometheus로 내보내기 위해 사용되는 커뮤니티 제공 프로메테우스 익스포터입니다. 그래펀다 대시보드에서 사용됩니다.

프로메테우스

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

레디스

레디스는 다음을 저장하기 위한 패키지입니다:

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

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

레디스 익스포터

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

레지스트리

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

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

센트리

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

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

Sidekiq

Sidekiq는 루비 백그라운드 작업 프로세서로, 레디스 대기열에서 작업을 추출하고 처리합니다. 백그라운드 작업을 통해 GitLab은 작업을 백그라운드로 이동하여 더 빠른 요청/응답 주기를 제공할 수 있게 됩니다.

푸마

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

Puma는 사용자가 마주하는 기능을 제공하는 코어 Rails 애플리케이션을 실행하는 데 사용되는 루비 애플리케이션 서버입니다. GitLab 버전에 따라 프로세스 출력에는 bundle 또는 config.ru가 표시됩니다.

LDAP 인증

발신 이메일

수신 이메일

요청 유형별 GitLab

GitLab은 최종 사용자가 서비스에 액세스하는 데 사용하는 두 “인터페이스”를 제공합니다:

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

몇 가지 프로세스가 두 가지 모두에서 사용되는 반면 다른 프로세스는 특정 요청 유형에만 사용됨을 이해하는 것이 중요합니다.

GitLab 웹 HTTP 요청 주기

HTTP 엔드포인트로 요청을 보낼 때 (예: /사용자/로그인 고려), 요청은 다음 경로를 통해 GitLab 서비스를 거칩니다:

  • NGINX - 첫 번째 라인 역방향 프록시로 작동합니다.
  • GitLab Workhorse - 부하를 줄이기 위해 Rails 애플리케이션 또는 다른 곳으로 전달해야 하는지 여부를 결정합니다.
  • Puma - 웹 요청이기 때문에 애플리케이션에 액세스해야 하므로 Puma로 라우팅됩니다.
  • PostgreSQL/Gitaly/Redis - 요청 유형에 따라 이러한 서비스를 통해 데이터를 저장하거나 검색할 수 있습니다.

GitLab Git 요청 주기

HTTP 대 SSH Git 요청이 차이점을 보이는 다양한 경로에 대해 설명합니다. 웹 요청 주기와 일부 중복이 있지만 몇 가지 차이점도 있습니다.

시스템 레이아웃

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

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

처리 큐를 위해 ps aux | grep '^git' 명령을 사용하십시오.

GitLab에는 여러 컴포넌트가 있습니다. 지속적인 데이터베이스(PostgreSQL)와 Redis 데이터베이스가 필요하며, Apache httpd 또는 NGINX를 사용하여 Puma를 proxypass하는 등 각 컴포넌트는 GitLab과 다른 시스템 사용자로 실행해야 합니다(예: 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
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:

  • 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 연결이 설정된 후인 경우에도 Rails 초기화 중에 구성해야 하는 모든 내용.

기타 많은 설정은 일반적으로 구성 파일보다 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

Ubuntu에서는 일반적으로 sudo 명령들이 작동하지만, RHEL에서는 항상 작동하는 것은 아닙니다.

GitLab.com

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

AI 아키텍처

AI 아키텍처에는 AI 기능을 활성화하는 SaaS 모델 게이트웨이가 제공됩니다.