GitLabページの管理

GitLab Pagesは静的サイトのホスティングを可能にします。管理者による設定が必要です。別途ユーザー向けのドキュメントがあります。

note
このガイドはLinuxパッケージインストール用です。セルフコンパイルでGitLabをインストールしている場合は、GitLab Pages administration for self-compiled installationsを参照してください。

GitLab Pages デーモン

GitLab Pages はGitLab Pages デーモンを使っています。Go で書かれた基本的な HTTP サーバーで、外部 IP アドレスを listen することができ、カスタムドメインやカスタム証明書をサポートしています。Server Name Indication(SNI) を通して動的な証明書をサポートし、デフォルトでは HTTP2 を使ってページを公開します。READMEを読んで、どのように動作するかを完全に理解することをお勧めします。

カスタムドメイン(ワイルドカードドメインではない)の場合、Pagesデーモンはポート80 および/または443 をリッスンする必要があります。そのため、設定方法には柔軟性があります：

  • GitLabと同じサーバーでPagesデーモンを実行し、セカンダリIPで待ち受けます。
  • Pagesデーモンを別のサーバーで実行します。その場合、PagesデーモンがインストールされているサーバーにもPagesパスが存在しなければならないので、ネットワークを通して共有する必要があります。
  • GitLabと同じサーバーでPagesデーモンを実行し、同じIPでリッスンしますが、ポートは異なります。この場合、ロードバランサーを使ってトラフィックをプロキシする必要があります。そのルートを選択する場合は、HTTPS用にTCPロードバランシングを使うべきです。TLS終端(HTTPSロードバランシング)を使う場合、ユーザー提供の証明書ではページを提供できません。HTTPの場合はHTTPまたはTCPロードバランシングを使っても問題ありません。

この文書では、最初の選択肢を想定して進めます。カスタムドメインをサポートしない場合、セカンダリIPは必要ありません。

前提条件

