NGINX設定

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

このページでは、GitLabインスタンス向けにNGINXを設定する管理者およびDevOpsエンジニア向けに、設定情報を提供します。これには、バンドルされたNGINX（Linuxパッケージ）、Helmチャート、またはカスタム設定に固有のパフォーマンスとセキュリティを最適化するための重要な手順が含まれています。

サービス固有のNGINX設定

異なるサービス向けにNGINX設定を設定するには、gitlab.rbファイルを編集します。

不正確または互換性のない設定により、サービスが利用できなくなる可能性があります。

GitLab Railsアプリケーションを設定するには、nginx['<setting>']キーを使用します。GitLabは、gitlab_pages['nginx']、registry['nginx']、gitlab_kas['nginx']のような他のサービスにも同様のキーを提供します。これらの<service>['nginx']設定でもnginxの設定が利用可能であり、GitLab Rails NGINXと同じデフォルト値を共有します。

gitlab.rbファイルを変更する際は、各サービス向けにNGINX設定を個別に設定します。サービス固有のNGINX設定（registry['nginx']['foo']など）には、nginx['foo']を使用して指定された設定はレプリケートされません。例えば、GitLabおよびレジストリのHTTPからHTTPSへのリダイレクトを設定するには、gitlab.rbに次の設定を追加します:

nginx['redirect_http_to_https'] = true
registry['nginx']['redirect_http_to_https'] = true

HTTPSを有効にする

デフォルトでは、LinuxパッケージのインストールはHTTPSを使用しません。gitlab.example.comのHTTPSを有効にするには:

プロキシ、ロードバランサー、またはその他の外部デバイスを使用してGitLabホスト名向けのSSLを終端する場合は、External, proxy, andロードバランサーSSL terminationを参照してください。

デフォルトのプロキシヘッダーを変更する

デフォルトでは、external_urlを指定すると、Linuxパッケージのインストールによって、ほとんどの環境に適したNGINXプロキシヘッダーが設定されます。

例えば、external_urlでhttpsスキーマを指定した場合、Linuxパッケージのインストールは以下を設定します:

"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"

GitLabインスタンスがリバースプロキシの背後にあるなど、より複雑なセットアップになっている場合は、次のようなエラーを回避するためにプロキシヘッダーを調整する必要があるかもしれません:

The change you wanted was rejected
Can't verify CSRF token authenticity Completed 422 Unprocessable

デフォルトのヘッダーをオーバーライドするには:

/etc/gitlab/gitlab.rbを編集します:

nginx['proxy_set_headers'] = {
  "X-Forwarded-Proto" => "http",
  "CUSTOM_HEADER" => "VALUE"
}

ファイルを保存し、変更を反映するためにGitLabを再設定します。

NGINXがサポートする任意のヘッダーを指定できます。

GitLabの信頼済みプロキシとNGINX `real_ip`モジュールを設定する

デフォルトでは、NGINXとGitLabは接続されたクライアントのIPアドレスをログに記録します。

GitLabがリバースプロキシの背後にある場合、プロキシのIPアドレスがクライアントアドレスとして表示されないようにしたい場合があります。

NGINXが異なるアドレスを使用するように設定するには、リバースプロキシをreal_ip_trusted_addressesリストに追加します:

# Each address is added to the NGINX config as 'set_real_ip_from <address>;'
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# Other real_ip config options
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'

これらのオプションについては、NGINX realipモジュールドキュメントを参照してください。

デフォルトでは、Linuxパッケージのインストールはreal_ip_trusted_addresses内のIPアドレスをGitLabの信頼済みプロキシとして使用します。信頼済みプロキシの設定により、ユーザーがそれらのIPアドレスからサインインしたとしてリストされるのを防ぎます。

ファイルを保存し、変更を反映するためにGitLabを再設定します。

PROXYプロトコルを設定する

GitLabの前にHAProxyのようなプロキシをPROXYプロトコルとともに使用するには:

/etc/gitlab/gitlab.rbを編集します:

