• フォーマット
  • 認証
  • TLS
  • ストレージ
  • Git
    • cat-file キャッシュ
  • gitaly-ruby
  • GitLab シェル
  • Prometheus
  • ロギング
• コンカレンシー

Gitalyリファレンス

GitalyはTOML設定ファイルによって設定されます。 ソースからのインストールとは異なり、Omnibus GitLabではこのファイルを直接編集することはありません。

設定ファイルは、gitaly実行ファイルの引数として渡されます。これは通常、Omnibus GitLab または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

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リポジトリは、”storages”（例えば、/home/git/repositories）と呼ばれるディレクトリにグループ化され、GitLabが管理するベアリポジトリが名前（例えば、default）で格納されています。

これらの名前とパスは、GitLabのgitlab.yml 設定ファイルでも定義されています。GitalyをGitLabと同じマシン上で実行する場合（これがデフォルトで推奨される設定です）、Gitalyのconfig.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プロセスの最大数を設定しています。

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

理想的には、この数値は通常のトラフィックを処理するのに十分な大きさであるべきです。 制限を上げた場合、その前後でキャッシュのヒット率を測定する必要があります。 ヒット率が向上しない場合、上限を上げても意味がない可能性があります。 ヒット率を確認するための 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 ヘルパーを再起動します。

使用例：

[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と一緒にインストールされなければなりません。 これは将来的に簡素化されるでしょう。

使用例：

[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