- ソフトウェア配信
-
コンポーネント
- 簡易コンポーネントの概要
- コンポーネント図
- コンポーネント凡例
- 部品リスト
-
コンポーネントの詳細
- アラートマネージャー
- 証明書管理
- Consul
- データベースの移行
- Elasticsearch
- Gitaly
- 総評
- GitLab Geo
- GitLab Exporter
- GitLab Pages
- GitLabランナー
- GitLab シェル
- GitLabの主力製品
- グラファナ
- イェーガー
- ログロテート
- マターモスト
- ミニオ
- NGINX
- ノードエクスポーター
- PgBouncer
- PgBouncer エクスポーター
- PostgreSQL
- PostgreSQL エクスポーター
- Prometheus
- Redis
- Redis エクスポーター
- レジストリ
- セントリー
- Sidekiq
- Unicorn
- LDAP認証
- 送信メール
- インバウンドメール
- GitLabマネージドアプリ
- リクエストタイプ別GitLab
- システムレイアウト
- トラブルシューティング
- GitLab.com
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のアーキテクチャを理解するために使える簡略化したアーキテクチャ図です。
完全なアーキテクチャ図は、以下のコンポーネント図でご覧いただけます。
コンポーネント図
コンポーネント凡例
- デフォルトでインストールされています。
- ⚙ - 追加設定、または 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サービスの構造化データを保存/公開します。
アラートマネージャー
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
alertmanager
- GitLab.com:GitLab.comのモニタリング
アラートマネージャーはPrometheusが提供するツールで、_「Prometheusサーバーなどのクライアントアプリケーションから送信されたアラートを処理します。 アラートの重複排除、_グループ_分け、電子メール、PagerDuty、Opsgenieなどの適切な受信インテグレーションへのルーティングを行います。 また、アラートの消音や抑制も行います。」_私たちがアラートする内容については、イシュー#45740をご覧ください。
証明書管理
Consul
Consulは、サービスの発見と設定のためのツールです。 Consulはディストリビューションで、高い可用性を持ち、非常にスケーラブルです。
データベースの移行
Elasticsearch
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- GitLab.com:GitLab.comのエピックでAdvanced Global Searchを使えるようにしました。
Elasticsearch はクラウド用に構築されたディストリビューション RESTful 検索エンジンです。
Gitaly
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- プロセス
gitaly
- GitLab.com:サービスアーキテクチャ
Gitalyは、GitLabの分散デプロイメント(GitLab.comや高可用性デプロイメントを考えてください)におけるGitストレージのためのNFSの必要性を取り除くためにGitLabによって設計されたサービスです。 11.3.0現在、このサービスはGitLabのすべてのGitレベルのアクセスを処理します。 プロジェクトについての詳細はプロジェクトのREADMEをご覧ください。
総評
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- プロセス
praefect
- GitLab.com:サービスアーキテクチャ
Praefectは、各GitクライアントとGitalyの間の透過的なプロキシであり、セカンダリノードへのリポジトリ更新のレプリケーションを調整します。
GitLab Geo
GitLab Exporter
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
gitlab-exporter
- GitLab.com:GitLab.comのモニタリング
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
- GitLab.com:サービスアーキテクチャ
GitLab Workhorseは、Unicornからのプレッシャーを軽減するためにGitLabで設計されたプログラムです。 開発者の歴史的な理由については、こちらをご覧ください。 GitLab全体のスピードアップを助けるスマートなリバースプロキシとして機能するように設計されています。
グラファナ
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- GitLab.com:GitLab トリアージ Grafana ダッシュボード
Grafanaは、Graphite、Elasticsearch、OpenTSDB、Prometheus、InfluxDBのためのオープンソースで機能豊富なメトリクスダッシュボードとグラフエディタです。
イェーガー
JaegerはDapperとOpenZipkinにインスパイアされたディストリビューショントレーシングシステムです。 マイクロサービスベースの分散システムのモニタリングに利用できます。
デプロイされたアプリの監視については、Jaeger tracing documentationを参照してください。
ログロテート
GitLabはすべてのログを記録する多くのサービスから構成されています。 私たちは責任を持ってログを記録することを確認するために、7.4から独自のlogrotateをバンドルし始めました。 これは一般的なオープンソースオファリングのパッケージ版にすぎません。
マターモスト
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(プロセッサー)
- GitLab.com:Mattermost
Mattermost は、https://mattermost.comが提供するオープンソース、非公開クラウド、Slack 代替サービスです。
ミニオ
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- GitLab.com:ストレージアーキテクチャ
MinIOはApache License v2.0でリリースされたオブジェクトストレージサーバーです。 Amazon S3クラウドストレージサービスと互換性があります。 写真、ビデオ、ログファイル、バックアップ、コンテナ/VMイメージなどの非構造化データの保存に最適です。 オブジェクトのサイズは数KBから最大5TBまでです。
NGINX
- プロジェクトページ:
- コンフィギュレーション:
- レイヤー:コアサービス(プロセッサー)
- プロセス
nginx
- GitLab.com:サービスアーキテクチャ
NginxはすべてのHTTPリクエストに対してIngressポートを持ち、GitLab内の適切なサブシステムにルーティングします。 私たちは、人気のあるオープンソースのウェブサーバの未修正バージョンをバンドルしています。
ノードエクスポーター
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
node-exporter
- GitLab.com:GitLab.comのモニタリング
Node ExporterはPrometheusのツールで、基礎となるマシンのメトリクス(CPU/ディスク/負荷など)を提供します。 これはPrometheusプロジェクトが提供する一般的なオープンソースのパッケージ版です。
PgBouncer
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- GitLab.com:データベースアーキテクチャ
PostgreSQL 用の軽量接続プーラです。
PgBouncer エクスポーター
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- GitLab.com:GitLab.comのモニタリング
PgBouncer用のPrometheusエクスポータです。 9127/metricsでメトリクスをエクスポートします。
PostgreSQL
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- プロセス
postgresql
- GitLab.com:PostgreSQL
GitLabはアプリケーションのメタデータとユーザー情報を保存するために人気のあるデータベースをパッケージ化しています。
PostgreSQL エクスポーター
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
postgres-exporter
- GitLab.com:GitLab.comのモニタリング
postgres_exporter
はコミュニティが提供するPrometheus exporterで、PostgreSQLに関するデータをGrafanaダッシュボードで使用するためにPrometheusに配信します。
Prometheus
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
prometheus
- GitLab.com:Prometheus
Prometheusは、GitLab管理者がGitLabにサービスを提供するために使用される個々のプロセスに関するメトリクスを公開するのに役立つ時系列ツールです。
Redis
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:コアサービス(データ)
- プロセス
redis
- GitLab.com:サービスアーキテクチャ
Redisは保存場所を提供するためにパッケージ化されています:
- セッションデータ
- 一時キャッシュ情報
- バックグラウンドジョブキュー
Redis エクスポーター
- プロジェクトページ
- コンフィギュレーション:
- レイヤー:モニタリング
- プロセス
redis-exporter
- GitLab.com:GitLab.comのモニタリング
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 からの相対パスで表示されます。
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が提供する実行ファイルであることに注意してください:
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.log
sidekiq.log
unicorn.stdout.log
git_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のアーキテクチャについても詳しく説明しましたが、何百万人ものユーザーを抱えているのでなければ、これはおそらくオーバーでしょう。