# Enable termination of ProxyProtocol by NGINX
nginx['proxy_protocol'] = true
# Configure trusted upstream proxies. Required if `proxy_protocol` is enabled.
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

ファイルを保存し、変更を反映するためにGitLabを再設定します。

この設定を有効にすると、NGINXはこれらのリスナーでPROXYプロトコルトラフィックのみを受け入れます。モニタリングチェックなど、他の環境も調整してください。

非バンドル型Webサーバーを使用する

GitLabは、バンドルされていないウェブサーバーの設定に関する情報のみをガイダンスとして提供します。バンドルされていないコンポーネントのトラブルシューティングは、サポート対象外とみなされます。非バンドル型Webサーバーの使用に関してご質問や問題がある場合は、非バンドル型Webサーバーのドキュメントを参照してください。

デフォルトでは、LinuxパッケージはバンドルされたNGINXとともにGitLabをインストールします。Linuxパッケージのインストールは、gitlab-wwwユーザー（同名のグループに属する）を介したWebサーバーアクセスを許可します。外部WebサーバーがGitLabにアクセスできるようにするには、外部Webサーバーユーザーをgitlab-wwwグループに追加します。

Apacheまたは既存のNGINXインストールなどの別のWebサーバーを使用するには:

バンドルされたNGINXを無効にする:
/etc/gitlab/gitlab.rbで次を設定します:
```
nginx['enable'] = false
```
非バンドル型Webサーバーユーザー名を設定します:
Linuxパッケージのインストールには、外部Webサーバーユーザーのデフォルト設定がありません。設定でそれを指定する必要があります。例:
- Debian/Ubuntu: ApacheとNGINXの両方でデフォルトユーザーはwww-dataです。
- RHEL/CentOS: NGINXユーザーはnginxです。
Webサーバーユーザーが作成されるように、続行する前にApacheまたはNGINXをインストールしてください。そうしないと、再設定中にLinuxパッケージのインストールが失敗します。
Webサーバーユーザーがwww-dataの場合、/etc/gitlab/gitlab.rbで次を設定します:
```
web_server['external_users'] = ['www-data']
```
この設定は配列なので、gitlab-wwwグループに追加する複数のユーザーを指定できます。
変更を反映するため、sudo gitlab-ctl reconfigureを実行します。
SELinuxを使用しており、Webサーバーが制限されたSELinuxプロファイルで実行されている場合は、SELinux権限を設定する必要があるかもしれません。
外部Webサーバーが使用するすべてのディレクトリに対して、Webサーバーユーザーが正しい権限を持っていることを確認してください。そうしないと、failed (XX: Permission denied) while reading upstreamエラーが発生する可能性があります。
非バンドル型Webサーバーを信頼済みプロキシのリストに追加します:
Linuxパッケージのインストールは通常、信頼済みプロキシのリストを、バンドルされたNGINX向けのreal_ipモジュール内の設定にデフォルトで設定します。
非バンドル型Webサーバーの場合、リストを直接設定します。WebサーバーがGitLabと同じマシン上にない場合は、そのWebサーバーのIPアドレスを含めます。そうしないと、ユーザーはWebサーバーのIPアドレスからサインインしたように見えます。
```
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
```
オプション。Apacheを使用する場合は、GitLab Workhorseの設定を設定します:
ApacheはUNIXソケットに接続できず、TCPポートに接続する必要があります。GitLab WorkhorseがTCP（デフォルトポート8181）でリッスンできるようにするには、/etc/gitlab/gitlab.rbを編集します:
```
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
```
変更を反映するため、sudo gitlab-ctl reconfigureを実行します。
正しいWebサーバー設定をダウンロードします:
GitLabリポジトリに移動し、必要な設定をダウンロードします。GitLabをSSLの有無にかかわらず提供するための正しい設定ファイルを選択します。変更する必要があるかもしれません:
- YOUR_SERVER_FQDNの値をFQDNに変更します。
- SSLを使用する場合は、SSLキーの場所。
- ログファイルの場所。

NGINX設定オプション

