NGINXの設定

サービス固有のNGINX設定

ユーザーは、gitlab.rbを介して、サービスごとに異なる NGINX 設定を行うことができます。GitLab Rails アプリケーションの設定は、nginx['<some setting>'] のキーを使用して行うことができます。pages_nginx、mattermost_nginx 、registry_nginxなどの他のサービスにも同様のキーがあります。nginx で利用可能なすべての設定は、これらの<service_nginx> の設定でも利用可能で、GitLab NGINX と同じデフォルト値を共有します。

gitlab.rb経由で変更する場合は、各サービスの NGINX 設定を個別に構成する必要があります。nginx['foo'] 経由で指定した設定は、サービス固有の NGINX 設定 (registry_nginx['foo'] やmattermost_nginx['foo']など) には複製されません。たとえば、GitLab、Mattermost、レジストリで HTTP から HTTPS へのリダイレクトを構成するには、次の設定をgitlab.rb 

nginx['redirect_http_to_https'] = true
registry_nginx['redirect_http_to_https'] = true
mattermost_nginx['redirect_http_to_https'] = true
注意:NGINXの設定を変更する際は、不正確な設定や互換性のない設定を行うとサービスが利用できなくなる可能性があるため、十分注意してください。

HTTPSの有効化

デフォルトでは、Omnibus GitLab は HTTPS を使用しません。gitlab.example.comで HTTPS を有効にするには、2 つのオプションがあります：

  1. Let’s Encryptによる無料かつ自動のHTTPS化
  2. 独自の証明書によるHTTPSの手動設定

警告

NGINXの設定は、今後24ヶ月間はセキュアな接続を介してのみGitLabインスタンスと通信するようにブラウザやクライアントに伝えます。 HTTPSを有効にすることで、少なくとも今後24ヶ月間はインスタンスへのセキュアな接続を提供する必要があります。

HTTPSの手動設定

デフォルトでは、Omnibus GitLabはHTTPSを使用しません。

ドメインのHTTPSを有効にするには、gitlab.example.com：

  1. /etc/gitlab/gitlab.rbでexternal_url を編集します： 

    # note the 'https' below
external_url "https://gitlab.example.com"

  2. /etc/gitlab/ssl ディレクトリを作成し、そこに鍵と証明書をコピーします： 

    sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/

    この例ではホスト名がgitlab.example.comなので、GitLab はそれぞれ/etc/gitlab/ssl/gitlab.example.com.key と/etc/gitlab/ssl/gitlab.example.com.crtという名前の秘密鍵と公開証明書のファイルを探します。

    クライアントが接続する際の SSL エラーを防ぐため、証明書チェーンを完全に使用するようにしてください。 証明書チェーンの完全な順序は、最初にサーバー証明書、次にすべての中間証明書、最後にルート CA となります。

    certificate.key ファイルがパスワードで保護されている場合、GitLab を再設定する際に NGINX がパスワードを尋ねることはありません。 その場合、Omnibus GitLab はエラーメッセージを出さずに静かに失敗します。 キーからパスワードを削除するには、以下を実行します： 

    openssl rsa -in certificate_before.key -out certificate_after.key

  3. では、GitLabを再設定しましょう： 

    sudo gitlab-ctl reconfigure

再設定が完了すると、GitLabインスタンスはhttps://gitlab.example.com。

ファイアウォールを使用している場合は、ポート443を開いてHTTPSトラフィックの受信を許可する必要があります。 

# UFW example (Debian, Ubuntu)
sudo ufw allow https

# lokkit example (RedHat, CentOS 6)
sudo lokkit -s https

# firewall-cmd (RedHat, Centos 7)
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld

HTTP リクエストを次のようにリダイレクトします。HTTPS

デフォルトでは、「https」で始まるexternal_url を指定すると、NGINXは80番ポートの暗号化されていないHTTPトラフィックをリッスンしなくなります。すべてのHTTPトラフィックをHTTPSにリダイレクトしたい場合は、redirect_http_to_https。

注：この動作はデフォルトで有効になっています。
external_url "https://gitlab.example.com"
nginx['redirect_http_to_https'] = true

デフォルトのポートとSSL証明書の場所を変更します。

デフォルト（443）以外のHTTPSポートを使用する必要がある場合は、external_urlの一部として指定してください。 

external_url "https://gitlab.example.com:2443"

ssl証明書の場所を設定するには、/etc/gitlab/ssl ディレクトリを作成し、.crt と.key ファイルをそのディレクトリに置き、以下の設定を指定します： 