Pagesの設定を行う前に、次のことが必要です：

  1. GitLab インスタンスのドメインのサブドメインではない Pages 用のドメインを持っていること。

    GitLabドメインページドメイン動作しますか？
    example.comexample.io {チェックサークル｝はい
    example.compages.example.com {点線円｝いいえ
    gitlab.example.compages.example.com {チェックサークル｝はい
  2. ワイルドカード DNS レコードを設定します。
  3. オプション。PagesをHTTPSで提供する場合は、そのドメインのワイルドカード証明書を用意します。
  4. 任意ですが、推奨します。共有ランナーを有効にすることで、ユーザーが自分のランナーを持参する必要がなくなります。
  5. カスタムドメインの場合は、セカンダリIPを用意してください。
note
GitLabインスタンスとPagesデーモンが非公開ネットワークまたはファイアウォールの背後にデプロイされている場合、GitLab Pagesウェブサイトは、非公開ネットワークにアクセスできるデバイス/ユーザーのみがアクセスできます。

ドメインを公開サフィックスリストに追加します。

公開サフィックスリストは、ブラウザがサブドメインをどのように扱うかを決定するために使われます。GitLabインスタンスでGitLab Pagesサイトの公開を許可している場合、そのユーザーはpagesドメイン(example.io)にサブドメインを作成することができます。公開サフィックス・リストにドメインを追加することで、とりわけブラウザがsupercookieを受け付けないようにすることができます。

以下の手順に従って、GitLab Pagesのサブドメインを申請してください。例えば、あなたのドメインがexample.ioの場合、example.io を公開サフィックス・リストに追加するようリクエストしてください。GitLab.comは2016年にgitlab.io 。

DNS設定

GitLab Pagesは自身のバーチャルホスト上で動作することを想定しています。DNSサーバー/プロバイダーで、ワイルドカードDNSA レコード をGitLabが動作するホストを指すように追加します。例えば、エントリーは次のようになります：

*.example.io. 1800 IN A    192.0.2.1
*.example.io. 1800 IN AAAA 2001:db8::1

example.io はGitLab Pagesが提供されるドメイン、192.0.2.1 はGitLabインスタンスのIPv4アドレス、2001:db8::1 はIPv6アドレスです。IPv6を持っていない場合は、AAAA レコードを省略することができます。

カスタムドメインのDNS設定

カスタムドメインのサポートが必要な場合、PagesルートドメインのすべてのサブドメインはセカンダリIP（Pagesデーモン専用）を指す必要があります。この設定をしないと、ユーザーはCNAME レコードを使ってカスタムドメインを GitLab Pages に向けることができません。

たとえば、次のようなエントリが考えられます：

example.com   1800 IN A    192.0.2.1
*.example.io. 1800 IN A    192.0.2.2

この例には以下のコンテナが含まれています：

  • example.com:GitLabドメイン。
  • example.io:GitLab Pagesが提供されるドメイン。
  • 192.0.2.1:GitLab インスタンスのプライマリ IP。
  • 192.0.2.2:GitLab Pages専用のセカンダリIP。プライマリIPとは異なる必要があります。
note
GitLabドメインをユーザーページの提供に使ってはいけません。詳しくはセキュリティセクションをご覧ください。

設定

必要に応じて、GitLab Pagesを4つの異なる方法で設定することができます。

以下の例は、最も簡単な設定から最も高度なものまでリストアップされています。ワイルドカードDNSはすべての設定に必要なので、最低限設定しておく必要があります。

ワイルドカードドメイン

要件

URLスキームhttp://<namespace>.example.io/<project_slug>

以下は、Pagesを使用できる最小限の設定です。以下に説明する他のすべてのセットアップのベースとなります。NGINXはすべてのリクエストをデーモンにプロキシします。Pagesデーモンは外部からの要求を聞きません。

  1. /etc/gitlab/gitlab.rb で GitLab Pages の内部 URL を設定します：

    external_url "http://gitlab.example.com" # external_url here is only for reference
pages_external_url "http://pages.example.com" # not a subdomain of external_url

  2. GitLab を再設定します。

この設定についてはビデオチュートリアルをご覧ください。

TLSをサポートするワイルドカードドメイン

要件

URLスキームhttps://<namespace>.example.io/<project_slug>

NGINXはすべてのリクエストをデーモンにプロキシします。Pagesデーモンは外部からの要求を聞きません。

  1. example.io の証明書と鍵を/etc/gitlab/sslの内部に配置します。

  2. /etc/gitlab/gitlab.rb 、以下の設定を指定します：

    external_url "https://gitlab.example.com" # external_url here is only for reference
pages_external_url "https://pages.example.com" # not a subdomain of external_url
   
pages_nginx['redirect_http_to_https'] = true

  3. 証明書と鍵にexample.io.crt とexample.io.key という名前を付けていない場合は、以下のようにフルパスも追加する必要があります：

    pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
  4. GitLab を再設定します。
  5. Pages Access Control を使っている場合は、GitLab PagesSystem OAuth アプリケーションのリダイレクト URI を HTTPS プロトコルを使うように更新します。
caution
一つのインスタンスに複数のワイルドカードを割り当てることはサポートされていません。割り当てられるワイルドカードは、インスタンスごとに 1 つだけです。
caution
リダイレクト URI に変更が加えられた場合、GitLab Pages は OAuth アプリケーションを更新しません。再設定する前に、/etc/gitlab/gitlab-secrets.jsonからgitlab_pages セクションを削除してから、gitlab-ctl reconfigureを実行してください。詳細については、GitLab Pages does not regenerate OAuthをお読みください。

TLS 終端ロードバランサーを使ったワイルドカードドメイン

要件

URLスキームhttps://<namespace>.example.io/<project_slug>

この設定は、主にAmazon Web ServicesにGitLab POCをインストールするときに使うことを想定しています。これには、HTTPS接続をリッスンし、TLS証明書を管理し、HTTPトラフィックをインスタンスに転送する、TLS終端の古典的なロードバランサーが含まれます。

  1. /etc/gitlab/gitlab.rb 、以下の設定を指定します：

    external_url "https://gitlab.example.com" # external_url here is only for reference
pages_external_url "https://pages.example.com" # not a subdomain of external_url
   
pages_nginx['enable'] = true
pages_nginx['listen_port'] = 80
pages_nginx['listen_https'] = false
pages_nginx['redirect_http_to_https'] = true

  2. GitLab を再設定します。

グローバル設定

以下は、LinuxパッケージのインストールでPagesが知っているすべての設定と、その動作の表です。これらのオプションは/etc/gitlab/gitlab.rbで調整することができ、GitLab を再設定した後に有効になります。これらの設定のほとんどは、あなたの環境でPagesデーモンがどのように実行され、どのようにコンテンツを提供するかをより細かく制御する必要がない限り、手動で設定する必要はありません。

設定説明
pages_external_urlプロトコル（HTTP / HTTPS）を含む、GitLab PagesにアクセスできるURL。https:// を使用する場合は、追加の設定が必要です。詳しくはTLSをサポートするワイルドカードドメインと TLSをサポートするカスタムドメインをご覧ください。
gitlab_pages[] 
access_control アクセス制御を有効にするかどうか。
api_secret_keyGitLab APIでの認証に使用するシークレットキーのファイルへのフルパス。未設定の場合は自動生成されます。
artifacts_serverGitLab Pagesでアーティファクトを表示できるようにします。
artifacts_server_timeoutアーティファクトサーバーへのプロキシされたリクエストのタイムアウト（秒）。
artifacts_server_urlアーティファクトリクエストのプロキシ先となる API URL。デフォルトはGitLabexternal URL +/api/v4 、例えばhttps://gitlab.com/api/v4。別のGitLabサーバーを実行している場合、このURLはメインのGitLabサーバーのAPIを指す必要があります。
auth_redirect_uriGitLabと認証するためのコールバックURL。デフォルトはプロジェクトのサブドメインpages_external_url +/auth 。
auth_secret認証リクエストに署名するためのシークレットキー。OAuth登録時にGitLabから自動的に取得する場合は空白のままにしてください。
dir設定ファイルとシークレットファイルの作業ディレクトリ。
enable現在のシステムで GitLab Pages を有効または無効にします。
external_http1つ以上のセカンダリIPアドレスにバインドし、HTTPリクエストを提供するようにPagesを設定します。複数のアドレスを、正確なポートとともに配列として指定することができます（例：['1.2.3.4', '1.2.3.5:8063'].listen_http の値を設定します。
external_httpsHTTPS リクエストに対応する 1 つ以上のセカンダリ IP アドレスにバインドするように Pages を設定します。複数のアドレスを、正確なポートとともに配列として指定できます (例['1.2.3.4', '1.2.3.5:8063'].) 。listen_https の値を設定します。
server_shutdown_timeoutGitLab Pages サーバーのシャットダウンタイムアウトを秒単位で設定します (デフォルト:30s)。
gitlab_client_http_timeoutGitLab API HTTP クライアント接続タイムアウト (秒) (デフォルト:10s)。
gitlab_client_jwt_expiryJWT トークンの有効期限 (秒) (デフォルト:30s)。
gitlab_cache_expiryドメインの設定がキャッシュに保存される最大時間 (デフォルト:600s)。
gitlab_cache_refreshドメインの設定がリフレッシュされる間隔（デフォルト：60s ）。
gitlab_cache_cleanup期限切れの項目がキャッシュから削除される間隔 (デフォルト:60s)。
gitlab_retrieval_timeoutリクエストごとに GitLab API からのレスポンスを待つ最大時間 (デフォルト:30s)。
gitlab_retrieval_intervalGitLab API経由でドメインの設定解決を再試行する前に待機する間隔 (デフォルト:1s)。
gitlab_retrieval_retriesAPI 経由でドメインの設定解決を再試行する最大回数 (デフォルト: 3)。
domain_config_sourceこのパラメータは14.0で削除されましたが、それ以前のバージョンではAPIドメイン設定ソースを有効にしてテストするために使用できます。
gitlab_idOAuth アプリケーション公開 ID。PagesがGitLabで認証するときに自動的に入力されるように、空白のままにしておいてください。
gitlab_secretOAuthアプリケーションのシークレット。PagesがGitLabで認証するときに自動的に入力されるように空白のままにします。
auth_scope認証に使用する OAuth アプリケーションのスコープ。GitLab Pages OAuthアプリケーションの設定と一致する必要があります。デフォルトでapi スコープを使用する場合は空白のままにしてください。
auth_cookie_session_timeout認証クッキーのセッションタイムアウトを秒単位で指定します (デフォルト:10m)。値が0 の場合、ブラウザセッション終了後にクッキーが削除されることを意味します。
gitlab_serverアクセス制御が有効な場合に認証に使用するサーバー。デフォルトは GitLabexternal_url 。
headers各レスポンスでクライアントに送信する追加の http ヘッダを指定します。複数のヘッダを配列で指定することも、ヘッダと値をひとつの文字列で指定することもできます。['my-header: myvalue', 'my-other-header: my-other-value']
enable_diskGitLab Pages デーモンがディスクからコンテンツを提供することを許可します。共有ディスクストレージが利用できない場合は無効にします。
insecure_ciphers3DESやRC4のような安全でない暗号スイートが含まれている可能性があります。
internal_gitlab_serverAPIリクエスト専用に使用されるGitLab内部サーバーアドレス。内部ロードバランサー経由でトラフィックを送りたい場合に便利です。デフォルトは GitLabexternal_url 。
listen_proxyリバースプロキシのリクエストをリッスンするアドレス。Pages はこれらのアドレスのネットワークソケットにバインドし、そこからのリクエストを受け取ります。$nginx-dir/conf/gitlab-pages.conf のproxy_pass の値を設定します。
log_directoryログディレクトリへの絶対パス。
log_formatログ出力フォーマット：text またはjson 。
log_verbose詳細ロギング、true/false。
propagate_correlation_id受信リクエストヘッダX-Request-ID に既存の Correlation ID があれば、それを再利用するために true (デフォルトは false) に設定します。リバースプロキシがこのヘッダを設定すると、その値はリクエストチェーンに伝搬されます。
max_connectionsHTTP, HTTPS あるいはプロキシリスナーへの同時接続数の制限。
max_uri_lengthGitLab Pagesが受け付けるURIの最大長。0に設定すると無制限になります。GitLab 14.5で導入されました。
metrics_addressメトリクスリクエストをリッスンするアドレス。
redirect_httpページを HTTP から HTTPS にリダイレクトします。
redirects_max_config_size _redirects ファイルの最大サイズをバイト単位で指定します (デフォルト: 65536)。
redirects_max_path_segments _redirects ルール URL で許可されるパスセグメントの最大数 (デフォルト: 25)。
redirects_max_rule_count _redirects で許可されるルールの最大数 (デフォルト: 1000)。
sentry_dsnSentryクラッシュレポートの送信先アドレス。
sentry_enabledSentryによるレポートとロギングを有効にします。
sentry_environmentSentryクラッシュレポートの環境。
status_uriステータスページのURLパス、例えば/@status 。
tls_max_version最大TLSバージョン（”tls1.2 “または “tls1.3”）を指定します。
tls_min_versionTLSの最小バージョン（”tls1.2 “または “tls1.3”）を指定します。
use_http2HTTP2 サポートを有効にします。
gitlab_pages['env'][] 
http_proxyPagesとGitLab間のトラフィックを仲介するためにHTTPプロキシを使用するようにGitLab Pagesを設定します。Pages デーモンを起動するときに環境変数http_proxy を設定します。
gitlab_rails[] 
pages_domain_verification_cron_workerGitLab Pagesのカスタムドメインを検証するためのスケジュール。
pages_domain_ssl_renewal_cron_workerGitLab PagesドメインのLet’s EncryptによるSSL証明書の取得と更新のスケジュール。
pages_domain_removal_cron_worker検証されていないカスタムGitLab Pagesドメインの削除スケジュール。
pages_pathページが保存されているディスク上のディレクトリ、デフォルトはGITLAB-RAILS/shared/pages 。
pages_nginx[] 
enableNGINX 内部の Pages 用のバーチャルホストserver{} ブロックを含めます。NGINXがトラフィックをPagesデーモンにプロキシするために必要です。カスタムドメインを使用する場合など、Pagesデーモンがすべてのリクエストを直接受信する必要がある場合は、false に設定します。
FF_CONFIGURABLE_ROOT_DIR デフォルトフォルダをカスタマイズする機能フラグ（デフォルトで有効）。
FF_ENABLE_PLACEHOLDERS書き換えの機能フラグ（デフォルトで有効）。詳しくは書き換えをご覧ください。
use_legacy_storage一時的に導入されたパラメータで、レガシードメイン設定のソースとストレージを使用することができます。14.3で削除されました。
rate_limit_source_ipソース IP ごとに、1 秒あたりのリクエスト数でレートを制限します。この機能を無効にするには、0 に設定します。
rate_limit_source_ip_burst送信元 IP ごとに、1 秒間に許可される最大バースト数でレートを制限します。
rate_limit_domainドメインごとのレート制限（1秒あたりのリクエスト数）。この機能を無効にするには、0 に設定します。
rate_limit_domain_burstRate limit per domain maximum burst allowed per second.
rate_limit_tls_source_ip1秒あたりのTLS接続数で、ソースIPごとのレート制限。この機能を無効にするには、0 に設定します。
rate_limit_tls_source_ip_burstRate limit per source IP maximum TLS connections burst allowed per second.
rate_limit_tls_domainドメインごとのレート制限（1秒あたりのTLS接続数）。この機能を無効にするには、0 に設定します。
rate_limit_tls_domain_burstRate limit per domain maximum TLS connections burst allowed per second.
server_read_timeoutリクエストヘッダとボディを読み取る最大時間。タイムアウトがない場合は、0 あるいは負の値を設定します。デフォルト：5s
server_read_header_timeoutリクエストヘッダを読み込む最大時間。タイムアウトがない場合は、0 あるいは負の値に設定します。デフォルト1s
server_write_timeoutデフォルト: 応答のすべてのファイルを書き込む最大時間。より大きなファイルはより多くの時間を必要とします。タイムアウトを設定しない場合は、0 負の 0値を設定します。0 デフォルト： 0
server_keep_aliveこのリスナーが受け入れるネットワーク接続のKeep-Alive 期間。0 の場合、Keep-Alive プロトコルとオペレーティング・システムでサポートされていれば有効 Keep-Aliveです。Keep-Alive 負の Keep-Alive場合は無効。デフォルト：15s

高度な設定

ワイルドカードドメインに加えて、GitLab Pagesをカスタムドメインで使えるように設定するオプションもあります。ここでも2つのオプションがあります: TLS証明書ありのカスタムドメインとTLS証明書なしのカスタムドメインです。一番簡単なのはTLS証明書なしの設定です。どちらの場合でも、セカンダリIPが必要です。IPv4アドレスだけでなくIPv6アドレスも持っていれば、両方を使用することができます。

カスタムドメイン

要件

URLスキーム：http://<namespace>.example.io/<project_slug> およびhttp://custom-domain.com

この場合、NGINXはデーモンへのリクエストをプロキシしますが、デーモンも外部からのリクエストを受け取ることができます。カスタムドメインはサポートされていますが、TLSはサポートされていません。

  1. /etc/gitlab/gitlab.rb 、以下の設定を指定します：

    external_url "http://gitlab.example.com" # external_url here is only for reference
pages_external_url "http://pages.example.com" # not a subdomain of external_url
nginx['listen_addresses'] = ['192.0.2.1'] # The primary IP of the GitLab instance
pages_nginx['enable'] = false
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # The secondary IPs for the GitLab Pages daemon

    IPv6をお持ちでない場合は、IPv6アドレスを省略できます。

  2. GitLab を再設定します。

TLSをサポートするカスタムドメイン

要件

URLスキーム：https://<namespace>.example.io/<project_slug> およびhttps://custom-domain.com

この場合、NGINXはデーモンへのリクエストをプロキシしますが、デーモンは外部からのリクエストも受け取ることができます。カスタムドメインとTLSがサポートされています。

  1. example.io の証明書と鍵を/etc/gitlab/sslの内部に配置します。

  2. /etc/gitlab/gitlab.rb 、以下の設定を指定します：

    external_url "https://gitlab.example.com" # external_url here is only for reference
pages_external_url "https://pages.example.com" # not a subdomain of external_url
nginx['listen_addresses'] = ['192.0.2.1'] # The primary IP of the GitLab instance
pages_nginx['enable'] = false
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # The secondary IPs for the GitLab Pages daemon
gitlab_pages['external_https'] = ['192.0.2.2:443', '[2001:db8::2]:443'] # The secondary IPs for the GitLab Pages daemon
# Redirect pages from HTTP to HTTPS
gitlab_pages['redirect_http'] = true

    IPv6をお持ちでない場合は、IPv6アドレスを省略できます。

  3. 証明書にexample.io.crt と鍵にexample.io.keyという名前を付けていない場合は、以下のようにフルパスも追加する必要があります：

    gitlab_pages['cert'] = "/etc/gitlab/ssl/example.io.crt"
gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
  4. GitLab を再設定します。
  5. Pages Access Control を使っている場合は、GitLab PagesSystem OAuth アプリケーションのリダイレクト URI を HTTPS プロトコルを使うように更新します。

カスタムドメインの検証

悪意のあるユーザーが自分のものではないドメインを乗っ取ることを防ぐため、GitLabはカスタムドメイン認証をサポートしています。カスタムドメインを追加する際、ユーザーはそのドメインのDNSレコードにGitLabが管理する認証コードを追加することで、そのドメインの所有者であることを証明する必要があります。

caution
ドメイン検証を無効にすることは安全ではなく、様々な脆弱性につながる可能性があります。無効にする場合は、Pagesのルートドメイン自体がセカンダリIPを指していないことを確認するか、ルートドメインをカスタムドメインとしてプロジェクトに追加してください。

そうでなければ、どのユーザーもこのドメインを自分のプロジェクトにカスタムドメインとして追加できます。ユーザーベースが非公開またはその他の方法で信頼されている場合は、検証要件を無効にできます：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左側のサイドバーで、[設定] > [環境設定]を選択します。
  4. ページを展開します。
  5. ユーザーにカスタムドメインの所有権を証明させる］チェックボックスをオフにします。この設定はデフォルトで有効になっています。

Let’s Encryptインテグレーション

GitLab 12.1 で導入されました。

GitLab PagesのLet’s Encryptインテグレーションにより、ユーザーはカスタムドメインの下で提供されるGitLab PagesサイトのためにLet’s Encrypt SSL証明書を追加することができます。

有効にするには:

  1. ドメインの期限切れに関する通知を受信するメールアドレスを選択します。
  2. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  3. Admin Areaを選択します。
  4. 左側のサイドバーで、[設定] > [環境設定]を選択します。
  5. ページを展開します。
  6. 通知を受け取るためのメールアドレスを入力し、Let’s Encrypt の利用規約に同意します。
  7. 変更を保存を選択します。

アクセス制御

GitLab Pagesのアクセスコントロールはプロジェクトごとに設定することができ、ユーザーのプロジェクトメンバーシップに基づいてPagesサイトへのアクセスをコントロールすることができます。

アクセスコントロールは、PagesデーモンをOAuthアプリケーションとしてGitLabに登録することで機能します。認証されていないユーザーから非公開 Pages サイトへのアクセス要求があると、Pages デーモンはそのユーザーを GitLab にリダイレクトします。認証に成功すると、ユーザーはトークンを受け取ってPagesにリダイレクトされ、トークンはクッキーに保存されます。クッキーは秘密鍵で署名されているので、改ざんを検知することができます。

非公開サイトのリソースを閲覧する各リクエストは、トークンを使ってPagesによって認証されます。受け取ったリクエストごとに GitLab API にリクエストを行い、ユーザーがそのサイトを読む権限があるかどうかを確認します。

Pagesのアクセスコントロールはデフォルトでは無効になっています。有効にするには

  1. /etc/gitlab/gitlab.rb で有効にしてください：

    gitlab_pages['access_control'] = true
  2. GitLab を再設定します。
  3. ユーザーはプロジェクトの設定でこれを設定できます。
note
この設定を複数ノードのセットアップで有効にするには、すべてのアプリノードとSidekiqノードに適用する必要があります。

認証範囲を縮小したPagesの使用

GitLab 13.10で導入されました。

デフォルトでは、Pages デーモンはapi スコープを使って認証します。これを設定することができます。例えば、/etc/gitlab/gitlab.rbのスコープをread_api に減らします：

gitlab_pages['auth_scope'] = 'read_api'

認証に使用するスコープは、GitLab Pages OAuthアプリケーションの設定と一致する必要があります。既存のアプリケーションのユーザーは GitLab Pages OAuth アプリケーションを変更する必要があります。以下の手順に従ってください：

  1. アクセス制御を有効にします。
  2. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  3. Admin Areaを選択します。
  4. 左サイドバーで「アプリケーション」を選択します。
  5. GitLab Pagesを展開します。
  6. api スコープのチェックボックスをクリアし、希望のスコープのチェックボックスを選択します（例：read_api ）。
  7. 変更を保存を選択します。

すべてのPagesサイトへの公開を無効にします。

GitLab 12.7から導入されました。

GitLabインスタンスでホストされているすべてのGitLab Pagesウェブサイトに対してアクセスコントロールを強制することができます。そうすることで、認証されたユーザーのみがアクセスできるようになります。この設定は、個々のプロジェクトでユーザーが設定したアクセスコントロールよりも優先されます。

これは、Pagesウェブサイトで公開される情報をインスタンスのユーザーのみに制限するのに役立ちます。そのためには

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左側のサイドバーで、[設定] > [環境設定]を選択します。
  4. ページを展開します。
  5. Pagesサイトへの公開を無効にする] チェックボックスを選択します。
  6. 変更を保存を選択します。

プロキシの後ろでの実行

GitLabの他の部分と同様に、Pagesは外部のインターネット接続がプロキシによってゲートされている環境でも使うことができます。GitLab Pagesでプロキシを使うには：

  1. /etc/gitlab/gitlab.rb で設定します：

    gitlab_pages['env']['http_proxy'] = 'http://example:8080'

  2. 変更を有効にするには、GitLabを再設定してください。

カスタム認証局の使用(CA)

カスタム認証局によって発行された証明書を使用する場合、カスタム認証局が認識されないと、アクセス制御と HTMLジョブアーティファクトのオンライン表示が機能しません。

これは通常、次のエラーになります:Post /oauth/token: x509: certificate signed by unknown authority.

Linuxパッケージのインストールでは、カスタムCAをインストールすることで解決します。

自己コンパイルインストールの場合は、カスタム認証局(CA) をシステム証明書ストアにインストールすることで解決できます。

ZIP配信とキャッシュの設定

GitLab 13.7 で導入されました。

caution
この説明では、GitLabインスタンスのいくつかの高度な設定を扱います。推奨されるデフォルト値はGitLab Pagesの中で設定されています。絶対に必要な場合のみ、これらの設定を変更してください。細心の注意を払ってください。

GitLab Pagesはオブジェクトストレージを通してZIPアーカイブからコンテンツを提供することができます（ディスクストレージのサポートにもイシューが存在します）。ZIP アーカイブからコンテンツを提供する際、パフォーマンスを向上させるためにインメモリキャッシュを使用します。以下の設定フラグを変更することで、キャッシュの動作を変更することができます。

設定説明
zip_cache_expirationZIP アーカイブのキャッシュ有効期限。古いコンテンツを提供しないためには、0より大きくなければなりません。デフォルトは60s 。
zip_cache_cleanupアーカイブが既に期限切れの場合にメモリから削除される間隔。デフ ォル ト は30s です。
zip_cache_refresh前にア ク セ ス さ れた場合に、 アーカ イブが メ モ リ 内で拡張 さ れる間隔zip_cache_expiration。こ れは zip_cache_expiration、 アーカ イブが メ モ リ 内で拡張 さ れてい る か ど う か を判断す る 際に使用 し ます。詳 し く は下記の例を参照 し て く だ さ い。デフォルトは30sです。
zip_open_timeoutZIPアーカイブを開くのに許される最大時間。大きなアーカイブや低速のネットワーク接続では、この時間を長くすると Pages の待ち時間に影響します。デフォルトは30秒です。
zip_http_client_timeoutZIP HTTP クライアントの最大時間。デフォルトは30m です。

ZIPキャッシュリフレッシュの例

アーカイブは，zip_cache_expiration より前にアクセスされ，期限切れまでの残り時間がzip_cache_refresh 以下の場合，キャッシュ内でリフレッシュされます（メモリに保持される時間が延長されます）。例えば、archive.zip が時刻0sにアクセスされた場合、60s で期限切れになります（zip_cache_expirationのデフォルト）。下の例では、15s の後にアーカイブを再度開いた場合、有効期限までの残り時間（45s）がzip_cache_refresh （デフォルトは30s）より長いため、リフレッシュされません。し か し 、45s の後にア ー カ イ ブに再びア ク セ ス さ れ る と （ア ー カ イ ブが最初に開かれた時点から）、 リ フ レ ッ シュ さ れます。これにより、アーカイブがメモリに残っている時間は45s + zip_cache_expiration (60s)から延長され、合計105sとなります。

アーカイブがzip_cache_expiration に達すると、それは期限切れとしてマークされ、次のzip_cache_cleanup の間隔で削除されます。

ZIP cache configuration

HTTPストリクト・トランスポート・セキュリティ(HSTS) サポート

HTTP Strict Transport Security(HSTS) は、gitlab_pages['headers'] 設定オプションで有効にできます。HSTS は、攻撃者がその後の接続を暗号化されずに強制できないようにするため、アクセスしているウェブサイトが常に HTTPS でコンテンツを提供するようブラウザに通知します。また、HTTPSにリダイレクトされる前に、ブラウザが暗号化されていないHTTPチャネルで接続しようとするのを防ぐため、Pagesの読み込み速度を向上させることができます。

gitlab_pages['headers'] = ['Strict-Transport-Security: max-age=63072000']

プロジェクトのリダイレクト制限ページ

GitLab 15.2 で導入されました。

GitLab Pagesには、_redirects ファイル 、パフォーマンスへの影響を最小限に抑えるためのデフォルトの制限セットが用意されています。制限を増やしたり減らしたりしたい場合は、これらの制限を設定することができます。

gitlab_pages['redirects_max_config_size'] = 131072
gitlab_pages['redirects_max_path_segments'] = 50
gitlab_pages['redirects_max_rule_count'] = 2000

環境変数を使う

Pagesデーモンに環境変数を渡すことができます（たとえば、機能フラグを有効または無効にするため）。

設定可能なディレクトリ機能を無効にするには：

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

    gitlab_pages['env'] = {
  'FF_CONFIGURABLE_ROOT_DIR' => "false"
}

  2. ファイルを保存して GitLab を再設定してください：

    sudo gitlab-ctl reconfigure

デーモンの冗長ロギングの有効化

GitLab Pages デーモンの冗長ロギングを設定するには、以下の手順に従ってください。

  1. デフォルトでは、デーモンはINFO レベルのログのみを記録します。DEBUG レベルのイベントをログに記録したい場合は、/etc/gitlab/gitlab.rb で設定する必要があります：

    gitlab_pages['log_verbose'] = true

  2. GitLab を再設定します。

相関 ID の伝播

GitLab 13.10で導入されました。

propagate_correlation_id をtrueに設定することで、リバースプロキシの背後にあるインストールが、GitLab Pagesに送信されたリクエストに相関IDを生成して設定できるようになります。リバースプロキシがヘッダ値X-Request-ID を設定すると、その値はリクエストチェーンに伝搬します。ユーザーは相関 ID をログで見つけることができます。

相関 ID の伝播を有効にするには、以下の手順に従います：

  1. /etc/gitlab/gitlab.rb でパラメータを true に設定します：

    gitlab_pages['propagate_correlation_id'] = true

  2. GitLab を再設定します。

ストレージパスの変更

GitLab Pagesのコンテンツが保存されるデフォルトパスを変更するには、以下の手順に従ってください。

  1. Pages はデフォルトで/var/opt/gitlab/gitlab-rails/shared/pages に保存されます。別の場所に保存したい場合は、/etc/gitlab/gitlab.rb で設定する必要があります：

    gitlab_rails['pages_path'] = "/mnt/storage/pages"

  2. GitLab を再設定します。

リバースプロキシリクエスト用のリスナーの設定

GitLab Pages のプロキシリスナーを設定するには、以下の手順に従ってください。

  1. デフォルトでは、リスナーはlocalhost:8090 のリクエストをリッスンする設定になっています。

    無効にしたい場合は/etc/gitlab/gitlab.rb で設定する必要があります：

    gitlab_pages['listen_proxy'] = nil

    別のポートをリッスンしたい場合は、/etc/gitlab/gitlab.rb で設定する必要があります：

    gitlab_pages['listen_proxy'] = "localhost:10080"

  2. GitLab を再設定します。

各GitLab Pagesサイトのグローバルな最大サイズを設定します。

前提条件

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトのグローバルな最大 Pages サイズを設定するには、以下の手順に従います：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左側のサイドバーで、[設定] > [環境設定]を選択します。
  4. ページを展開します。
  5. ページの最大サイズ] に値を入力します。デフォルトは100 です。
  6. 変更を保存を選択します。

グループ内の各GitLab Pagesサイトの最大サイズを設定します。

前提条件

  • インスタンスへの管理者アクセス権が必要です。

グループ内の各 GitLab Pages サイトの最大サイズを設定するには、継承された設定を上書きします：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. 左サイドバーで、設定 > 一般を選択します。
  3. ページを展開します。
  4. 最大サイズ（MB）]に値を入力します。
  5. 変更を保存を選択します。

