GitLab アーキテクチャの概要

ソフトウェア配信

GitLabには、オープンソースのCommunity Edition (CE)と、オープンコアのEnterprise Edition (EE)の2つのディストリビューションがあります。GitLabは、異なるサブスクリプションで利用できます。

GitLabの新しいバージョンは安定版ブランチでリリースされ、masterブランチは最先端の開発者のためのものです。

詳しくはGitLabリリースプロセスをご覧ください。

EEとCEはどちらもGitLab ShellとGitalyと呼ばれるアドオンコンポーネントを必要とします。 これらのコンポーネントはそれぞれGitLab Shellと Gitalyリポジトリから入手できます。 新しいバージョンは通常タグで表示されますが、masterブランチに留まることで最新の安定版を入手できます。 新しいリリースは、クリティカルとみなされる非公式のセキュリティアップデートを除いて、一般的にGitLab CEのリリースと同じ時期に行われます。

コンポーネント

GitLabの典型的なインストール環境はGNU/Linuxで、UnicornウェブサーバーをプロキシパスするウェブフロントエンドとしてNGINXかApacheを使います。 デフォルトでは、Unicornとフロントエンド間の通信はUnixドメインソケット経由ですが、TCP経由のリクエスト転送もサポートされています。 ウェブフロントエンドは、静的ページ、アップロード（アバター画像や添付ファイルなど）、コンパイル済みアセットを提供するために、Unicornサーバーをバイパスして/home/git/gitlab/public 。 GitLabは、Unicornウェブサーバーを使ってウェブページとGitLab APIを提供します。 ジョブキューとしてSidekiqを使い、ジョブ情報、メタデータ、受信ジョブのための非永続データベースバックエンドとしてRedisを使います。

GitLabHelmチャートを使ってKubernetes上にGitLabをデプロイすることもサポートしています。

GitLabウェブアプリは、永続的なデータベース情報（ユーザー、権限、イシュー、その他のメタデータなど）のためにPostgreSQLを使用しています。 GitLabはデフォルトで、提供するベアGitリポジトリを/home/git/repositories 。また、デフォルトのブランチとフック情報もベアリポジトリと一緒に保持します。

HTTP/HTTPSでリポジトリを提供する場合、GitLabはGitオブジェクトを提供するだけでなく、作成者とアクセスを解決するためにGitLab APIを利用します。

アドオンコンポーネントであるGitLab ShellはSSH経由でリポジトリにアクセスします。GitLab Shellは/home/git/.ssh/authorized_keys 内のSSHキーを管理します。GitLab ShellはGitaly経由でベアリポジトリにアクセスしてGitオブジェクトを提供し、Redisと通信してGitLabが処理するためのジョブをSidekiqに送信します。 GitLab ShellはGitLab APIに問い合わせて作成者とアクセスを決定します。

GitalyはGitLab ShellとGitLabウェブアプリからGitオペレーションを実行し、GitLabウェブアプリにAPIを提供し、Gitから属性（タイトル、ブランチ、タグ、その他のメタデータなど）を取得し、blob（差分、コミット、ファイルなど）を取得します。

GitLab.comのプロダクション・アーキテクチャにも興味があるかもしれません。

簡易コンポーネントの概要

これは、GitLabのアーキテクチャを理解するために使える簡略化したアーキテクチャ図です。

完全なアーキテクチャ図は、以下のコンポーネント図でご覧いただけます。

Simplified Component Overview

コンポーネント図