# For GitLab
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.example.com.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.example.com.key"

sudo gitlab-ctl reconfigure を実行して変更を有効にします。

SSL証明書の更新

SSL証明書の内容が更新されたにもかかわらず、gitlab.rbに設定変更が行われていない場合、gitlab-ctl reconfigure はNGINXに影響を与えません。代わりに、sudo gitlab-ctl hup nginx を実行して、NGINXが既存の設定と新しい証明書を優雅にリロードするようにします。

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

デフォルトでは、external_url Omnibusを指定すると、GitLabはほとんどの環境で正常であると想定されるいくつかのNGINXプロキシヘッダを設定します。

例えば、Omnibus GitLabは次のように設定します： 

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

external_urlでhttps スキーマを指定している場合。

しかし、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でサポートされているヘッダを指定することができます。

GitLabtrusted_proxies と NGINXreal_ip モジュールの設定

デフォルトでは、NGINXとGitLabは接続しているクライアントのIPアドレスを記録します。

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

リバースプロキシをreal_ip_trusted_addresses リストに追加することで、NGINX に別のアドレスを探させることができます： 

# Each address is added to the 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'

オプションの説明

デフォルトでは、Omnibus GitLabはreal_ip_trusted_addressesにあるIPアドレスをGitLabの信頼されたプロキシとして使用し、そのIPからのサインインとしてユーザがリストされないようにします。

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

HTTP2プロトコルの設定

デフォルトでは、external_url "https://gitlab.example.com"を指定して GitLab インスタンスに HTTPS でアクセスできるようにすると、http2 プロトコルも有効になります。

Omnibus GitLabパッケージはhttp2プロトコルと互換性のある必要なssl_cipherを設定します。

設定にカスタム ssl_ciphers を指定していて、その暗号がhttp2 暗号ブラックリストにある場合、GitLab インスタンスにアクセスしようとすると、ブラウザにINADEQUATE_SECURITY エラーが表示されます。

暗号リストから問題のある暗号を削除することを検討してください。 暗号を変更する必要があるのは、非常に特殊なカスタム設定がある場合だけです。

http2プロトコルを有効にする理由の詳細については、http2ホワイトペーパーをご覧ください。

暗号を変更するのが面倒な場合は、/etc/gitlab/gitlab.rbで http2 サポートを無効にすることができます： 

nginx['http2_enabled'] = false

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

注： http2 の設定はメインのGitLabアプリケーションに対してのみ機能し、他のサービスに対しては機能しません。

バンドルされていないウェブサーバーの使用

デフォルトでは、Omnibus GitLabはNGINXがバンドルされたGitLabをインストールします。 Omnibus GitLabは、gitlab-www 同じ名前のグループに存在するユーザーを介して gitlab-wwwWebサーバーへのアクセスを許可しますgitlab-www 。 外部WebサーバーからGitLabへのアクセスを許可するには、外部Webサーバーユーザーをグループに追加する必要が gitlab-wwwあります。