プロジェクト内のGitLab Pagesサイトの最大サイズの設定

前提条件

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトで GitLab Pages サイトの最大サイズを設定するには、継承された設定を上書きします：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 左サイドバーで、[デプロイ] > [Pages]を選択します。
  3. Maximum size of pages（ページの最大サイズ）に、サイズをMB単位で入力します。
  4. 変更を保存を選択します。

プロジェクトのGitLab Pagesカスタムドメインの最大数の設定

前提条件

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトのGitLab Pagesカスタムドメインの最大数を設定するには：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、[設定] > [環境設定]を選択し、[ページ]を展開します。
  4. プロジェクトごとのカスタムドメインの最大数に値を入力します。ドメイン数を無制限にするには、0 。
  5. 変更を保存を選択します。

GitLab Pagesウェブサイトごとの最大ファイル数の設定

ファイルエントリーの総数（ディレクトリとシンボリックリンクを含む）は、GitLab Pagesウェブサイトごとに200,000 。

GitLab Railsコンソールを使って、セルフマネージドインスタンスの制限を更新することができます。

詳しくはGitLab application limits をご覧ください。

GitLab Pagesを別のサーバーで実行する場合

GitLab Pagesデーモンを別のサーバーで実行することで、メインのアプリケーションサーバーの負荷を減らすことができます。この設定は相互TLS（mTLS）をサポートしません。詳しくは対応する機能提案をご覧ください。

