- サービス固有のNGINX設定
- HTTPSの有効化
- HTTPSの手動設定
HTTP
リクエストを次のようにリダイレクトします。HTTPS
- デフォルトのポートとSSL証明書の場所を変更します。
- SSL証明書の更新
- デフォルトのプロキシヘッダーの変更
- GitLab
trusted_proxies
と NGINXreal_ip
モジュールの設定 - HTTP2プロトコルの設定
- バンドルされていないウェブサーバーの使用
- NGINXのリッスンアドレスまたはアドレスの設定
- NGINXリッスンポートの設定
- プロキシSSLのサポート
- HTTPストリクト・トランスポート・セキュリティの設定
- Referrer-Policyヘッダーの設定
- Gzip圧縮の無効化
- カスタムSSL暗号の使用
- 双方向SSLクライアント認証の有効化
- カスタムのNGINX設定をGitLabサーバーブロックに挿入します。
- NGINX設定へのカスタム設定の挿入
- カスタムエラーページ
- 既存のPassenger/NGINXインストールを使用する場合
- nginx_status の有効化/無効化
- テンプレート
- トラブルシューティング
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
HTTPSの有効化
デフォルトでは、Omnibus GitLab は HTTPS を使用しません。gitlab.example.com
で HTTPS を有効にするには、2 つのオプションがあります:
警告
NGINXの設定は、今後24ヶ月間はセキュアな接続を介してのみGitLabインスタンスと通信するようにブラウザやクライアントに伝えます。 HTTPSを有効にすることで、少なくとも今後24ヶ月間はインスタンスへのセキュアな接続を提供する必要があります。
HTTPSの手動設定
デフォルトでは、Omnibus GitLabはHTTPSを使用しません。
ドメインのHTTPSを有効にするには、gitlab.example.com
:
-
/etc/gitlab/gitlab.rb
でexternal_url
を編集します:# note the 'https' below external_url "https://gitlab.example.com"
-
/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
-
では、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-www
Webサーバーへのアクセスを許可しますgitlab-www
。 外部WebサーバーからGitLabへのアクセスを許可するには、外部Webサーバーユーザーをグループに追加する必要が gitlab-www
あります。
Apacheのような別のWebサーバーや既存のNGINXインストールを使用するには、次の手順を実行する必要があります:
-
バンドルされているNGINXを無効にします。
/etc/gitlab/gitlab.rb
セットで:nginx['enable'] = false
-
バンドルされていないウェブサーバーのユーザー名を設定します。
デフォルトでは、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
エラーが発生します。 -
バンドルされていないウェブサーバーを信頼できるプロキシのリストに追加します。
通常、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' ]
-
(オプション)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
を実行して変更を有効にします。 -
正しいウェブサーバー設定のダウンロード
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 トークンの真正性を検証できません」など) が表示されるかもしれません。 詳細については、こちらをご覧ください:
- https://stackoverflow.com/questions/16042647/whats-the-de-facto-standard-for-a-reverse-proxy-to-tell-the-backend-ssl-is-used
- https://websiteforstudents.com/setup-apache2-reverse-proxy-nginx-ubuntu-17-04-17-10/
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
すると、この機能は無効になります。 詳細については、以下を参照してください:
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エラーページが表示されます。
gitlab-ctl reconfigure
を実行して NGINX の設定を書き換え、NGINX を再起動します。
既存のPassenger/NGINXインストールを使用する場合
既存のPassenger/NGINXを使ってGitLabをホストしたい場合でも、omnibusパッケージを使ってアップデートやインストールを行うことができる便利なケースもあります。
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