Apacheのような別のWebサーバーや既存のNGINXインストールを使用するには、次の手順を実行する必要があります：

  1. バンドルされているNGINXを無効にします。

    /etc/gitlab/gitlab.rb セットで： 

    nginx['enable'] = false

  2. バンドルされていないウェブサーバーのユーザー名を設定します。

    デフォルトでは、Omnibus GitLabには外部Webサーバユーザのデフォルト設定がないので、設定で指定する必要があります。 Debian/Ubuntuの場合、Apache/NGINXともにデフォルトユーザはwww-data 、RHEL/CentOSの場合はNGINXユーザはnginx。

    注意: 最初に Apache/NGINX をインストールしてウェブサーバユーザが作成されていることを確認してください。

    例えば、ウェブサーバのユーザがwww-dataであるとします。/etc/gitlab/gitlab.rb セットで： 

    web_server['external_users'] = ['www-data']

    注: この設定は配列なので、gitlab-www グループに追加するユーザーを複数指定できます。

    sudo gitlab-ctl reconfigure を実行して変更を有効にします。

    注意: SELinux を使用していて、Web サーバーが制限された SELinux プロファイルで動作している場合、Web サーバーの制限を緩める必要があるかもしれません。

    *注意: ウェブサーバユーザが外部ウェブサーバが使用するすべてのディレクト リに正しい権限を持っていることを確認してください。そうでない場合、failed (XX: Permission denied) while reading upstream エラーが発生します。

  3. バンドルされていないウェブサーバーを信頼できるプロキシのリストに追加します。

    通常、Omnibus GitLabでは、バンドルされているNGINXのreal_ip モジュールで設定されたものが、信頼されたプロキシのリストのデフォルトとなります。

    バンドルされていないWebサーバーの場合は、リストを直接設定する必要があります。 GitLabと同じマシン上にない場合は、WebサーバーのIPアドレスを含める必要があります。 そうしないと、ユーザーはWebサーバーのIPアドレスからサインインしたものとして表示されます。 

    gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]

  4. (オプション）Apacheを使用している場合、正しいGitLab Workhorseの設定を行います。

    注：以下の値はGitLab 8.2で追加されたものです。最新バージョンがインストールされていることを確認してください。

    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 を実行して変更を有効にします。

  5. 正しいウェブサーバー設定のダウンロード

    GitLabのレシピリポジトリにアクセスし、お好みのウェブサーバディレクトリの中にあるオムニバスの設定ファイルを探します。 SSLを使ってGitLabを提供するかどうかに応じて、適切な設定ファイルを選ぶようにしてください。変更する必要があるのは、YOUR_SERVER_FQDN 、自分のFQDNと、SSLを使う場合はSSLキーが現在ある場所だけです。また、ログファイルの場所を変更する必要があるかもしれません。

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'] = ['*', '[::]']
mattermost_nginx['listen_addresses'] = ['*', '[::]']
pages_nginx['listen_addresses'] = ['*', '[::]']

NGINXリッスンポートの設定

デフォルトでは、NGINX はexternal_url で指定されたポートをリッスンするか、暗黙のうちに適切なポート（HTTP の場合は 80、HTTPS の場合は 443）を使用します。 GitLab をリバースプロキシの背後で実行している場合は、リッスンするポートを別のものに上書きしたくなるかもしれません。 たとえば、ポート 8081 を使用する場合などです： 

nginx['listen_port'] = 8081

プロキシSSLのサポート

デフォルトでは、NGINXはexternal_urlにhttps://が含まれている場合にSSLを使うかどうかを自動検出します。リバースプロキシの後ろでGitLabを動かしている場合は、別のプロキシサーバーやロードバランサーでSSLを終了させるとよいでしょう。これを行うには、external_url にhttps:// が含まれていることを確認し、gitlab.rbに以下の設定を適用します： 

nginx['listen_port'] = 80
nginx['listen_https'] = false

他のバンドルされたコンポーネント(レジストリ、Pagesなど)もプロキシSSLに同様の戦略を使用します。 特定のコンポーネントの*_external_url をhttps:// で設定し、nginx[...] コンフィギュレーションの前にコンポーネント名を付けます。 例えば、レジストリの場合は以下のコンフィギュレーションを使用します： 

registry_external_url 'https://registry.example.com'

registry_nginx['listen_port'] = 80
registry_nginx['listen_https'] = false

同じフォーマットは、Pages (pages_ 接頭辞) や Mattermost (mattermost_ 接頭辞) にも使用できます。

特定のヘッダ (Host,X-Forwarded-Ssl,X-Forwarded-For,X-Forwarded-Portなど) を GitLab (と、使用している場合は Mattermost) に転送するように、リバースプロキシやロードバランサを設定する必要があるかもしれないことに注意してください。 このステップを忘れると、不適切なリダイレクトやエラー (「422 Unprocessable Entity」、「CSRF トークンの真正性を検証できません」など) が表示されるかもしれません。 詳細については、こちらをご覧ください：

HTTPストリクト・トランスポート・セキュリティの設定

デフォルトでは、GitLabはStrict Transport Securityを有効にし、ブラウザにHTTPSでのみウェブサイトにアクセスするように通知します。ブラウザはGitLabインスタンスに一度でもアクセスすると、ユーザーが明示的にhttp:// URLを入力している場合でも、安全でない接続を試行しないように記憶します。そのようなURLはブラウザによって自動的にhttps:// variantにリダイレクトされます。 

nginx['hsts_max_age'] = 31536000
nginx['hsts_include_subdomains'] = false

デフォルトでは1max_age 年に設定されており、これはブラウザがHTTPS経由でのみ接続することを記憶する期間 max_ageです。 0にmax_age 設定 max_ageすると、この機能は無効になります。 詳細については、以下を参照してください：

注意：HSTSの設定はGitLabのメイン・アプリケーションに対してのみ機能し、他のサービスに対しては機能しません。

Referrer-Policyヘッダーの設定

デフォルトでは、GitLab はすべてのレスポンスに対してReferrer-Policy ヘッダをstrict-origin-when-cross-origin に設定します。

これにより、同一オリジンリクエストのときはクライアントは完全なURLを参照元として送信しますが、クロスオリジンリクエストのときはオリジンのみを送信するようになります。

このヘッダーに別の値を設定するには 

nginx['referrer_policy'] = 'same-origin'

このヘッダーを無効にして、クライアントにデフォルト設定を使用させることもできます： 

nginx['referrer_policy'] = false

origin やno-referrer に設定すると、完全な参照 URL を必要とする GitLab のいくつかの機能が壊れてしまうことに注意しましょう。

Gzip圧縮の無効化

デフォルトでは、GitLabは10240バイト以上のテキストデータに対してGzip圧縮を有効にします。 この動作を無効にするには 

nginx['gzip_enabled'] = false
注： gzip の設定はメインのGitLabアプリケーションに対してのみ機能し、他のサービスに対しては機能しません。

カスタムSSL暗号の使用

デフォルトでは、GitLabはhttps://gitlab.com 、GitLabコミュニティによって貢献された様々なベストプラクティスを組み合わせたSSL暗号を使用しています。

しかし、gitlab.rbに追加することでssl暗号を変更することができます： 

  nginx['ssl_ciphers'] = "CIPHER:CIPHER1"

を実行し、reconfigureを実行します。

ssl_dhparam ディレクティブを有効にすることもできます。

まず、openssl dhparam -out dhparams.pem 2048でdhparams.pem を生成します。次に、gitlab.rb で、生成されたファイルへのパスを追加します： 

  nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem"

変更後、sudo gitlab-ctl reconfigureを実行します。

双方向SSLクライアント認証の有効化

ウェブクライアントに信頼できる証明書による認証を要求するには、gitlab.rbに追加して 2-way SSL を有効にします： 

  nginx['ssl_verify_client'] = "on"

を実行し、reconfigureを実行します。

SSLクライアント認証を設定するためにNGINXがサポートするこれらの追加オプションも設定できます： 

  nginx['ssl_client_certificate'] = "/etc/pki/tls/certs/root-certs.pem"
  nginx['ssl_verify_depth'] = "2"

変更後、sudo gitlab-ctl reconfigureを実行してください。

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

これらのカスタム設定は、gitlab.rb ファイルで同じ設定が定義されている場合、競合を引き起こす可能性があることに留意してください。

何らかの理由でGitLab用のNGINXserver ブロックにカスタム設定を追加する必要がある場合は、以下の設定を使用できます。 

# 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-ctl reconfigure を実行して NGINX の設定を書き換え、NGINX を再起動します。

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

備考

  • 新しいロケーションを追加する場合、以下の項目を追加する必要があります。 

     proxy_cache off;
 proxy_pass http://gitlab-workhorse;

    を文字列か NGINX 設定に追加してください。 これがないと、サブロケーションは 404 を返します。 GitLabCE Issue #30619を参照ください。

  • ルートの/ の場所や/assets の場所は、すでにgitlab-http.confに存在するため、追加することはできません。

NGINX設定へのカスタム設定の挿入

既存のサーバーブロックを含めるなど、NGINX設定にカスタム設定を追加する必要がある場合は、次の設定を使用できます。 

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

gitlab-ctl reconfigure を実行して NGINX の設定を書き換え、NGINX を再起動します。

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

カスタムエラーページ

custom_error_pages を使って GitLab のデフォルトエラーページのテキストを変更することができます。 これは 404 や 502 などの有効な HTTP エラーコードに使えます。

例として、以下のようにデフォルトの404エラーページを変更します。 

nginx['custom_error_pages'] = {
  '404' => {
    'title' => 'Example title',
    'header' => 'Example header',
    'message' => 'Example message'
  }
}

その結果、以下のような404エラーページが表示されます。

custom 404 error page

gitlab-ctl reconfigure を実行して NGINX の設定を書き換え、NGINX を再起動します。

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

既存のPassenger/NGINXを使ってGitLabをホストしたい場合でも、omnibusパッケージを使ってアップデートやインストールを行うことができる便利なケースもあります。

注意:NGINX を無効にすると、手動でnginx.confに追加しない限り、Grafana や Mattermost など、Omnibus に含まれている他のサービスにアクセスできなくなります。

設定

まず、組み込みのNGINXとPumaを無効にするために、/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']

変更を有効にするには、sudo gitlab-ctl reconfigure を実行してください。

注：8.16.0より古いバージョンを使用している場合、再設定を成功させるためには、Unicornサービスファイル(/opt/gitlab/service/unicorn)があれば手動で削除する必要があります。

Vhost (サーバーブロック)

次に、Passenger/NGINXのカスタムインストールで、以下のサイト設定ファイルを作成します： 

upstream gitlab-workhorse {
  server unix://var/opt/gitlab/gitlab-workhorse/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_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;
  }

  ## To access Grafana
  location /-/grafana/ {
    proxy_pass http://localhost:3000/;
  }

  error_page 502 /502.html;
}