GitLab Pagesを別のサーバーで設定するには：

caution
以下の手順には、gitlab-secrets.json ファイルをバックアップして編集する手順が含まれています。このファイルには、データベースの暗号化を制御するシークレットが含まれています。注意してください。

  1. GitLab サーバー上にシークレットファイルのバックアップを作成します：

    cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.bak

  2. GitLabサーバーで、Pagesを有効にするために、/etc/gitlab/gitlab.rb ：

    pages_external_url "http://<pages_server_URL>"

  3. オプションで、アクセス制御を有効にするには、/etc/gitlab/gitlab.rbに以下を追加します：

    gitlab_pages['access_control'] = true

  4. オブジェクトストレージを設定し、ページデータをマイグレーションします。

  5. 変更を有効にするためにGitLab サーバーを再設定します。gitlab-secrets.json ファイルが新しい設定で更新されました。

  6. 新しいサーバーを設定します。これがPages サーバーになります。

  7. PagesサーバーにLinuxパッケージを使ってGitLabをインストールし、/etc/gitlab/gitlab.rb ：

    roles ['pages_role']
   
pages_external_url "http://<pages_server_URL>"
   
gitlab_pages['gitlab_server'] = 'http://<gitlab_server_IP_or_URL>'
   
## If access control was enabled on step 3
gitlab_pages['access_control'] = true

  8. GitLabサーバーでカスタムUID/GID設定をしている場合は、Pagesサーバーの /etc/gitlab/gitlab.rb 。そうしないと、GitLabサーバーで gitlab-ctl reconfigure 、ファイル所有者が変更され、Pagesリクエストが失敗することがあります。

  9. Pagesサーバー上のシークレットファイルのバックアップを作成してください：

    cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.bak

  10. GitLabサーバーから Pagesサーバーに/etc/gitlab/gitlab-secrets.json 。

    # On the GitLab server