graph TB HTTP[HTTP/HTTPS] -- TCP 80, 443 --> NGINX[NGINX] SSH -- TCP 22 --> GitLabShell[GitLab Shell] SMTP[SMTP Gateway] Geo[GitLab Geo Node] -- TCP 22, 80, 443 --> NGINX GitLabShell --TCP 8080 -->Unicorn["Unicorn (GitLab Rails)"] GitLabShell --> Praefect GitLabShell --> Redis Unicorn --> PgBouncer[PgBouncer] Unicorn --> Redis Unicorn --> Praefect Sidekiq --> Redis Sidekiq --> PgBouncer Sidekiq --> Praefect GitLabWorkhorse[GitLab Workhorse] --> Unicorn GitLabWorkhorse --> Redis GitLabWorkhorse --> Praefect Praefect --> Gitaly NGINX --> GitLabWorkhorse NGINX -- TCP 8090 --> GitLabPages[GitLab Pages] NGINX --> Grafana[Grafana] Grafana -- TCP 9090 --> Prometheus[Prometheus] Prometheus -- TCP 80, 443 --> Unicorn 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 GitLabExporter --> PostgreSQL GitLabExporter --> GitLabShell GitLabExporter --> Sidekiq PgBouncer --> Consul PostgreSQL --> Consul PgBouncer --> PostgreSQL NGINX --> Registry Unicorn --> Registry NGINX --> Mattermost Mattermost --- Unicorn Prometheus --> Alertmanager Migrations --> PostgreSQL Runner -- TCP 443 --> NGINX Unicorn -- TCP 9200 --> Elasticsearch Sidekiq -- TCP 9200 --> Elasticsearch Sidekiq -- TCP 80, 443 --> Sentry Unicorn -- TCP 80, 443 --> Sentry Sidekiq -- UDP 6831 --> Jaeger Unicorn -- UDP 6831 --> Jaeger Gitaly -- UDP 6831 --> Jaeger GitLabShell -- UDP 6831 --> Jaeger GitLabWorkhorse -- UDP 6831 --> Jaeger Alertmanager -- TCP 25 --> SMTP Sidekiq -- TCP 25 --> SMTP Unicorn -- TCP 25 --> SMTP Unicorn -- TCP 369 --> LDAP Sidekiq -- TCP 369 --> LDAP Unicorn -- TCP 443 --> ObjectStorage["Object Storage"] Sidekiq -- TCP 443 --> ObjectStorage GitLabWorkhorse -- TCP 443 --> ObjectStorage Registry -- TCP 443 --> ObjectStorage Geo -- TCP 5432 --> PostgreSQL

コンポーネント凡例

  • デフォルトでインストールされています。
  • ⚙ - 追加設定、または GitLab Managed Apps が必要です。
  • ⤓ 手動での取り付けが必要です。
  • ❌ - サポートされていないか、利用可能なインストラクションがありません。
  • 該当なし

コンポーネントのステータスは、各コンポーネントの設定ドキュメントにリンクされています。

部品リスト

テーブルの説明リンク：

コンポーネント 説明 オムニバス GitLab GitLabチャート ミニキューブ ミニマル GitLab.com ソース GDK CE/EE
証明書管理 TLS設定、Let’s Encrypt ✅ ✅ ⚙ ✅ ⚙ ⚙ CEおよびEE
領事 データベースノードの検出、フェイルオーバー ⚙ ❌ ❌ ✅ ❌ ❌ EEのみ
データベースの移行 データベースの移行 ✅ ✅ ✅ ✅ ⚙ ✅ CEおよびEE
Elasticsearch GitLab内の検索の改善 ⤓ ⤓ ⤓ ❌ ⤓ ⤓ EEのみ
Gitaly GitLabによるすべてのGitコールを処理するGit RPCサービス ✅ ✅ ✅ ✅ ⚙ ✅ CEおよびEE
GitLab Exporter GitLabの様々なメトリクスを生成します。 ✅ ✅ ✅ ✅ ❌ ❌ CEおよびEE
GitLab Geoノード 地理的に分散したGitLabノード ⚙ ❌ ❌ ✅ ❌ ⚙ EEのみ
GitLab マネージドアプリ Helm、Ingress、Cert-Manager、Prometheus、Runner、JupyterHub、Knativeのクラスターへのデプロイ ⤓ ⤓ ⤓ ⤓ ⤓ ⤓ CEおよびEE
GitLab Pages 静的ウェブサイトのホスティング ⚙ ❌ ❌ ✅ ⚙ ⚙ CEおよびEE
GitLab セルフモニタリング: Alertmanager Prometheusからのアラートを重複排除、グループ化、ルーティングします。 ⚙ ✅ ⚙ ✅ ❌ ❌ 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の主力製品 大容量のHTTPリクエストを処理するスマートなリバースプロキシ ✅ ✅ ✅ ✅ ⚙ ✅ CEおよびEE
インバウンドメール(SMTP) イシュー更新のためのメッセージ受信 ⤓ ⤓ ⤓ ✅ ⤓ ⤓ CEおよびEE
イェーガー・インテグレーション デプロイアプリの分散トレース ⤓ ⤓ ⤓ ⤓ ⤓ ⤓ EEのみ
LDAP認証 集中型LDAPディレクトリに対するユーザー認証 ⤓ ⤓ ⤓ ❌ ⤓ ⤓ CEおよびEE
マターモスト オープンソースのSlack代替ツール ⚙ ⤓ ⤓ ⤓ ❌ ❌ CEおよびEE
ミニオ オブジェクト・ストレージ・サービス ⤓ ✅ ✅ ✅ ❌ ⚙ CEおよびEE
Nginx リクエストを適切なコンポーネントにルーティングし、SSLを終了します。 ✅ ✅ ⚙ ✅ ⤓ ❌ CEおよびEE
ノードエクスポーター システム・メトリクスを備えた Prometheus エンドポイント ✅ 該当なし 該当なし ✅ ❌ ❌ CEおよびEE
送信メール(SMTP) ユーザーへのメール送信 ⤓ ⤓ ⤓ ✅ ⤓ ⤓ CEおよびEE
PgBouncer エクスポーター PgBouncerメトリクスとPrometheusエンドポイント ⚙ ❌ ❌ ✅ ❌ ❌ CEおよびEE
PgBouncer データベース接続プール、フェイルオーバー ⚙ ❌ ❌ ✅ ❌ ❌ EEのみ
PostgreSQL エクスポーター PostgreSQLメトリクスを使用したPrometheusエンドポイント ✅ ✅ ✅ ✅ ❌ ❌ CEおよびEE
PostgreSQL データベース ✅ ✅ ✅ ✅ ⤓ ✅ CEおよびEE
総評 GitクライアントとGitalyストレージノード間の透過的なプロキシです。 ✅ ❌ ❌ ✅ ⚙ ✅ CEおよびEE
Redis エクスポーター Redisメトリクスを使用したPrometheusエンドポイント ✅ ✅ ✅ ✅ ❌ ❌ CEおよびEE
Redis キャッシュサービス ✅ ✅ ✅ ✅ ⤓ ✅ CEおよびEE
レジストリ コンテナレジストリ、イメージのプッシュ/プル可能 ⚙ ✅ ✅ ✅ ⤓ ⚙ CEおよびEE
ランナー GitLab CI/CDジョブの実行 ⤓ ✅ ⚙ ✅ ⚙ ⚙ CEおよびEE
セントリーのインテグレーション デプロイアプリのエラートラッキング ⤓ ⤓ ⤓ ⤓ ⤓ ⤓ CEおよびEE
Sidekiq バックグラウンドジョブプロセッサ ✅ ✅ ✅ ✅ ✅ ✅ CEおよびEE
Unicorn (GitLab Rails) ウェブインターフェースとAPIへのリクエストを処理します。 ✅ ✅ ✅ ✅ ⚙ ✅ CEおよびEE