上記の例のgit.example.com をあなたのサーバーのURLに更新することを忘れないでください。

注:403 forbiddenが表示される場合は、/etc/nginx/nginx.confでpassengerを有効にしていない可能性があります： 

# include /etc/nginx/passenger.conf;

ではsudo service nginx reload

nginx_status の有効化/無効化

デフォルトでは、127.0.0.1:8060/nginx_status に NGINX health-check エンドポイントが設定され、NGINX サーバーの状態を監視します。

以下の情報が表示されます。 

Active connections: 1
server accepts handled requests
 18 18 36
Reading: 0 Writing: 1 Waiting: 0
  • アクティブな接続 - 開いている接続の合計。
  • 数字は3つ。
    • すべての接続を受け付けました。
    • すべての接続を処理しました。
    • 処理したリクエストの総数。
  • 読み取り: NGINXはリクエストヘッダを読み取ります。
  • 書き込み: NGINXはリクエストボディの読み取り、リクエストの処理、またはクライアントへのレスポンスの書き込みを行います。
  • Waiting：キープアライブ接続。 この数はキープアライブタイムアウトに依存します。

設定オプション

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

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

このサービスが現在のインフラにとって有用でないと思われる場合は、このサービスを無効にすることができます： 

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

変更を有効にするには、sudo gitlab-ctl reconfigure を実行してください。