cp /etc/gitlab/gitlab-secrets.json /mnt/pages/gitlab-secrets.json
   
# On the Pages server
mv /var/opt/gitlab/gitlab-rails/shared/pages/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json

  11. 変更を有効にするためにPagesサーバーを再設定します。

  12. GitLab サーバーで、/etc/gitlab/gitlab.rb に以下の変更を加えます：

    pages_external_url "http://<pages_server_URL>"
gitlab_pages['enable'] = false
pages_nginx['enable'] = false

  13. 変更を有効にするためにGitLab サーバーを再設定します。

GitLab Pagesを複数のサーバーで動作させ、負荷を分散させることができます。これは、Pagesサーバーに複数のIPを返すようにDNSサーバーを設定したり、IPレベルで動作するようにロードバランサーを設定したりといった、標準的なロードバランシングの方法で行うことができます。複数のサーバーで GitLab Pages をセットアップしたい場合は、それぞれの Pages サーバーで上記の手順を実行してください。

ドメインソースの設定

GitLab Pages デーモンがページのリクエストを処理するとき、まずどのプロジェクトがリクエストされた URL の処理に使われ、そのコンテンツがどのように保存されているかを特定する必要があります。

GitLab 13.3以前では、すべてのページのコンテンツは特別な共有ディレクトリに展開され、各プロジェクトは特別な設定ファイルを持っていました。Pages デーモンはこれらの設定ファイルを読み込み、その内容をメモリに保存していました。

