CLIオプション
Redis
相対 URL サポート
TLSのサポート
authBackend とauthSocket
エラートラッキング
ディストリビューショントレース
- 相関 ID の伝播
- 信頼できるプロキシ
継続的なプロファイリング
関連するトピック

Workhorse設定

歴史的な理由から、Workhorseは使用しています：

コマンドラインフラグ。
設定ファイル。
環境変数。

Workhorseの新しい設定オプションを設定ファイルに追加します。

CLIオプション

  gitlab-workhorse [OPTIONS]

Options:
  -apiCiLongPollingDuration duration
        Long polling duration for job requesting for runners (default 50ns)
  -apiLimit uint
        Number of API requests allowed at single time
  -apiQueueDuration duration
        Maximum queueing duration of requests (default 30s)
  -apiQueueLimit uint
        Number of API requests allowed to be queued
  -authBackend string
        Authentication/authorization backend (default "http://localhost:8080")
  -authSocket string
        Optional: Unix domain socket to dial authBackend at
  -cableBackend string
        ActionCable backend
  -cableSocket string
        Optional: Unix domain socket to dial cableBackend at
  -config string
        TOML file to load config from
  -developmentMode
        Allow the assets to be served from Rails app
  -documentRoot string
        Path to static files content (default "public")
  -listenAddr string
        Listen address for HTTP server (default "localhost:8181")
  -listenNetwork string
        Listen 'network' (tcp, tcp4, tcp6, unix) (default "tcp")
  -listenUmask int
        Umask for Unix socket
  -logFile string
        Log file location
  -logFormat string
        Log format to use defaults to text (text, json, structured, none) (default "text")
  -pprofListenAddr string
        pprof listening address, for example, 'localhost:6060'
  -prometheusListenAddr string
        Prometheus listening address, for example, 'localhost:9229'
  -propagateCorrelationID X-Request-ID
        Reuse existing Correlation-ID from the incoming request header X-Request-ID if present
  -proxyHeadersTimeout duration
        How long to wait for response headers when proxying the request (default 5m0s)
  -secretPath string
        File with secret key to authenticate with authBackend (default "./.gitlab_workhorse_secret")
  -version
        Print version and exit

auth backend’はGitLab Railsアプリケーションを指します。この名前は、GitLab Workhorse がgit push とgit pull のみを HTTP で扱っていたときの名残です。

GitLab WorkhorseはTCPソケットかUnixドメインソケットでリッスンできます。また、Gonet/http/pprof プロファイラーサーバーで2つ目のリスニング用TCPリスニングソケットを開くこともできます。

GitLab Workhorseは、-config フラグを通して有効なTOML設定ファイルを渡せば、RedisのビルドとRunner登録イベントをリッスンすることができます。通常のセットアップでは、次のようにするだけです（文字列を実際のソケットに置き換えます）。

Redis

GitLab WorkhorseはRedisとインテグレーションし、CIビルドリクエストのロングポーリングを行います。設定方法は以下の通りです：

TOML 設定ファイルで Redis の設定を行います。
-apiCiLongPollingDuration コマンドラインフラグで CI ビルドリクエストのポーリング動作を制御します。

CIポーリングを無効にしたまま、設定ファイルでRedisを有効にすることができます。この設定では、RedisのPub/Sub接続はアイドル状態になります。その逆はできません：CIロングポーリングには正しいRedisの設定が必要です。

例えば、設定ファイルの[redis] ：

[redis]
URL = "unix:///var/run/gitlab/redis.sock"
Password = "my_awesome_password"
Sentinel = [ "tcp://sentinel1:23456", "tcp://sentinel2:23456" ]
SentinelMaster = "mymaster"

URL - unix://path/to/redis.sock またはtcp://host:port という書式の文字列。
Password - Redis インスタンスがパスワードで保護されている場合のみ必要です。
Sentinel - Sentinelを使用する場合は必要です。

Sentinel とURL の両方が指定された場合、Sentinel のみが使用されます。

オプションのフィールド：

[redis]
DB = 0
MaxIdle = 1
MaxActive = 1

DB - 接続先データベース。デフォルトは0 です。
MaxIdle - Redis プールに同時にいくつのアイドル接続を持つことができるか。デフォルトは1 です。
MaxActive - プールが保持できる接続数。デフォルトは1 です。

相対 URL サポート

example.com/gitlab) のように相対URLでGitLabをマウントする場合は、authBackend の設定でこの相対URLを使用します：

gitlab-workhorse -authBackend http://localhost:8080/gitlab

TLSのサポート

受信リクエストに TLS を使用するリスナーを設定できます。サーバの証明書と一致する秘密鍵を含むファイルへのパスを提供する必要があります：

[[listeners]]
network = "tcp"
addr = "localhost:3443"
[listeners.tls]
  certificate = "/path/to/certificate"
  key = "/path/to/private/key"
  min_version = "tls1.2"
  max_version = "tls1.3"

certificate ファイルには、サーバーの証明書、中間証明書、CAの証明書を連結したものを含める必要があります。

メトリクス・エンドポイントも同様に設定できます：

[metrics_listener]
network = "tcp"
addr = "localhost:9229"
[metrics_listener.tls]
  certificate = "/path/to/certificate"
  key = "/path/to/private/key"
  min_version = "tls1.2"
  max_version = "tls1.3"

`authBackend` と`authSocket`

との相互作用はauthBackend authSocket 混乱を招くことが authSocket authBackendあります。がauthBackend 設定されて authBackendいるauthBackend authSocket 場合 authSocket authBackend、相対パスではなく、authBackend ホスト部分を上書き authBackendします。

表形式では