GitLabは、特定のニーズに合わせてNGINXの動作をカスタマイズするためのさまざまな設定オプションを提供します。これらの参照項目を使用して、NGINXのセットアップを微調整し、GitLabのパフォーマンスとセキュリティを最適化します。

NGINXのリスナーアドレスを設定する

デフォルトでは、NGINXはすべてのローカルIPv4アドレスで受信接続を受け入れます。

アドレスのリストを変更するには:

/etc/gitlab/gitlab.rbを編集します:

# Listen on all IPv4 and IPv6 addresses
nginx['listen_addresses'] = ["0.0.0.0", "[::]"]
registry['nginx']['listen_addresses'] = ['*', '[::]']
gitlab_pages['nginx']['listen_addresses'] = ['*', '[::]']

ファイルを保存し、変更を反映するためにGitLabを再設定します。

NGINXのリスナーポートを設定する

デフォルトでは、NGINXはexternal_urlで指定されたポートでリッスンするか、標準ポート（HTTPの場合は80、HTTPSの場合は443）を使用します。GitLabをリバースプロキシの背後で実行している場合、リッスンポートをオーバーライドしたい場合があります。

リッスンポートを変更するには:

/etc/gitlab/gitlab.rbを編集します。例えば、ポート8081を使用するには:
```
nginx['listen_port'] = 8081
```
ファイルを保存し、変更を反映するためにGitLabを再設定します。

NGINXのログレベルを変更する

デフォルトでは、NGINXはerrorの冗長レベルでログを記録します。

ログレベルを変更するには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['error_log_level'] = "debug"
```
ファイルを保存し、変更を反映するためにGitLabを再設定します。

有効なログレベルの値については、’error_log’ directiveを参照してください。

Referrer-Policyヘッダーを設定する

デフォルトでは、GitLabはすべてのレスポンスでReferrer-Policyヘッダーをstrict-origin-when-cross-originに設定します。この設定により、クライアントは以下を実行します:

同一オリジンのリクエストに対して、完全なURLをリファラーとして送信します。
クロスオリジンのリクエストに対しては、オリジンのみを送信します。

このヘッダーを変更するには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['referrer_policy'] = 'same-origin'
```
このヘッダーを無効にして、クライアントのデフォルト設定を使用するには:
```
nginx['referrer_policy'] = false
```
ファイルを保存し、変更を反映するためにGitLabを再設定します。

この設定をoriginまたはno-referrerにすると、完全なリファラーURLを必要とするGitLabの機能が損なわれます。

詳細については、Referrer Policy仕様を参照してください。

Cross-Origin-Resource-PolicyヘッダーとMermaidダイアグラム

Cross-Origin-Resource-Policy (CORP) ヘッダーをsame-siteまたはsame-originの値で設定すると、Mermaidダイアグラムはサイレントにレンダリングに失敗します。

例:

nginx['custom_gitlab_server_config'] = "add_header Cross-Origin-Resource-Policy same-site;"

Mermaidサンドボックス化されたiframeは、意図的にallow-same-originサンドボックス属性を省略します。これにより、iframeのオリジンがnullになります。CORPがsame-siteまたはsame-originに設定されている場合、nullはどちらのポリシーも満たさないため、ブラウザはnullオリジンのリソース読み込みをブロックします。

Mermaidダイアグラムのレンダリングを許可するには、cross-originを使用します:

nginx['custom_gitlab_server_config'] = "add_header Cross-Origin-Resource-Policy cross-origin;"

cross-originは、same-siteまたはsame-originよりも制限が緩やかです。この設定を使用する前に、セキュリティ要件を確認してください。

Gzip圧縮を無効にする