このアプローチにはいくつかの欠点があり、新しいドメインがリクエストされるたびに GitLab 内部 API を使う GitLab Pages に置き換えられました。ドメイン情報はPagesデーモンによってキャッシュされ、その後のリクエストを高速化します。

GitLab 14.0からGitLab PagesはデフォルトでAPIを使用し、APIに接続できない場合は起動に失敗します。よくあるイシューについては、トラブルシューティングをご覧ください。

詳細はこちらのブログポストをご覧ください。

GitLab APIキャッシュの設定

GitLab 13.10で導入されました。

APIベースの設定は、Pagesを提供する際のパフォーマンスと信頼性を向上させるためにキャッシュ機構を使用します。キャッシュの動作はキャッシュの設定を変更することで変更できますが、推奨される値はあなたのために設定されたものであり、必要な場合にのみ変更してください。これらの値の設定が不適切な場合、断続的または持続的なエラーが発生したり、Pagesデーモンが古いコンテンツを提供したりすることがあります。

note
有効期限、インターバル、およびタイムアウトフラグは、Go durationフォーマットを使用します。継続時間文字列は、300ms、1.5h 、2h45mのような、オプションの分数と単位の接尾辞を持つそれぞれの10進数の符号付きシーケンスです。有効な時間単位は、ns、us （またはµs）、ms、s、m、h。