コンポーネントの詳細

このドキュメントは、GitLabの内部とその連携についてより深く理解したいシステム管理者やGitLabサポートエンジニアが読むことを想定しています。

デプロイされたとき、GitLabは以下のプロセスを統合したものと考えるべきです。 トラブルシューティングやデバッグをするときは、どのコンポーネントを参照しているのかをできるだけ具体的にしてください。 そうすることで、明快さが増し、混乱が減るはずです。

レイヤー

GitLabはプロセスの観点から2つのレイヤーがあると考えることができます：

  • モニタリング: このレイヤーのものは GitLab アプリケーションを提供するために必要なものではありませんが、管理者がインフラストラクチャやサービス全体の動きをより深くインサイトできるようになります。
  • Core: GitLabをプラットフォームとして提供するために不可欠なすべてのプロセス。 これらのプロセスのいずれかが停止すると、GitLabの停止が発生します。 Coreレイヤーでは、さらに以下のように分けることができます：
    • プロセッサー：実際にオペレーションを行い、サービスを提供するプロセスです。
    • データ：これらのサービスはGitLabサービスの構造化データを保存/公開します。

アラートマネージャー

アラートマネージャーはPrometheusが提供するツールで、_「Prometheusサーバーなどのクライアントアプリケーションから送信されたアラートを処理します。 アラートの重複排除、_グループ_分け、電子メール、PagerDuty、Opsgenieなどの適切な受信インテグレーションへのルーティングを行います。 また、アラートの消音や抑制も行います。」_私たちがアラートする内容については、イシュー#45740をご覧ください。

証明書管理

Consul

Consulは、サービスの発見と設定のためのツールです。 Consulはディストリビューションで、高い可用性を持ち、非常にスケーラブルです。

データベースの移行

Elasticsearch

Elasticsearch はクラウド用に構築されたディストリビューション RESTful 検索エンジンです。

Gitaly

