• フォーマット
  • 認証
  • TLS
  • ストレージ
  • Git
    • cat-file キャッシュ
  • GitLab シェル
  • Prometheus
  • 伐採
• 同時実行

Gitalyリファレンス

GitalyはTOML設定ファイルによって設定されます。セルフ・コンパイル・インストールとは異なり、Linuxパッケージ・インストールでは、このファイルを直接編集することはありません。Linuxパッケージ・インストールの場合、デフォルトのファイルの場所は/var/opt/gitlab/gitaly/config.toml です。

設定ファイルは、gitaly 実行ファイルへの引数として渡されます。これは通常、Linux パッケージ・インストールかinitスクリプトによって行われます。

設定ファイルの例はGitalyプロジェクトにあります。

フォーマット

トップレベルでは、config.toml 。

使用例：

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

transitioning トークン設定の変更が終わったら、transitioning を無効にすることを忘れないでください。

Prometheus では、すべての認証試行がgitaly_authentications_total メトリック でカウントされます。

TLS

GitalyはTLS暗号化をサポートしています。自動的には提供されませんので、ご自身で証明書をご用意ください。

tls_listen_addr = "localhost:8888"

[tls]
certificate_path = '/home/git/cert.cert'
key_path = '/home/git/key.pem'

GitalyのTLSについてもっと読む.

ストレージ

GitLabリポジトリは、/home/git/repositories のようなストレージと呼ばれるディレクトリにグループ化されています。これらのディレクトリには、GitLab が管理するベアリポジトリがdefault のような名前で格納されています。

これらの名前とパスはGitLabのgitlab.yml 設定ファイルでも定義されています。GitalyをGitLabと同じマシン上で実行する場合（デフォルトで推奨される設定）、Gitalyconfig.toml で定義されたストレージ・パスはgitlab.ymlのものと一致しなければなりません。

使用例：

[[storage]]
path = "/path/to/storage/repositories"
name = "my_shard"

[[storage]]
path = "/path/to/other/repositories"
name = "other_storage"

Git

設定ファイルの[git] セクションでは、以下の値を設定できます。

cat-file キャッシュ

Gitaly RPCの多くは、リポジトリからGitオブジェクトを検索する必要があります。ほとんどの場合、そのためにgit cat-file --batch プロセスを使用します。パフォーマンスを向上させるために、GitalyはRPCコール間でこれらのgit cat-file プロセスを再利用することができます。以前使用されたプロセスは、“Git cat-fileキャッシュ “に保存されます。システムリソースの使用量を制御するために、キャッシュに入ることができるcat-fileプロセスの最大数を設定しています。

デフォルトの上限は100cat-filesで、これはgit cat-file --batch とgit cat-file --batch-check プロセスのペアを構成します。開いているファイルが多すぎる」というエラーや、新しいプロセスを作成できない場合は、この上限を下げるとよいでしょう。

理想的には、標準的なトラフィックを処理するのに十分な数であるべきです。制限値を上げる場合は、その前後でキャッシュのヒット率を測定してください。ヒット率が向上しない場合、上限を上げても意味がない可能性があります。ヒット率を見るための Prometheus クエリの例を示します：

sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))

GitLab シェル

歴史的な理由により、GitLab ShellはGitLabがGitプッシュを検証し反応するためのGitフックを含んでいます。GitalyはGitプッシュを “所有 “しているため、GitLab ShellはGitalyと一緒にインストールする必要があります。

使用例：

[gitlab-shell]
dir = "/home/git/gitlab-shell"

Prometheus

オプションで、PrometheusのGRPCメソッド呼び出しのヒストグラムレイテンシを記録するようにGitalyを設定することができます。

使用例：

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 におけるロギングの設定です。

メインの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 = "/gitaly.RepositoryService/GarbageCollect"
max_per_repo = 1