例：

  • gitlab_cache_expiry を増やすと、アイテムがキャッシュに長く存在するようになります。この設定はGitLab PagesとGitLab Rails間の通信が安定していない場合に有効です。

  • gitlab_cache_refresh を増やすと、GitLab Pages が GitLab Rails にドメインの設定をリクエストする頻度が減ります。この設定はGitLab PagesがGitLab APIへのリクエストを多く生成し、コンテンツが頻繁に変更されない場合に有効です。

  • gitlab_cache_cleanup を減らすと、キャッシュから期限切れのアイテムをより頻繁に削除し、Pages ノードのメモリ使用量を減らすことができます。

  • gitlab_retrieval_timeout を減らすと、GitLab Rails へのリクエストをより素早く止めることができます。増やすと、API からのレスポンスを受け取るまでの時間が長くなり、遅いネットワーク環境で役立ちます。

  • gitlab_retrieval_interval を減らすと、API へのリクエストをより頻繁に行うようになり、API からエラー応答があった場合（例えば接続タイムアウトなど）にのみリクエストが行われるようになります。

  • gitlab_retrieval_retries を減らすと、エラーを報告する前にドメインの設定を自動的に解決しようとする回数が減ります。

オブジェクトストレージ設定

オブジェクトストレージの設定は以下の通りです：

  • pages: の下にネストされ、セルフコンパイル・インストールではobject_store: の下にネストされます。
  • Linux パッケージインストールでは、pages_object_store_ がプレフィックスとなります。
設定説明デフォルト
enabledオブジェクトストレージが有効かどうか。false
remote_directoryPages サイトのコンテンツが保存されているバケットの名前。 
connection以下に説明する様々な接続オプション。 
note
NFSサーバーの使用を停止し、切断したい場合は、明示的にローカルストレージを無効にする必要があり、それはGitLab 13.11にアップグレードした後にのみ可能です。

S3互換接続設定

GitLab 13.2以降では、統合オブジェクトストレージ設定を使用する必要があります。このセクションでは、以前の設定フォーマットについて説明します。

各プロバイダーで利用可能な接続設定を参照してください。

Linux package (Omnibus)

  1. /etc/gitlab/gitlab.rb に以下の行を追加し、値を必要なものに置き換えてください：

    gitlab_rails['pages_object_store_enabled'] = true
gitlab_rails['pages_object_store_remote_directory'] = "pages"
gitlab_rails['pages_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
  'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
}

    AWS IAMプロファイルを使用する場合は、AWSアクセスキーとシークレットアクセスキー/値のペアを必ず省略してください：

    gitlab_rails['pages_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'use_iam_profile' => true
}

  2. ファイルを保存し、変更を有効にするためにGitLab を再設定してください。

  3. 既存の Pages デプロイをオブジェクトストレージにマイグレーションします。

Self-compiled (source)

  1. /home/git/gitlab/config/gitlab.yml を編集し、以下の行を追加または修正します：

    pages:
  object_store:
    enabled: true
    remote_directory: "pages" # The bucket name
    connection:
      provider: AWS # Only AWS supported at the moment
      aws_access_key_id: AWS_ACCESS_KEY_ID
      aws_secret_access_key: AWS_SECRET_ACCESS_KEY
      region: eu-central-1

  2. ファイルを保存してGitLab を再起動すると、変更が有効になります。

  3. 既存の Pages デプロイをオブジェクトストレージにマイグレーションします。

