Gitalyリファレンス
GitalyはTOML設定ファイルによって設定されます。 ソースからのインストールとは異なり、Omnibus GitLabではこのファイルを直接編集することはありません。
設定ファイルは、gitaly
実行ファイルの引数として渡されます。これは通常、Omnibus GitLab またはinitスクリプトによって行われます。
設定ファイルの例はGitalyプロジェクトにあります。
フォーマット
トップレベルでは、config.toml
。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
socket_path
| 列 | yes (listen_addr が設定されていない場合)
| GitalyがUnixソケットを開くパス。 |
listen_addr
| 列 | yes (socket_path が設定されていない場合)
| GitalyがリッスンするためのTCPアドレス。 |
tls_listen_addr
| 列 | いいえ | GitalyがリッスンするためのTCP over TLSアドレス。 |
bin_dir
| 列 | はい | Gitalyの実行ファイルがあるコンテナ。 |
prometheus_listen_addr
| 列 | いいえ | Prometheus メトリクスの TCP リスナー・アドレス。 設定されていない場合、Prometheus リスナーは起動しません。 |
使用例:
socket_path = "/home/git/gitlab/tmp/sockets/private/gitaly.socket"
listen_addr = "localhost:9999"
tls_listen_addr = "localhost:8888"
bin_dir = "/home/git/gitaly"
prometheus_listen_addr = "localhost:9236"
認証
Gitalyは、ヘッダに特定のベアラートークンを含まないリクエストを拒否するように 設定することができます。 これは、TCP上でリクエストを提供するときに使われる セキュリティ対策です:
[auth]
# A non-empty token enables authentication.
token = "the secret token"
config.toml
のトークン設定がないか、空文字列の場合、認証は無効になります。
transitioning
、一時的に認証を無効にすることができます。これにより、まだ正しく設定されていないクライアントのサービス停止を引き起こすことなく、すべてのクライアントが正しく認証されているかどうかを監視することができます:
[auth]
token = "the secret token"
transitioning = true
Prometheusでは、すべての認証試行がgitaly_authentications_total
のメトリクスでカウントされます。
TLS
GitalyはTLS暗号化をサポートしています。 これは自動的には提供されないので、あなた自身の証明書を持参する必要があります。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
certificate_path
| 列 | いいえ | 証明書へのパス。 |
key_path
| 列 | いいえ | キーへのパス。 |
tls_listen_addr = "localhost:8888"
[tls]
certificate_path = '/home/git/cert.cert'
key_path = '/home/git/key.pem'
GitalyのTLSについてもっと読む
ストレージ
GitLabリポジトリは、”storages”(例えば、/home/git/repositories
)と呼ばれるディレクトリにグループ化され、GitLabが管理するベアリポジトリが名前(例えば、default
)で格納されています。
これらの名前とパスは、GitLabのgitlab.yml
設定ファイルでも定義されています。GitalyをGitLabと同じマシン上で実行する場合(これがデフォルトで推奨される設定です)、Gitalyのconfig.toml
で定義されたストレージ・パスは、gitlab.yml
のものと一致しなければなりません。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
storage
| アレイ | はい | ストレージシャードのアレイ。 |
path
| 列 | はい | ストレージ・シャードへのパス。 |
name
| 列 | はい | ストレージ・シャードの名前。 |
使用例:
[[storage]]
path = "/path/to/storage/repositories"
name = "my_shard"
[[storage]]
path = "/path/to/other/repositories"
name = "other_storage"
Git
コンフィギュレーション・ファイルの[git]
セクションでは、以下の値を設定できます。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
bin_path
| 列 | いいえ | git バイナリへのパス。設定されていない場合はPATH を使って解決されます。
|
catfile_cache_size
| 整数 | いいえ | キャッシュされるcat-file プロセスの最大数。デフォルトは100 。
|
cat-file
キャッシュ
GitalyのRPCの多くは、リポジトリからGitオブジェクトを検索する必要があります。ほとんどの場合、そのためにgit cat-file --batch
プロセスを使用します。パフォーマンスを向上させるために、GitalyはRPCコール間でこれらのgit cat-file
プロセスを再利用することができます。 以前に使用されたプロセスは、“Git cat-fileキャッシュ “に保持されます。 これが使用するシステムリソースの量を制御するために、私たちはキャッシュに入ることができるcat-fileプロセスの最大数を設定しています。
デフォルトの上限は、git cat-file --batch
とgit cat-file --batch-check
プロセスのペアを構成する 100cat-file
s です。 「開いているファイルが多すぎる」、または新しいプロセスを作成できない、といったエ ラーが表示される場合は、この上限を下げるとよいでしょう。
理想的には、この数値は通常のトラフィックを処理するのに十分な大きさであるべきです。 制限を上げた場合、その前後でキャッシュのヒット率を測定する必要があります。 ヒット率が向上しない場合、上限を上げても意味がない可能性があります。 ヒット率を確認するための Prometheus クエリの例を示します:
sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))
gitaly-ruby
Gitalyプロセスは、Goの代わりにRubyで実装されたRPCを実行するために、1つ以上のgitaly-ruby
ヘルパー・プロセスを使用します。設定ファイルの[gitaly-ruby]
セクションには、これらのヘルパー・プロセスの設定が含まれています。
これらのプロセスは、時折メモリリークに悩まされることが知られています。 Gitalyは、そのメモリがmax_rss
の制限を超えた場合、そのgitaly-ruby
ヘルパーを再起動します。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
dir
| 列 | はい |
gitaly-ruby がインストールされている場所へのパス(プロセスの起動に必要)。
|
max_rss
| 整数 | いいえ |
gitaly-ruby の再起動をトリガーする常駐設定サイズ制限。バイト単位。デフォルトは200000000 (200MB)。
|
graceful_restart_timeout
| 列 | いいえ |
max_rss を超えたgitaly-ruby プロセスが強制終了されるまでの猶予時間。デフォルトは10m (10 分)。
|
restart_delay
| 列 | いいえ | 再起動前にgitaly-ruby メモリがハイのままでなければならない時間。デフォルトは5m (5分)。
|
num_workers
| 整数 | いいえ |
gitaly-ruby ワーカープロセスの数。ResourceExhausted エラーが発生する場合は、この数を増やしてみてください。 デフォルトは2 、最小は 2 。
|
linguist_languages_path
| 列 | いいえ | 動的なlanguages.json 発見のためのオーバーライド。 デフォルトは空文字列です(動的発見の使用)。
|
使用例:
[gitaly-ruby]
dir = "/home/git/gitaly/ruby"
max_rss = 200000000
graceful_restart_timeout = "10m"
restart_delay = "5m"
num_workers = 2
GitLab シェル
歴史的な理由から、GitLab ShellはGitLabがGitプッシュを検証し反応するためのGitフックを含んでいます。 GitalyはGitプッシュを “所有 “しているため、GitLab ShellはGitalyと一緒にインストールされなければなりません。 これは将来的に簡素化されるでしょう。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
dir
| 列 | はい | GitLab Shellがインストールされているディレクトリ。 |
使用例:
[gitlab-shell]
dir = "/home/git/gitlab-shell"
Prometheus
オプションで、PrometheusのGRPCメソッド呼び出しのヒストグラム・レイテンシを記録するようにGitalyを設定できます。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
grpc_latency_buckets
| アレイ | いいえ | Prometheusは各オブザベーションをバケットに保存します。 つまり、レイテンシの近似値を得ることができます。 バケットを最適化することで、近似値の精度をよりコントロールすることができます。 |
使用例:
prometheus_listen_addr = "localhost:9236"
[prometheus]
grpc_latency_buckets = [0.001, 0.005, 0.025, 0.1, 0.5, 1.0, 10.0, 30.0, 60.0, 300.0, 1500.0]
ロギング
以下の値は、[logging]
セクションで Gitaly のロギングを設定します。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
format
| 列 | いいえ | ログフォーマット:text またはjson . デフォルト:text .
|
level
| 列 | いいえ | ログレベル:debug ,info ,warn ,error ,fatal , またはpanic . デフォルト:info .
|
sentry_dsn
| 列 | いいえ | 例外監視用の Sentry DSN。 |
sentry_environment
| 列 | いいえ | 例外監視のためのSentry環境。 |
ruby_sentry_dsn
| 列 | いいえ |
gitaly-ruby 例外監視用の Sentry DSN。
|
メインのGitalyアプリケーションのログはstdout
に行きますが、GitLab Shellのログのように、設定されたディレクトリに行く余分なログファイルがいくつかあります。GitLab Shellはpanic
またはtrace
レベルのログをサポートしていません。panic
はerror
にフォールバックし、trace
はdebug
にフォールバックします。その他の無効なログレベルはデフォルトでinfo
になります。
使用例:
[logging]
level = "warn"
dir = "/home/gitaly/logs"
format = "json"
sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"
ruby_sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"
コンカレンシー
各 RPC エンドポイントのconcurrency
を調整できます。
名称 | タイプ | 必須 | 説明 |
---|---|---|---|
concurrency
| アレイ | はい | RPC エンドポイントの配列。 |
rpc
| 列 | いいえ | RPC エンドポイントの名前 (/gitaly.RepositoryService/GarbageCollect )。
|
max_per_repo
| 整数 | いいえ | リポジトリごとのRPCごとの同時実行数。 |
使用例:
[[concurrency]]
rpc = "/gitaly.RepositoryService/GarbageCollect"
max_per_repo = 1