Gitalyは、GitLabの分散デプロイメント（GitLab.comや高可用性デプロイメントを考えてください）におけるGitストレージのためのNFSの必要性を取り除くためにGitLabによって設計されたサービスです。 11.3.0現在、このサービスはGitLabのすべてのGitレベルのアクセスを処理します。 プロジェクトについての詳細はプロジェクトのREADMEをご覧ください。

総評

Praefectは、各GitクライアントとGitalyの間の透過的なプロキシであり、セカンダリノードへのリポジトリ更新のレプリケーションを調整します。

GitLab Geo

GitLab Exporter

GitLab ExporterはGitLabアプリケーション内部に関するメトリクスをPrometheusにエクスポートするために社内で設計されたプロセスです。 詳しくはプロジェクトのREADMEをご覧ください。

GitLab Pages

GitLab Pagesは、GitLabのリポジトリから静的ウェブサイトを直接公開できる機能です。

ポートフォリオ、ドキュメンテーション、マニフェスト、ビジネスプレゼンテーションなど、個人またはビジネスのウェブサイトのいずれにも使用できます。 また、コンテンツに任意のライセンスを付けることもできます。

GitLabランナー

GitLab Runnerはジョブを実行し、結果をGitLabに送信します。

GitLab CI/CDはGitLabに含まれるオープンソースの継続的インテグレーションサービスで、テストを調整します。 このプロジェクトの古い名前はGitLab CI Multi Runner でしたが、今後はGitLab Runner （CIなし）を使ってください。

GitLab シェル

GitLab ShellはGitLabで設計されたSSHベースのgit セッションを扱うプログラムであり、作成者のSSHキーのリストを変更します。 GitLab ShellはUnixシェルではなく、BashやZshの代わりでもありません。

GitLabの主力製品

GitLab Workhorseは、Unicornからのプレッシャーを軽減するためにGitLabで設計されたプログラムです。 開発者の歴史的な理由については、こちらをご覧ください。 GitLab全体のスピードアップを助けるスマートなリバースプロキシとして機能するように設計されています。

グラファナ

Grafanaは、Graphite、Elasticsearch、OpenTSDB、Prometheus、InfluxDBのためのオープンソースで機能豊富なメトリクスダッシュボードとグラフエディタです。

イェーガー

JaegerはDapperとOpenZipkinにインスパイアされたディストリビューショントレーシングシステムです。 マイクロサービスベースの分散システムのモニタリングに利用できます。

デプロイされたアプリの監視については、Jaeger tracing documentationを参照してください。

ログロテート

GitLabはすべてのログを記録する多くのサービスから構成されています。 私たちは責任を持ってログを記録することを確認するために、7.4から独自のlogrotateをバンドルし始めました。 これは一般的なオープンソースオファリングのパッケージ版にすぎません。

マターモスト

Mattermost は、https://mattermost.comが提供するオープンソース、非公開クラウド、Slack 代替サービスです。

ミニオ

MinIOはApache License v2.0でリリースされたオブジェクトストレージサーバーです。 Amazon S3クラウドストレージサービスと互換性があります。 写真、ビデオ、ログファイル、バックアップ、コンテナ/VMイメージなどの非構造化データの保存に最適です。 オブジェクトのサイズは数KBから最大5TBまでです。

NGINX

NginxはすべてのHTTPリクエストに対してIngressポートを持ち、GitLab内の適切なサブシステムにルーティングします。 私たちは、人気のあるオープンソースのウェブサーバの未修正バージョンをバンドルしています。

ノードエクスポーター

Node ExporterはPrometheusのツールで、基礎となるマシンのメトリクス（CPU/ディスク/負荷など）を提供します。 これはPrometheusプロジェクトが提供する一般的なオープンソースのパッケージ版です。

PgBouncer

PostgreSQL 用の軽量接続プーラです。

PgBouncer エクスポーター

PgBouncer用のPrometheusエクスポータです。 9127/metricsでメトリクスをエクスポートします。

PostgreSQL

GitLabはアプリケーションのメタデータとユーザー情報を保存するために人気のあるデータベースをパッケージ化しています。

PostgreSQL エクスポーター

postgres_exporter はコミュニティが提供するPrometheus exporterで、PostgreSQLに関するデータをGrafanaダッシュボードで使用するためにPrometheusに配信します。

Prometheus

Prometheusは、GitLab管理者がGitLabにサービスを提供するために使用される個々のプロセスに関するメトリクスを公開するのに役立つ時系列ツールです。

Redis

Redisは保存場所を提供するためにパッケージ化されています：

  • セッションデータ
  • 一時キャッシュ情報
  • バックグラウンドジョブキュー