デフォルトでは、GitLabは10240バイトを超えるテキストデータに対してGzip圧縮を有効にします。Gzip圧縮を無効にするには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['gzip_enabled'] = false
```
ファイルを保存し、変更を反映するためにGitLabを再設定します。

gzip設定は、メインのGitLabアプリケーションにのみ適用され、他のサービスには適用されません。

プロキシリクエストのバッファリングを無効にする

特定の場所に対するリクエストのバッファリングを無効にするには:

/etc/gitlab/gitlab.rbを編集します:

nginx['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$"

ファイルを保存し、変更を反映するためにGitLabを再設定します。
NGINX設定を正常にリロードします:
```
sudo gitlab-ctl hup nginx
```

hupコマンドの詳細については、NGINXドキュメントを参照してください。

`robots.txt`を設定する

独自のインスタンス向けカスタムrobots.txtファイルを設定するには:

カスタムrobots.txtファイルを作成し、そのパスをメモします。
/etc/gitlab/gitlab.rbを編集します:
```
nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"
```
/path/to/custom/robots.txtをカスタムrobots.txtファイルへの実際のパスに置き換えます。
ファイルを保存し、変更を反映するためにGitLabを再設定します。

この設定により、カスタムrobots.txtファイルを提供するためのカスタムNGINX設定が追加されます。

GitLabサーバーブロックにカスタムNGINX設定を挿入する

GitLab向けのNGINX serverブロックにカスタム設定を追加するには:

/etc/gitlab/gitlab.rbを編集します:

# Example: block raw file downloads from a specific repository
nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n"

ファイルを保存し、変更を反映するためにGitLabを再設定します。

これにより、定義された文字列が/var/opt/gitlab/nginx/conf/service_conf/gitlab-rails.conf内のserverブロックの末尾に挿入されます。

カスタム設定は、gitlab.rbファイルの他の場所で定義されている設定と競合する可能性があります。

デフォルトサーバーを無効にする

デフォルトでは、バンドルされたNGINXはGitLabサーバーブロックのlistenディレクティブにdefault_serverを含めます。この設定により、NGINXは、他のサーバーブロックと一致しないすべてのリクエストに対して、このサーバーブロックをデフォルトとして使用します。

独自のカスタムサーバーブロックをdefault_server（例えば、nginx['custom_gitlab_server_config']を使用する場合）で追加する必要がある場合は、GitLab設定でデフォルトサーバーを無効にする必要があります:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['default_server_enabled'] = false
```
ファイルを保存し、変更を反映するためにGitLabを再設定します。

このアプローチにより、listenディレクティブからdefault_serverが削除され、独自のデフォルトサーバーブロックを定義できるようになります。

注

新しいロケーションを追加する場合は、以下を含める必要があるかもしれません:
```
proxy_cache off;
proxy_http_version 1.1;
proxy_pass http://gitlab-workhorse;
```
これらがないと、サブロケーションは404エラーを返す可能性があります。
ルート/ロケーションまたは/assetsロケーションは、すでにgitlab-rails.confに存在するため、追加できません。

カスタム設定をNGINX設定に挿入する

カスタム設定をNGINX設定に追加するには:

/etc/gitlab/gitlab.rbを編集します:

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;"

ファイルを保存し、変更を反映するためにGitLabを再設定します。

これにより、定義された文字列が/var/opt/gitlab/nginx/conf/nginx.conf内のhttpブロックの末尾に挿入されます。

例えば、カスタムサーバーブロックを作成して有効にするには:

/etc/gitlab/nginx/sites-availableディレクトリにカスタムサーバーブロックを作成します。
/etc/gitlab/nginx/sites-enabledディレクトリが存在しない場合は作成します。
カスタムサーバーブロックを有効にするには、シンボリックリンクを作成します:
```
sudo ln -s /etc/gitlab/nginx/sites-available/example.conf /etc/gitlab/nginx/sites-enabled/example.conf
```
NGINX設定をリロードします:
```
sudo gitlab-ctl hup nginx
```
または、NGINXを再起動できます:
```
sudo gitlab-ctl restart nginx
```

生成されたLet’s Encrypt SSL証明書に、サーバーブロックのドメインを代替名として追加できます。

/etc/gitlab/ディレクトリ内のカスタムNGINX設定は、アップグレード中およびsudo gitlab-ctl backup-etcが手動で実行されたときに/etc/gitlab/config_backup/にバックアップされます。