`authBackend`	`authSocket`	Workhorseの接続先	Rails 相対 URL
アンセット	アンセット	`localhost:8080`	`/`
`http://localhost:3000`	アンセット	`localhost:3000`	`/`
`http://localhost:3000/gitlab`	アンセット	`localhost:3000`	`/gitlab`
アンセット	`/path/to/socket`	`/path/to/socket`	`/`
`http://localhost:3000`	`/path/to/socket`	`/path/to/socket`	`/`
`http://localhost:3000/gitlab`	`/path/to/socket`	`/path/to/socket`	`/gitlab`

cableBackend とcableSocket も同様。

エラートラッキング

GitLab-WorkhorseはSentryによるリモートエラー追跡をサポートしています。この機能を有効にするには、GITLAB_WORKHORSE_SENTRY_DSN 環境変数を設定します。また、GITLAB_WORKHORSE_SENTRY_ENVIRONMENT 環境変数を設定すると、Sentry 環境機能を使用してステージング、本番、開発を分けることができます。

Linux package (Omnibus)

gitlab_workhorse['env'] = {
    'GITLAB_WORKHORSE_SENTRY_DSN' => 'https://foobar'
    'GITLAB_WORKHORSE_SENTRY_ENVIRONMENT' => 'production'
}

Self-compiled (source)

export GITLAB_WORKHORSE_SENTRY_DSN='https://foobar'
export GITLAB_WORKHORSE_SENTRY_ENVIRONMENT='production'

ディストリビューショントレース

WorkhorseはOpenTracing APIを使用したLabKitによる分散トレースをサポートしています。

デフォルトでは、トレースの実装はバイナリにリンクされていません。BUILD_TAGS make変数を設定することで、ビルドタグやビルド制約で異なるOpenTracingプロバイダをリンクすることができます。

サポートされているプロバイダの詳細については、LabKitを参照してください。Jaegerのトレースサポートの例としては、次のようにtags:BUILD_TAGS="tracer_static tracer_static_jaeger" をインクルードしてください：

make BUILD_TAGS="tracer_static tracer_static_jaeger"

WorkhorseをOpenTracingプロバイダでコンパイルした後、GITLAB_TRACING 環境変数でトレース設定を行います：

GITLAB_TRACING=opentracing://jaeger ./gitlab-workhorse

相関 ID の伝播

ユーザーが新しいプロジェクトを作成するなどの HTTP リクエストを行うと、最初のリクエストは Workhorse を経由して別のサービスに送られます。リクエストがサービス間を流れる際のトレースを助けるために、Workhorseは相関IDと呼ばれるランダムな値を生成します。Workhorseはこの相関IDをX-Request-Id HTTPヘッダで送信します。

GitLab ShellのようないくつかのGitLabサービスは、独自の相関IDを生成します。さらに、Gitalyのような他のサービスは、元のリクエストから相関IDを渡す内部APIコールを行います。いずれの場合も、相関 ID はX-Request-Id HTTP ヘッダを介して渡されます。

デフォルトでは、Workhorseはこのヘッダを無視し、常に新しい相関IDを生成します。これはデバッグを困難にし、ディストリビューショントレースが正しく動作することを妨げます。

Workhorse は-propagateCorrelationID コマンドラインフラグによって、入力された相関 ID を伝播するように設定できます。このオプションは、信頼できないクライアントによって任意の値が生成されないようにするために、IP許可リストと一緒に使用することを強くお勧めします。

IP 許可リストは Workhorse 設定ファイルのtrusted_cidrs_for_propagation オプションで指定します。信頼できる CIDR ブロックのリストを指定します。例えば

trusted_cidrs_for_propagation = ["10.0.0.0/8", "127.0.0.1/32"]

trusted_cidrs_for_propagation オプションが動作するには、-propagateCorrelationID フラグを使用する必要があります。

信頼できるプロキシ

Workhorse が NGINX のようなリバースプロキシの後ろにある場合、X-Forwarded-For HTTP ヘッダを通して発信元 IP アドレスを提供するために信頼できる CIDR ブロックを指定するにはtrusted_cidrs_for_x_forwarded_for オプションが必要です。例えば

trusted_cidrs_for_x_forwarded_for = ["10.0.0.0/8", "127.0.0.1/32"]

継続的なプロファイリング

Workhorse はLabKitを使ってStackdriver Profilerを使った継続的なプロファイリングをサポートしています。デフォルトでは、Stackdriver Profilerの実装はビルドタグを使ってバイナリにリンクされていますが、これは必須ではなく、スキップすることもできます。例えば

make BUILD_TAGS=""

Workhorseを連続プロファイリングでコンパイルした後、GITLAB_CONTINUOUS_PROFILING 環境変数でプロファイラ設定を行います。例えば

GITLAB_CONTINUOUS_PROFILING="stackdriver?service=workhorse&service_version=1.0.1&project_id=test-123 ./gitlab-workhorse"

LabKit モニタリング・ドキュメント

Workhorse設定

CLIオプション

Redis

相対 URL サポート

TLSのサポート

`authBackend` と`authSocket`

エラートラッキング

ディストリビューショントレース

相関 ID の伝播

信頼できるプロキシ

継続的なプロファイリング

Help & feedback

Docs

Product

Feature availability and product trials

Get Help

Workhorse設定

CLIオプション

Redis

相対 URL サポート

TLSのサポート

authBackend とauthSocket

エラートラッキング

ディストリビューショントレース

相関 ID の伝播

信頼できるプロキシ

継続的なプロファイリング

関連するトピック

Help & feedback

Docs

Product

Feature availability and product trials

Get Help

`authBackend` と`authSocket`