Redis エクスポーター

Redis Exporterは、PrometheusにRedisプロセスに関する特定のメトリクスを提供し、Grafanaでこれらのメトリクスをグラフ化できるように設計されています。

レジストリ

レジストリはユーザが自分の Docker イメージを保存するために使うものです。 バンドルされたレジストリでは NGINX をロードバランサとして、GitLab を認証マネージャとして使っています。 クライアントがレジストリからイメージの pull や push をリクエストするたびに、401 レスポンスが返され、認証トークンの取得先（この場合は GitLab インスタンス）を示すヘッダが付加されます。 クライアントは GitLab に pull や push の認証トークンをリクエストし、レジストリへの元のリクエストを再試行します。トークン認証の詳細についてはこちらをご覧ください。

外部のレジストリも GitLab を認証エンドポイントとして使うように設定できます。

セントリー

Sentry fundamentallyは、クラッシュをリアルタイムで監視し、修正するのに役立つサービスです。 サーバはPython製ですが、あらゆる言語、あらゆるアプリケーションからイベントを送信するための完全なAPIが含まれています。

デプロイされたアプリの監視については、Sentryインテグレーションドキュメントを参照してください。

Sidekiq

SidekiqはRubyのバックグラウンドジョブプロセッサで、Redisのキューからジョブを取り出して処理します。 バックグラウンドジョブによって、GitLabは作業をバックグラウンドに移すことでリクエスト/レスポンスサイクルを高速化することができます。

Unicorn

UnicornはRubyアプリケーションサーバーで、GitLabのユーザー向け機能を提供するコアRailsアプリケーションを実行するために使われます。多くの場合、プロセス出力では、GitLabのバージョンによってbundle 、またはconfig.ru 。

LDAP認証

送信メール

インバウンドメール

GitLabマネージドアプリ

GitLabは、設定したクラスターに直接追加できる様々なアプリケーションをワンクリックでインストールできるGitLab Managed Appsを提供しています。 これらのアプリケーションは、レビューアプリやAuto DevOpsを使用する際のデプロイに必要です。 クラスターを作成した後にインストールすることができます。 これには以下が含まれます：

リクエストタイプ別GitLab

GitLabは、エンドユーザーがサービスにアクセスするための2つの「インターフェース」を提供しています：

  • ウェブHTTPリクエスト（UI/APIの表示）
  • Git HTTP/SSH リクエスト (Git データのプッシュ/プル)

いくつかのプロセスは両方で使用され、他のプロセスは特定のリクエストタイプ専用であるため、区別を理解することが重要です。

GitLab ウェブ HTTP リクエストサイクル

HTTP エンドポイント（/users/sign_inを考えてください）にリクエストをするとき、リクエストは GitLab サービスを通して次のような経路をたどります：

  • Nginx - 第一線のリバースプロキシとして動作します。
  • GitLab Workhorse - Unicornの負荷を減らすために、Railsアプリケーションに行く必要があるのか、他の場所に行く必要があるのかを決定します。
  • Unicorn - これはWebリクエストで、アプリケーションにアクセスする必要があるので、Unicornに行きます。
  • PostgreSQL/Gitaly/Redis - リクエストのタイプによって、データを保存したり取得したりするために、これらのサービスをヒットするかもしれません。

GitLab Git リクエストサイクル

以下では、HTTP と SSH の Git リクエストの経路の違いについて説明します。 Web Request Cycle と重複する部分もありますが、異なる部分もあります。

ウェブリクエスト (80/443)

HTTP上でのGitオペレーションは、Gitドキュメントで説明されているステートレスな “smart “プロトコルを使いますが、これらのオペレーションを扱う責任はGitLabのいくつかのコンポーネントに分かれています。

以下はgit fetchのシーケンス図です。 すべてのリクエストは Nginx と他の HTTP ロードバランサーを通過しますが、それらによって変換されることはないことに注意してください。 すべてのパスは/namespace/project.git URL からの相対パスで表示されます。

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

git-upload-packの代わりにgit-receive-pack を使用する以外は、git pushの場合と同様です。

SSH リクエスト (22)

SSH上でのGitオペレーションは、Gitドキュメントで説明されているステートフルなプロトコルを使うことができますが、その処理の責任はいくつかのGitLabコンポーネントに分かれています。

GitLabのコンポーネントはSSHを直接話しません - すべてのSSH接続はクライアントマシンのGitとSSHサーバーの間で行われ、SSHサーバーが接続を終了します。 SSHサーバーに対しては、すべての接続はgit ユーザーとして認証されます。GitLabのユーザーはクライアントから提示されたSSHキーによって区別されます。