カスタムエラーページを設定する

デフォルトのGitLabエラーページのテキストを変更するには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['custom_error_pages'] = {
 '404' => {
   'title' => 'Example title',
   'header' => 'Example header',
   'message' => 'Example message'
 }
}
```
この例では、デフォルトの404エラーページを変更します。この形式は、404または502などの有効なHTTPエラーコードすべてに使用できます。
ファイルを保存し、変更を反映するためにGitLabを再設定します。

404エラーページの結果は次のようになります:

既存のPassengerとNGINXのインストールを使用する

既存のPassengerとNGINXのインストールでGitLabをホストしながら、更新とインストールにLinuxパッケージを使用できます。

NGINXを無効にした場合、nginx.confに手動で追加しない限り、Linuxパッケージインストールに含まれる他のサービスにアクセスできません。

設定

既存のPassengerとNGINXのインストールでGitLabをセットアップするには:

/etc/gitlab/gitlab.rbを編集します:

# Define the external url
external_url 'http://git.example.com'

# Disable the built-in NGINX
nginx['enable'] = false

# Disable the built-in Puma
puma['enable'] = false

# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.example.com'

# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['www-data']

ファイルを保存し、変更を反映するためにGitLabを再設定します。

仮想ホスト（サーバーブロック）を設定する

カスタムのPassenger/NGINXインストールで:

以下の内容で新しいサイト設定ファイルを作成します:

upstream gitlab-workhorse {
 server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}

server {
 listen *:80;
 server_name git.example.com;
 server_tokens off;
 root /opt/gitlab/embedded/service/gitlab-rails/public;

 client_max_body_size 250m;

 access_log  /var/log/gitlab/nginx/gitlab_access.log;
 error_log   /var/log/gitlab/nginx/gitlab_error.log;

 # Ensure Passenger uses the bundled Ruby version
 passenger_ruby /opt/gitlab/embedded/bin/ruby;

 # Correct the $PATH variable to included packaged executables
 passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

 # Make sure Passenger runs as the correct user and group to
 # prevent permission issues
 passenger_user git;
 passenger_group git;

 # Enable Passenger & keep at least one instance running at all times
 passenger_enabled on;
 passenger_min_instances 1;

 location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 location ~ ^/api/v3/projects/.*/repository/archive {
   # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
   error_page 418 = @gitlab-workhorse;
   return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /ci/api/v1/builds/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }

 # Build artifacts should be submitted to this location
 location ~ /api/v4/jobs/[0-9]+/artifacts {
     client_max_body_size 0;
     # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
     error_page 418 = @gitlab-workhorse;
     return 418;
 }


 # For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
 if ($http_host = "") {
 # use one of values defined in server_name
   set $http_host_with_default "git.example.com";
 }

 if ($http_host != "") {
   set $http_host_with_default $http_host;
 }

 location @gitlab-workhorse {

   ## https://github.com/gitlabhq/gitlabhq/issues/694
   ## Some requests take more than 30 seconds.
   proxy_read_timeout      3600;
   proxy_connect_timeout   300;
   proxy_redirect          off;

   # Do not buffer Git HTTP responses
   proxy_buffering off;

   proxy_set_header    Host                $http_host_with_default;
   proxy_set_header    X-Real-IP           $remote_addr;
   proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
   proxy_set_header    X-Forwarded-Proto   $scheme;

   proxy_http_version 1.1;
   proxy_pass http://gitlab-workhorse;

   ## The following settings only work with NGINX 1.7.11 or newer
   #
   ## Pass chunked request bodies to gitlab-workhorse as-is
   # proxy_request_buffering off;
   # proxy_http_version 1.1;
 }

 ## Enable gzip compression as per rails guide:
 ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
 ## WARNING: If you are using relative urls remove the block below
 ## See config/application.rb under "Relative url support" for the list of
 ## other files that need to be changed for relative url support
 location ~ ^/(assets)/ {
   root /opt/gitlab/embedded/service/gitlab-rails/public;
   gzip_static on; # to serve pre-gzipped version
   expires max;
   add_header Cache-Control public;
 }

 error_page 502 /502.html;
}

git.example.comをサーバーURLに置き換えます。

403 Forbiddenエラーが発生した場合は、/etc/nginx/nginx.confでPassengerが有効になっていることを確認してください:

この行のコメントを解除します:
```
# include /etc/nginx/passenger.conf;
```
NGINX設定をリロードします:
```
sudo service nginx reload
```

NGINXステータスモニタリングを設定する

デフォルトでは、GitLabはNGINXサーバーのステータスをモニタリングするために、127.0.0.1:8060/nginx_statusにNGINXヘルスチェックエンドポイントを設定します。仮想ホストトラフィックステータス（VTS）モジュールが有効になっている場合（デフォルト）、このポートは127.0.0.1:8060/metricsでPrometheusメトリクスも提供します。

このエンドポイントには以下の情報が表示されます:

Active connections: 1
server accepts handled requests
18 18 36
Reading: 0 Writing: 1 Waiting: 0

アクティブな接続: 合計のオープン接続。
3つの数値は以下を示します:
- すべての受け入れられた接続。
- すべての処理された接続。
- 処理されたリクエストの総数。
読み取り: NGINXはリクエストヘッダーを読み取ります。
書き込み: NGINXはリクエストボディを読み取り、リクエストを処理し、またはクライアントに応答を書き込みます。
待機: キープアライブ接続。この数値はkeepalive_timeoutディレクティブに依存します。

NGINXステータスオプションを設定する

NGINXステータスオプションを設定するには:

/etc/gitlab/gitlab.rbを編集します:

nginx['status'] = {
 "listen_addresses" => ["127.0.0.1"],
 "fqdn" => "dev.example.com",
 "options" => {
   "access_log" => "off", # Disable logs for stats
   "allow" => "127.0.0.1", # Only allow access from localhost
   "deny" => "all" # Deny access to anyone else
 }
}

VTSが有効な場合、オプションに"stub_status" => "on"を含めないでください。この設定はすべてのエンドポイントに適用され、/metricsがPrometheusメトリクスの代わりに基本的なnginx_status出力を返す原因となります。

VTSを無効にし、基本的なnginx_statusメトリクスのみを使用するには:

nginx['status']['vts_enable'] = false

NGINXステータスエンドポイントを無効にするには:

nginx['status'] = {
 'enable' => false
}

ファイルを保存し、変更を反映するためにGitLabを再設定します。

VTSモジュールで高度なメトリクスを設定する

GitLabには、追加のパフォーマンスメトリクス（レイテンシーパーセンタイルを含む）を提供するNGINX VTS（仮想ホストトラフィックステータス）モジュールが含まれています。

ヒストグラムバケットでVTSモジュールを有効にする前に、以下の影響を考慮してください:

メトリクスデータを格納するために、メモリ使用量が増加します。影響は仮想ホストの数とトラフィック量に応じてスケールします。
各リクエストでヒストグラムメトリクスを計算すると、少量のCPUが消費されます。
これらのメトリクスをPrometheusで収集する場合、追加のストレージが必要です。

高トラフィックのインストールの場合、パフォーマンスが許容範囲内に収まることを確認するために、これらのメトリクスをモニタリングしてください。

高度なレイテンシーメトリクスを有効にするには:

以下の設定を/etc/gitlab/gitlab.rbに追加します:

nginx['custom_gitlab_server_config'] = "vhost_traffic_status_histogram_buckets 0.005 0.01 0.05 0.1 0.25 0.5 1 2.5 5 10;"

または、カスタムNGINX設定ファイルを作成します:

sudo mkdir -p /etc/gitlab/nginx/conf.d/
sudo vim /etc/gitlab/nginx/conf.d/vts-custom.conf

ヒストグラムバケットとフィルタリングを有効にするには、これらの設定を追加します:

vhost_traffic_status_histogram_buckets 0.005 0.01 0.05 0.1 0.25 0.5 1 2.5 5 10;
vhost_traffic_status_filter_by_host on;
vhost_traffic_status_filter on;
vhost_traffic_status_filter_by_set_key $server_name server::*;

GitLabがカスタム設定を含むように設定するには、以下を/etc/gitlab/gitlab.rbに追加します:
```
nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/conf.d/vts-custom.conf;"
```

NGINXを再設定して再起動します:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart nginx

これらの設定を有効にした後、Prometheusクエリを使用してさまざまなレイテンシーメトリクスをモニタリングできます:

# Average response time
rate(nginx_vts_server_request_seconds_total[5m]) / rate(nginx_vts_server_requests_total{code=~"2xx|3xx|4xx|5xx"}[5m])

# P90 latency
histogram_quantile(0.90, rate(nginx_vts_server_request_duration_seconds_bucket[5m]))

# P99 latency
histogram_quantile(0.99, rate(nginx_vts_server_request_duration_seconds_bucket[5m]))

# Average upstream response time
rate(nginx_vts_upstream_response_seconds_total[5m]) / rate(nginx_vts_upstream_requests_total{code=~"2xx|3xx|4xx|5xx"}[5m])

# P90 upstream latency
histogram_quantile(0.90, rate(nginx_vts_upstream_response_duration_seconds_bucket[5m]))

# P99 upstream latency
histogram_quantile(0.99, rate(nginx_vts_upstream_response_duration_seconds_bucket[5m]))

GitLab Workhorse固有のメトリクスには、以下を使用できます:

# 90th percentile upstream latency for GitLab Workhorse
histogram_quantile(0.90, rate(nginx_vts_upstream_response_duration_seconds_bucket{upstream="gitlab-workhorse"}[5m]))

# Average upstream response time for GitLab Workhorse
rate(nginx_vts_upstream_response_seconds_total{upstream="gitlab-workhorse"}[5m]) /
rate(nginx_vts_upstream_requests_total{upstream="gitlab-workhorse",code=~"2xx|3xx|4xx|5xx"}[5m])

アップロードのユーザー権限を設定する

ユーザーのアップロードにアクセスできるようにするには、NGINXユーザー（通常はwww-data）をgitlab-wwwグループに追加します:

sudo usermod -aG gitlab-www www-data

テンプレート

設定ファイルは、バンドルされたGitLab NGINX設定に似ていますが、以下の違いがあります:

Pumaの代わりにPassenger設定が使用されます。
HTTPSはデフォルトでは有効になっていませんが、有効にできます。

NGINX設定を変更した後:

Debianベースのシステムの場合、NGINXを再起動します:
```
sudo service nginx restart
```
その他のシステムについては、NGINXを再起動するための正しいコマンドについて、オペレーティングシステムのドキュメントを参照してください。

NGINX設定

サービス固有のNGINX設定

HTTPSを有効にする

デフォルトのプロキシヘッダーを変更する

GitLabの信頼済みプロキシとNGINX real_ipモジュールを設定する

PROXYプロトコルを設定する

非バンドル型Webサーバーを使用する

NGINX設定オプション

NGINXのリスナーアドレスを設定する

NGINXのリスナーポートを設定する

NGINXのログレベルを変更する

Referrer-Policyヘッダーを設定する

Cross-Origin-Resource-PolicyヘッダーとMermaidダイアグラム

Gzip圧縮を無効にする

プロキシリクエストのバッファリングを無効にする

robots.txtを設定する

GitLabサーバーブロックにカスタムNGINX設定を挿入する

デフォルトサーバーを無効にする

注

カスタム設定をNGINX設定に挿入する

カスタムエラーページを設定する

既存のPassengerとNGINXのインストールを使用する

設定

仮想ホスト（サーバーブロック）を設定する

NGINXステータスモニタリングを設定する

NGINXステータスオプションを設定する

VTSモジュールで高度なメトリクスを設定する

アップロードのユーザー権限を設定する

テンプレート

GitLabの信頼済みプロキシとNGINX `real_ip`モジュールを設定する

`robots.txt`を設定する