Pagesデプロイメントをオブジェクトストレージにマイグレーションします。

既存のPagesデプロイ・オブジェクト（zipアーカイブ）は、次のいずれかに保存できます：

既存のPagesデプロイをローカルストレージからオブジェクトストレージにマイグレーションします：

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

PostgreSQLコンソールを使用して、進捗を追跡し、すべてのPagesデプロイが正常にマイグレーションされたことを確認できます：

  • sudo gitlab-rails dbconsole GitLab 14.1以前を実行しているLinuxパッケージインストールの場合。
  • sudo gitlab-rails dbconsole --database main 14.2以降を実行しているLinuxパッケージインストール用。
  • sudo -u git -H psql -d gitlabhq_production セルフコンパイルインストールの場合。

以下のobjectstg (store=2) にすべての Pages デプロイのカウントがあることを確認してください：

gitlabhq_production=# SELECT count(*) AS total, sum(case when file_store = '1' then 1 else 0 end) AS filesystem, sum(case when file_store = '2' then 1 else 0 end) AS objectstg FROM pages_deployments;

total | filesystem | objectstg
------+------------+-----------
   10 |          0 |        10

すべてが正しく機能していることを確認したら、Pagesローカルストレージを無効にします。

Pagesデプロイをローカルストレージにロールバックします。

オブジェクトストレージへのマイグレーションが実行された後、Pagesデプロイをローカルストレージに戻すことができます：

sudo gitlab-rake gitlab:pages:deployments:migrate_to_local

Pagesローカルストレージを無効にします。

GitLab 13.11 で導入されました。

オブジェクトストレージを使用している場合、ローカルストレージを無効にすることで、不必要なディスクの使用や書き込みを避けることができます：

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

    gitlab_rails['pages_local_store_enabled'] = false

  2. 変更を有効にするには、GitLabを再設定してください。

ZIPストレージ

GitLab 14.0では、GitLab Pagesの基礎となるストレージフォーマットが、ディスクに直接保存されるファイルから、プロジェクトごとに単一のZIPアーカイブに変更されました。

これらのZIPアーカイブは、ディスクストレージにローカルに保存するか、設定されていればオブジェクトストレージに保存することができます。

GitLab 13.5からは、ページが更新されるたびにZIPアーカイブが保存されます。

バックアップ

GitLab Pagesは通常のバックアップの一部なので、個別にバックアップを設定する必要はありません。

セキュリティ

XSS攻撃を防ぐために、GitLab PagesをGitLabとは異なるホスト名で実行することを強く考慮する必要があります。

レート制限

サービス拒否（DoS）攻撃のリスクを最小限に抑えるために、レート制限を強制することができます。GitLab Pages は、トークンバケットアルゴリズムを使用してレート制限を実施します。デフォルトでは、指定された制限を超えるリクエストやTLS接続は報告されますが、拒否はされません。

GitLab Pages は以下のタイプのレート制限をサポートしています：

  • source_ip ごとに。単一のクライアントIPアドレスから許可されるリクエストやTLS接続の数を制限します。
  • domain ごとに。GitLab Pagesでホストされているドメインごとに許可されるリクエスト数やTLS接続数を制限します。example.comのようなカスタムドメインでも、group.gitlab.ioのようなグループドメインでもかまいません。

HTTP リクエストベースのレート制限は、以下を使用して実施されます：

  • rate_limit_source_ip:クライアント IP ごとに 1 秒あたりの要求数で最大しきい値を設定します。この機能を無効にするには、0 を設定します。
  • rate_limit_source_ip_burst:クライアント IP ごとに要求の最初の爆発で許可される要求数の最大しきい 値を設定します。たとえば、多数のリソースを同時にロードする Web ページをロードする場合などです。
  • rate_limit_domain:ホストされたページのドメインごとに、1 秒あたりの要求数 の最大しきい値を設定します。この機能を無効にするには0に設定します。
  • rate_limit_domain_burst:ホストされているページドメインごとのリクエストの最初の爆発で許可されるリクエスト数の最大しきい値を設定します。

TLSコネクションベースのレート制限は、以下を使用して実施されます：

  • rate_limit_tls_source_ip:1秒あたりのクライアントIPあたりのTLS接続数で最大しきい値を設定します。この機能を無効にするには0を設定します。
  • rate_limit_tls_source_ip_burst:クライアント IP ごとの TLS 接続の初期アウトバーストで許可される TLS 接続数の最大しきい値を設定します。たとえば、異なるウェブブラウザから同時にウェブページを読み込む場合などです。
  • rate_limit_tls_domain:1秒あたりのホストされたページドメインごとのTLS接続数の最大しきい値を設定します。この機能を無効にするには0に設定します。
  • rate_limit_tls_domain_burst:ホストされたページドメインごとのTLS接続の初期アウトバーストで許可されるTLS接続数の最大しきい値を設定します。

送信元IPによるHTTPリクエストのレート制限を有効にします。

GitLab 14.5 で導入されました。

  1. /etc/gitlab/gitlab.rbでレート制限を設定 ：

    gitlab_pages['rate_limit_source_ip'] = 20.0
gitlab_pages['rate_limit_source_ip_burst'] = 600

  2. GitLab を再設定します。

ドメインによるHTTPリクエストのレート制限を有効にします

GitLab 14.7 で導入されました。

  1. /etc/gitlab/gitlab.rbでレート制限を設定 ：

    gitlab_pages['rate_limit_domain'] = 1000
gitlab_pages['rate_limit_domain_burst'] = 5000

  2. GitLab を再設定します。

ソースIPによるTLS接続のレート制限を有効にします。

GitLab 14.9で導入されました。

  1. /etc/gitlab/gitlab.rbでレート制限を設定 ：

    gitlab_pages['rate_limit_tls_source_ip'] = 20.0
gitlab_pages['rate_limit_tls_source_ip_burst'] = 600

  2. GitLab を再設定します。

ドメインごとのTLS接続レート制限を有効に

GitLab 14.9で導入されました。

  1. /etc/gitlab/gitlab.rbでレート制限を設定 ：

    gitlab_pages['rate_limit_tls_domain'] = 1000
gitlab_pages['rate_limit_tls_domain_burst'] = 5000

  2. GitLab を再設定します。