FastSSHキーlookupが有効になっていると仮定した場合のgit fetchのシーケンス図です。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 upload-packの代わりにgit receive-pack を使用することを除けば、git push のオペレーションは非常によく似ています。

SSHキーの高速検索が有効になっていない場合、SSHサーバは~git/.ssh/authorized_keys ファイルを読み込んで、与えられたSSHセッションで実行するコマンドを決定します。これはRailsのAuthorizedKeysWorker、SSHキーがユーザによって変更されるたびに実行されるようにスケジュールされています。

鍵の代わりにSSH証明書を使うこともできます。 この場合、AuthorizedKeysCommand をAuthorizedPrincipalsCommandに置き換えます。これはRails内部APIを使わずに証明書からユーザ名を抽出するもので、後の/api/internal/allowed の呼び出しでkey_id の代わりに使われます。

GitLab Shellには、二要素認証コードのリセットなど、Gitalyを介さないオペレーションもいくつかあります。 Gitalyへのラウンドトリップがないことを除けば、これらは同じように処理されます - Railsは内部API呼び出しの一部としてアクションを実行し、GitLab Shellはレスポンスをユーザーに直接ストリーミングで返します。

システムレイアウト

写真の中で~git を指している場合は、Gitユーザーのホーム・ディレクトリを意味します。これは通常、/home/gitです。

GitLabは主に/home/git ユーザのホームディレクトリ内にgit ユーザとしてインストールされます。ホームディレクトリ内にはGitLabサーバソフトウェアとリポジトリが存在します（リポジトリの場所は設定可能です）。

ベアリポジトリは/home/git/repositoriesにあります。 GitLabはRuby on railsアプリケーションなので、内部構造の詳細はRuby on railsアプリケーションがどのように動作するかを勉強することで学ぶことができます。

SSH 経由でリポジトリを提供するには、GitLab Shell というアドオンアプリケーションがあり、/home/git/gitlab-shellにインストールされています。

インストールフォルダの概要

要約すると、git ユーザーのホームディレクトリ](../install/structure.md)の[ディレクトリ構造です。

プロセス 

ps aux | grep '^git'

GitLabのオペレーションにはいくつかのコンポーネントがあります。 永続データベース（PostgreSQL）とRedisデータベースを必要とし、UnicornをプロキシパスするためにApachehttpd またはNGINXを使用します。 これらのコンポーネントはすべて、GitLabとは異なるシステムユーザーとして実行する必要があります（例えば、postgres、redis 、www-dataの代わりにgit）。

git 、SidekiqとUnicorn（デフォルトではポート8080 で動作するシンプルなRuby HTTPサーバー）を起動します。GitLabユーザーでは通常、unicorn_rails master （1プロセス）、unicorn_rails worker（2プロセス）、sidekiq （1プロセス）の4つのプロセスがあります。

リポジトリへのアクセス

リポジトリはHTTPまたはSSHでアクセスされます。 HTTPクローン/プッシュ/プルはGitLab APIを利用し、SSHクローンはGitLab Shell（以前に説明済み）で処理されます。

トラブルシューティング

詳しくはREADMEをご覧ください。

サービスの初期スクリプト

GitLab initスクリプトは、Unicornと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（UnicornとSidekiqのログを含みます）：

  • /home/git/gitlab/log/ application.log, , , , , が正常にコンテナに入っています。production.logsidekiq.logunicorn.stdout.loggit_json.log unicorn.stderr.log

GitLab シェル：

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

SSH:

  • /var/log/auth.log 認証ログ（Ubuntu）。
  • /var/log/secure 認証ログ（RHELの場合）。

Nginx：

  • /var/log/nginx/ にはエラーログとアクセスログが含まれます。

Apachehttpd：

  • 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の設定。
  • unicorn.rb - Unicornウェブサーバーの設定。
  • database.yml - データベース接続設定。

GitLab Shell には/home/git/gitlab-shell/config.ymlに設定ファイルがあります。

メンテナンスタスク

GitLabはRakeタスクを提供し、バージョン情報を見たり、アプリケーション内で正しく設定されているか素早くチェックしたりすることができます。Maintenance Rake tasksを参照してください。 簡単に言うと、次のようにします： 

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のアーキテクチャについても詳しく説明しましたが、何百万人ものユーザーを抱えているのでなければ、これはおそらくオーバーでしょう。