警告

ユーザーのアップロードにアクセスできるようにするには、NGINXユーザー（通常はwww-data）をgitlab-www グループに追加する必要があります。これは次のコマンドで実行できます： 

sudo usermod -aG gitlab-www www-data

テンプレート

Unicornの代わりにPassengerを設定することと、HTTPSがないこと（これは有効にできますが）以外は、これらのファイルはほとんど同じです：

新しい設定を読み込むためにNGINXを再起動することを忘れないでください（Debianベースのシステムの場合sudo service nginx restart）。

トラブルシューティング

400 Bad Request: Host ヘッダが多すぎます。

nginx['custom_gitlab_server_config'] の設定にproxy_set_header の設定がないことを確認し、代わりにgitlab.rb ファイルの‘proxy_set_headers’設定を使用してください。

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

GitLab 10から、Omnibus GitLabパッケージはデフォルトでTLSv1プロトコルをサポートしなくなりました。 このため、古いJavaベースのIDEクライアントでGitLabインスタンスとやりとりする際に接続のイシューが発生する可能性があります。このユーザーコメントで言及されているのと同様に、サーバーの暗号をアップグレードすることを強くお勧めします。

このサーバーの変更が不可能な場合は、/etc/gitlab/gitlab.rbの値を変更することで、以前の動作にデフォルトで戻すことができます： 

nginx['ssl_protocols'] = "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"

秘密鍵と証明書の不一致

NGINXのログにx509 certificate routines:X509_check_private_key:key values mismatch) （Omnibusのデフォルトでは/var/log/gitlab/nginx/current ）が表示される場合、秘密鍵と証明書の不一致が考えられます。

これを解決するには、正しい秘密鍵と証明書を一致させる必要があります。

鍵と証明書が正しいことを確認するには、秘密鍵と証明書のモジュラスが一致していることを確認します： 

/opt/gitlab/embedded/bin/openssl rsa -in /etc/gitlab/ssl/gitlab.example.com.key -noout -modulus | openssl sha1

/opt/gitlab/embedded/bin/openssl x509 -in /etc/gitlab/ssl/gitlab.example.com.crt -noout -modulus| openssl sha1

一致することを確認したら、NGINXを再設定してリロードする必要があります： 

sudo gitlab-ctl reconfigure
sudo gitlab-ctl hup nginx