GitLab Pagesの管理

GitLab Pagesは、GitLabプロジェクトおよびグループの静的サイトホスティングを提供します。ユーザーがこの機能にアクセスできるようにするには、サーバー管理者がPagesを設定しておく必要があります。GitLab Pagesを使用すると、管理者は次のことが可能になります:

• カスタムドメインとSSL/TLS証明書を使用して、静的ウェブサイトを安全にホストする。
• GitLabの権限を通じてPagesサイトへのアクセスを制御するための認証を有効にする。
• マルチノード環境でオブジェクトストレージまたはネットワークストレージを使用して、デプロイをスケールする。
• レート制限とカスタムヘッダーを使用して、トラフィックをモニタリングおよび管理する。
• すべてのPagesサイトでIPv4およびIPv6アドレスをサポートする。

GitLab Pagesデーモンは個別のプロセスとして実行され、GitLabと同じサーバー上または独自の専用インフラストラクチャ上で設定できます。ユーザー向けドキュメントについては、GitLab Pagesを参照してください。

GitLab Pagesデーモン

GitLab Pagesは、GitLab Pagesデーモンを使用しています。これは、Goで記述された基本的なHTTPサーバーであり、外部IPアドレスをリッスンし、カスタムドメインとカスタム証明書をサポートしています。Server Name Indication（SNI）を使用した動的証明書をサポートし、デフォルトでHTTP2を使用してページを公開します。この仕組みを十分に理解するために、READMEを読むことをおすすめします。

カスタムドメインで使用する場合、Pagesデーモンは、ポート80および/または443でリッスンする必要があります。これは、ワイルドカードドメインでは必要ありません。

Pagesデーモンは、柔軟な方法で設定できます:

• GitLabと同じサーバーでPagesデーモンを実行し、secondary IP（セカンダリIP）でリッスンする。
• 別のサーバーでPagesデーモンを実行する。この場合、PagesデーモンをインストールしたサーバーにもPagesのパスが存在する必要があるため、ネットワーク経由で共有する必要があります。
• GitLabと同じサーバーでPagesデーモンを実行し、同じIP上の別のポートでリッスンする。この場合、ロードバランサーによるトラフィックのプロキシ処理が必要になります。このルートを選択する場合、HTTPSではTCPロードバランシングを使用する必要があります。TLS終端（HTTPSロードバランシング）を使用する場合、ユーザーが提供する証明書ではページを配信できません。HTTPの場合は、HTTPまたはTCPロードバランシングを使用できます。

このドキュメントでは、最初のオプションを前提として説明を進めます。カスタムドメインをサポートしていない場合、セカンダリIPは必要ありません。

前提要件

このセクションでは、GitLab Pagesを設定するための前提要件について説明します。

ワイルドカードドメイン

ワイルドカードドメインのPagesを設定する前に、次の準備が必要です:

1. GitLabインスタンスドメインのサブドメインではない、Pagesのドメインを用意します。

   GitLabドメイン	Pagesドメイン	動作可能？
   example.com	example.io	はい
   example.com	pages.example.com	いいえ
   gitlab.example.com	pages.example.com	はい

2. wildcard DNS record（ワイルドカードDNSレコード）を設定します。

3. オプション。HTTPSでPagesを提供する場合は、そのドメインのwildcard certificate（ワイルドカード証明書）を用意します。

4. （推奨されるオプション）ユーザーが独自にRunnerを用意しなくてもいいように、インスタンスRunnerを有効にします。

5. カスタムドメインの場合は、secondary IP（セカンダリIP）を用意します。

シングルドメインサイト

シングルドメインサイトのPagesを設定する前に、次の準備が必要です:

1. GitLabインスタンスドメインのサブドメインではない、Pagesのドメインを用意します。

   GitLabドメイン	Pagesドメイン	サポート対象
   example.com	example.io	はい
   example.com	pages.example.com	いいえ
   gitlab.example.com	pages.example.com	はい

2. DNS record（DNSレコード）を設定します。

3. オプション。HTTPSでPagesを提供する場合は、そのドメインのTLS certificate（TLS証明書）を用意します。

4. （推奨されるオプション）ユーザーが独自にRunnerを用意しなくてもいいように、インスタンスRunnerを有効にします。

5. カスタムドメインの場合は、secondary IP（セカンダリIP）を用意します。

Public Suffix Listにドメインを追加する

Public Suffix Listは、サブドメインの処理方法を決定するためにブラウザによって使用されます。GitLabインスタンスが一般ユーザーによるGitLab Pagesサイトの作成を許可している場合、これらのユーザーはページドメイン（example.io）上にサブドメインを作成することも許可されます。ドメインをPublic Suffix Listに追加すると、ブラウザがスーパーCookieを受け入れるのを防ぐことができます。

GitLab Pagesのサブドメインを登録するには、Submit amendments to the Public Suffix List（Public Suffix Listへの修正申請）に記載された手順に従います。たとえば、ドメインがexample.ioの場合、example.ioをPublic Suffix Listに追加するよう申請する必要があります。GitLab.comは、2016年にgitlab.ioを追加しました。

DNS設定

GitLab Pagesは、独自の仮想ホストで実行されることを想定しています。DNSサーバー/プロバイダーで、GitLabを実行しているホストを指すワイルドカードDNS Aレコードを追加します。たとえば、次のようなエントリになります:

*.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設定

ワイルドカードDNSを使用せずに、シングルドメインサイトのGitLab Pages DNSを設定するには、次の手順に従います:

1. /etc/gitlab/gitlab.rbにgitlab_pages['namespace_in_path'] = trueを追加して、この機能のGitLab Pagesフラグを有効にします。

2. DNSプロバイダーで、example.ioのエントリを追加します。example.ioをドメイン名に、192.0.0.0をIPアドレスのIPv4バージョンに置き換えます。次のようなエントリになります:

   example.io          1800 IN A    192.0.0.0

3. オプション。GitLabインスタンスにIPv6アドレスがある場合は、そのエントリを追加します。example.ioをドメイン名に、2001:db8::1をIPアドレスのIPv6バージョンに置き換えます。次のようなエントリになります:

   example.io          1800 IN AAAA 2001:db8::1

この例には、次の項目が含まれています:

• example.io: GitLab Pagesを提供するドメイン。

カスタムドメインの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とは異なるものを指定する必要があります。

設定

ニーズに応じて、4種類の方法でGitLab Pagesを設定できます。

次に、もっとも簡単な設定からもっとも高度な設定へと続く順番で、各設定例を紹介します。

ワイルドカードドメイン

次の設定は、GitLab Pagesを使用するための最小限のセットアップです。これは、このセクションで説明する他のすべての設定の基礎となります。この設定では、次のようになります:

• NGINXがすべてのリクエストをGitLab Pagesデーモンにプロキシします。
• GitLab Pagesデーモンは、パブリックインターネットを直接リッスンしません。

前提要件:

• ワイルドカードDNSの設定が完了している。

ワイルドカードドメインを使用するようにGitLab Pagesを設定するには、次の手順に従います:

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

   external_url "http://example.com" # external_url here is only for reference
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

この設定でアクセス可能になるURLスキームは、http://<namespace>.example.io/<project_slug>です。

概要については、How to Enable GitLab Pages for GitLab CE and EE（GitLab CEおよびEEでGitLab Pagesを有効にする方法）をご覧ください。

シングルドメインサイト

次の設定は、GitLab Pagesを使用するための最小限のセットアップです。これは、このセクションで説明する他のすべての設定の基礎となります。この設定では、次のようになります:

• NGINXがすべてのリクエストをGitLab Pagesデーモンにプロキシします。
• GitLab Pagesデーモンは、パブリックインターネットを直接リッスンしません。

前提要件:

• シングルドメインサイトのDNS設定が完了している。

シングルドメインサイトを使用するようにGitLab Pagesを設定するには、次の手順に従います:

1. /etc/gitlab/gitlab.rbで、GitLab Pagesの外部URLを設定し、機能を有効にします:

   external_url "http://example.com" # Swap out this URL for your own
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com
   
   # Set this flag to enable this feature
   gitlab_pages['namespace_in_path'] = true

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

この設定でアクセス可能になるURLスキームは、http://example.io/<namespace>/<project_slug>です。

TLS対応のワイルドカードドメイン

NGINXはすべてのリクエストをデーモンにプロキシします。Pagesデーモンはパブリックインターネットをリッスンしません。

前提要件:

• ワイルドカードDNSの設定が完了している。
• TLS証明書を所有している。ワイルドカードでも、要件を満たす他のタイプでもかまいません。

1. *.example.ioのワイルドカードTLS証明書とキーを/etc/gitlab/ssl内に配置します。

2. /etc/gitlab/gitlab.rbで、次のように設定します:

   external_url "https://example.com" # external_url here is only for reference
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be https://pages.example.com
   
   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へのアクセス制御を使用している場合は、GitLab PagesのシステムOAuthアプリケーションのリダイレクトURIを更新して、HTTPSプロトコルを使用します。

この設定でアクセス可能になるURLスキームは、https://<namespace>.example.io/<project_slug>です。

TLS対応のシングルドメインサイト

この設定では、NGINXはすべてのリクエストをデーモンにプロキシします。GitLab Pagesデーモンはパブリックインターネットをリッスンしません:

前提要件:

• シングルドメインサイトのDNS設定が完了している。
• ドメイン（例: example.io）をカバーするTLS証明書を所有している。

1. 前提要件にあるTLS証明書とキーを/etc/gitlab/sslに配置します。

2. /etc/gitlab/gitlab.rbで、GitLab Pagesの外部URLを設定し、機能を有効にします:

   external_url "https://example.com" # Swap out this URL for your own
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be https://pages.example.com
   
   pages_nginx['redirect_http_to_https'] = true
   
   # Set this flag to enable this feature
   gitlab_pages['namespace_in_path'] = true

3. TLS証明書およびキーのファイル名がドメイン名（例: example.io.crtやexample.io.key）と一致しない場合は、証明書とキーのファイルのフルパスを/etc/gitlab/gitlab.rbに追加します:

   pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
   pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"

4. Pagesへのアクセス制御を使用している場合は、GitLab PagesのシステムOAuthアプリケーションのリダイレクトURIを更新して、HTTPSプロトコルを使用します。

   GitLab PagesはOAuthアプリケーションを更新せず、デフォルトのauth_redirect_uriがhttps://example.io/projects/authに更新されます。再設定する前に、gitlab_pagesから/etc/gitlab/gitlab-secrets.jsonセクションを削除し、gitlab-ctl reconfigureを実行してください。詳細については、GitLab PagesがOAuthを再生成しないを参照してください。

5. ファイルを保存して、GitLabを再設定し、変更を有効にします。

この設定でアクセス可能になるURLスキームは、https://example.io/<namespace>/<project_slug>です。

TLS終端ロードバランサーを使用するワイルドカードドメイン

Amazon Web ServicesでGitLab POCをインストールする際に、この設定を使用します。この設定には、TLSを終端するクラシックロードバランサーが含まれており、このロードバランサーがHTTPS接続をリッスンして、TLS証明書を管理し、HTTPトラフィックをインスタンスに転送します。

前提要件:

• ワイルドカードDNSの設定が完了している。
• TLS終端ロードバランサーがある。

1. /etc/gitlab/gitlab.rbで、次のように設定します:

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

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

この設定でアクセス可能になるURLスキームは、https://<namespace>.example.io/<project_slug>です。

グローバル設定

以下の表では、LinuxパッケージインストールでPagesが認識するすべての設定項目について説明しています。これらのオプションは/etc/gitlab/gitlab.rbで調整でき、GitLabを再設定すると有効になります。

環境内でPagesデーモンの動作やコンテンツの提供方法をよりきめ細かく制御する必要がない限り、ほとんどの設定は手動で指定する必要はありません。

高度な設定

ワイルドカードドメインに加えて、GitLab Pagesがカスタムドメインで動作するように設定することもできます。この場合も、カスタムドメインでTLS証明書を使用する、使用しないの2つのオプションがあります。最も簡単なセットアップは、TLS証明書を使用しない方法です。いずれの場合も、secondary IP（セカンダリIP）が必要になります。IPv4アドレスとIPv6アドレスがある場合は、両方を使用できます。

カスタムドメイン

この設定では、Pagesデーモンを実行しており、NGINXが引き続きデーモンにリクエストをプロキシしますが、デーモンは外部からのリクエストを受け取ることができます。カスタムドメインはサポートされていますが、TLSはサポートされていません。

前提要件:

• ワイルドカードDNSの設定が完了している。
• セカンダリIPがある。

1. /etc/gitlab/gitlab.rbで、次のように設定します:

   external_url "http://example.com" # external_url here is only for reference
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com
   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['custom_domain_mode'] = 'http' # Enable custom domain

   IPv6を使用していない場合は、IPv6アドレスは省略できます。

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

この設定でアクセス可能になるURLスキームは、http://<namespace>.example.io/<project_slug>およびhttp://custom-domain.comです。

TLS対応のカスタムドメイン

この設定では、Pagesdaemonを実行しており、NGINXが引き続きデーモンにリクエストをプロキシしますが、デーモンは外部からのリクエストを受け取ることもできます。カスタムドメインとTLSをサポートしています。

前提要件:

• ワイルドカードDNSの設定が完了している。
• TLS証明書を所有している。ワイルドカードでも、要件を満たす他のタイプでもかまいません。
• セカンダリIP。

1. *.example.ioのワイルドカードTLS証明書とキーを/etc/gitlab/ssl内に配置します。

2. /etc/gitlab/gitlab.rbで、次のように設定します:

   external_url "https://example.com" # external_url here is only for reference
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be https://pages.example.com
   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
   gitlab_pages['custom_domain_mode'] = 'https' # Enable custom domain
   # 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へのアクセス制御を使用している場合は、GitLab PagesのシステムOAuthアプリケーションのリダイレクトURIを更新して、HTTPSプロトコルを使用します。

カスタムドメインの検証

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

ユーザーベースがプライベートであるか、または信頼できる場合は、検証要件を無効にできます:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. ユーザーにカスタムドメインの所有権を証明することを要求するチェックボックスをオフにします。この設定はデフォルトで有効になっています。

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

GitLab PagesのLet’s Encryptのインテグレーションを使用すると、カスタムドメインで提供されるGitLab PagesサイトにLet’s Encrypt SSL証明書を追加できます。

有効にするには、次の手順に従います:

1. 有効期限が近づいているドメインに関する通知を受信するメールアドレスを選択します。
2. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
3. 設定 > 設定を選択します。
4. Pagesを展開します。
5. 通知を受信するメールアドレスを入力し、Let’s Encryptの利用規約に同意します。
6. 変更を保存を選択します。

アクセス制御

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

アクセス制御は、PagesデーモンをGitLabのOAuthアプリケーションとして登録することで機能します。認証されていないユーザーがプライベートPagesサイトにアクセスするリクエストを行うたびに、PagesデーモンはユーザーをGitLabにリダイレクトします。認証に成功すると、ユーザーはトークン付きでPagesにリダイレクトされ、そのトークンはCookieに保持されます。Cookieはシークレットキーで署名されているため、改ざんを検出できます。

プライベートサイトのリソースを表示する各リクエストは、そのトークンを使用してPagesによって認証されます。Pagesは受信したリクエストごとにGitLab APIにリクエストを送り、ユーザーにそのサイトを閲覧する権限があるかどうかを確認します。

Pagesへのアクセス制御はデフォルトで無効になっています。有効にするには、次の手順に従います:

1. /etc/gitlab/gitlab.rbで、この設定を有効にします:

   gitlab_pages['access_control'] = true

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

3. これで、ユーザーはプロジェクトの設定からアクセス制御を設定できるようになります。

認証スコープを制限してPagesを使用する

Pagesデーモンが認証に使用するスコープを設定できます。デフォルトでは、Pagesデーモンはapiスコープを使用します。

たとえば、/etc/gitlab/gitlab.rbでスコープをread_apiに制限するには、次のように設定します:

gitlab_pages['auth_scope'] = 'read_api'

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

前提要件:

• アクセス制御を有効にしている。

Pagesが使用するスコープを変更するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. アプリケーションを選択します。
3. GitLab Pagesを展開します。
4. apiスコープのチェックボックスをオフにして、必要なスコープのチェックボックス（read_apiなど）をオンにします。
5. 変更を保存を選択します。

すべてのPagesサイトへの公開アクセスを無効にする

GitLabインスタンスでホストしているすべてのGitLab Pagesウェブサイトに対して、アクセス制御を適用できます。これにより、認証済みユーザーのみがアクセスできるようになります。この設定は、個々のプロジェクトでユーザーが設定したアクセス制御をオーバーライドします。

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

前提要件:

• インスタンスへの管理者アクセス権が必要です。
• この設定を管理者エリアに表示するには、まずアクセス制御を有効にする必要があります。

すべてのPagesサイトへの公開アクセスを無効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. Pagesサイトへの公開アクセスを無効にするチェックボックスをオンにします。
5. 変更を保存を選択します。

デフォルトで一意のドメインを無効にする

デフォルトでは、新しく作成されたすべてのGitLab Pagesサイトは、一意のドメインURL（例: my-project-1a2b3c.example.com）を使用します。これにより、同じネームスペース内の異なるサイト間でCookieが共有されなくなります。

このデフォルトの動作を無効にすると、新しいPagesサイトがパスベースのURL（例: my-namespace.example.com/my-project）を使用するようになります。ただし、このアプローチには、同じネームスペース内の異なるサイト間でCookieが共有されるリスクがあります。

この設定が制御するのは、新しいサイトのデフォルト動作だけです。ユーザーは、個々のプロジェクトでこの設定をオーバーライドできます。

前提要件:

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

デフォルトで一意のドメインを無効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. デフォルトで一意のドメインを有効にするチェックボックスをオフにします。
5. 変更を保存を選択します。

この設定は、新しいPagesサイトにのみ影響します。既存のサイトは、現在の一意のドメイン設定を保持します。

プロキシの背後で実行する

GitLabの他の機能と同様に、Pagesも外部インターネット接続がプロキシで制限されている環境で使用できます。GitLab Pagesにプロキシを使用するには、次の手順に従います:

1. /etc/gitlab/gitlab.rbで次のように設定します:

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

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

カスタム認証局（CA）を使用する

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

その場合は通常、次のようなエラーが表示されます:

Post /oauth/token: x509: certificate signed by unknown authority

Linuxパッケージインストールの場合、カスタムCAをインストールすることで、この問題を解決できます。

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

GitLab APIの呼び出し時に相互TLSをサポートする

GitLabの設定で相互TLSを必須にしている場合は、GitLab Pagesの設定にクライアント証明書を追加する必要があります。

証明書には次の要件があります:

• 証明書には、ホスト名またはIPアドレスがSubject Alternative Name（サブジェクトの別名）として指定されている必要があります。
• エンドユーザー証明書、中間証明書、ルート証明書をこの順序で含む完全な証明書チェーンが必要です。

証明書の共通名フィールドは無視されます。

前提要件:

• Linuxパッケージを使用してインスタンスをインストールしている必要があります。

GitLab Pagesサーバーで証明書を設定するには、次の手順に従います:

1. GitLab Pagesノードで、/etc/gitlab/sslディレクトリを作成し、キーと完全な証明書チェーンをそこにコピーします:

   sudo mkdir -p /etc/gitlab/ssl
   sudo chmod 755 /etc/gitlab/ssl
   sudo cp key.pem cert.pem /etc/gitlab/ssl/
   sudo chmod 644 key.pem cert.pem

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

   gitlab_pages['client_cert'] = ['/etc/gitlab/ssl/cert.pem']
   gitlab_pages['client_key'] = ['/etc/gitlab/ssl/key.pem']

3. カスタム認証局（CA）を使用している場合は、ルートCA証明書を/etc/gitlab/sslにコピーし、/etc/gitlab/gitlab.rbを編集する必要があります:

   gitlab_pages['client_ca_certs'] = ['/etc/gitlab/ssl/ca.pem']

   複数のカスタム認証局（CA）のファイルパスは、カンマで区切って指定します。

4. マルチノードのGitLab Pagesインストール環境を使用している場合は、すべてのノードでこれらの手順を繰り返します。

5. すべてのGitLabノードの/etc/gitlab/trusted-certsディレクトリに、完全な証明書チェーンファイルのコピーを保存します。

ZIP配信とキャッシュ設定

GitLab Pagesは、オブジェクトストレージを通じてZIPアーカイブのコンテンツを配信できます。ZIPアーカイブからコンテンツを配信する際のパフォーマンスを向上させるため、インメモリキャッシュを使用しています。次の設定フラグを変更することで、このキャッシュの動作を変更できます。

ZIPキャッシュの更新例

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

アーカイブがzip_cache_expirationに達すると、期限切れとマークされ、次回のzip_cache_cleanupの間隔が経過するとメモリから削除されます。

HTTP Strict Transport Security（HSTS）のサポート

HTTP Strict Transport Security（HSTS）は、gitlab_pages['headers']設定オプションを使用して有効にできます。HSTSは、攻撃者が後続の接続で暗号化なしの状態を強制できないように、アクセスしているウェブサイトが常にHTTPS経由でコンテンツを提供する必要があることをブラウザに通知します。これにより、ブラウザがHTTPSにリダイレクトされる前に、暗号化されていないHTTPチャンネル経由で接続を試みるのを防ぐことができるため、ページの読み込み速度の向上にもつながります。

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

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

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を再設定し、変更を有効にします。

デーモンの冗長なログの生成を有効にする

GitLab Pagesデーモンの冗長なログの生成を設定するには、次の手順に従います。

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

   gitlab_pages['log_verbose'] = true

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

相関IDを伝播させる

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. ページはデフォルトで/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サイトのグローバルな最大サイズを設定する

前提要件:

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

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

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. Maximum size of pages（ページの最大サイズ）に値を入力します。デフォルトは100です。
5. 変更を保存を選択します。

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

前提要件:

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

グループ内の各GitLab Pagesサイトの最大サイズを設定し、継承された設定をオーバーライドするには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > 一般を選択します。
3. Pagesを展開します。
4. Maximum size（最大サイズ）に値をMB単位で入力します。
5. 変更を保存を選択します。

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

前提要件:

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

プロジェクト内のGitLab Pagesサイトの最大サイズを設定し、継承された設定をオーバーライドするには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. デプロイ > Pagesを選択します。
3. Maximum size of pages（ページの最大サイズ）に、サイズをMB単位で入力します。
4. 変更を保存を選択します。

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

前提要件:

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

プロジェクトのGitLab Pagesカスタムドメインの最大数を設定するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. プロジェクトごとのカスタムドメインの最大数に値を入力します。カスタムドメイン数を無制限にする場合は、0を入力します。
5. 変更を保存を選択します。

並列デプロイのデフォルトの有効期限を設定する

前提要件:

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

並列デプロイが削除されるまでの、インスタンスのデフォルト期間を設定するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、管理者を選択します。
2. 設定 > 設定を選択します。
3. Pagesを展開します。
4. Default expiration for parallel deployments in seconds（並列デプロイのデフォルトの有効期限（秒））に値を入力します。並列デプロイをデフォルトで期限切れにしない場合は、0を入力します。
5. 変更を保存を選択します。

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

GitLab Pagesウェブサイトごとに、ファイルエントリ（ディレクトリやシンボリックリンクを含む）の総数は200,000に制限されています。

この制限は、GitLab Self-ManagedインスタンスでGitLab Railsコンソールを使用して更新できます。

詳細については、GitLabアプリケーションの制限を参照してください。

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

GitLab Pagesデーモンを別のサーバーで実行することで、メインアプリケーションサーバーの負荷を軽減できます。

別のサーバーでGitLab Pagesを設定するには、次の手順に従います:

1. オプション。アクセス制御を有効にするには、/etc/gitlab/gitlab.rbに次の内容を追加し、GitLab server（GitLabサーバー）を再設定します:

   アクセス制御を有効にした状態でGitLab Pagesを使用する予定がある場合は、最初のGitLabサーバーで有効にしてから、gitlab-secrets.jsonをコピーする必要があります。アクセス制御を有効にすると、新しいOAuthアプリケーションが生成され、その情報がgitlab-secrets.jsonに伝播されます。正しい順序で作業を行わないと、アクセス制御で問題が発生する可能性があります。

   gitlab_pages['access_control'] = true

2. GitLab server（GitLabサーバー）でシークレットファイルのバックアップを作成します:

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

3. GitLab server（GitLabサーバー）でPagesを有効にするには、/etc/gitlab/gitlab.rbに次の内容を追加します:

   pages_external_url "http://<pages_server_URL>"

4. 次のいずれかの方法でオブジェクトストレージを設定します:

   • オブジェクトストレージを設定し、GitLab Pagesのデータを移行する。
   • ネットワークストレージを設定する。

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

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

7. Pages server（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 server（GitLabサーバー）でカスタムUID/GIDを設定している場合は、Pages server（Pagesサーバー）の/etc/gitlab/gitlab.rbにも同じ設定を追加してください。そうしないと、GitLab server（GitLabサーバー）でgitlab-ctl reconfigureを実行した際に、ファイルの所有権が変更され、Pagesリクエストが失敗する原因になります。

9. Pages server（Pagesサーバー）でシークレットファイルのバックアップを作成します:

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

10. 個々のGitLab Pagesサイトでカスタムドメインを有効にするには、次のいずれかを使用してPages server（Pagesサーバー）を設定します:

    • カスタムドメイン
    • TLS対応のカスタムドメイン

11. /etc/gitlab/gitlab-secrets.jsonファイルをGitLab server（GitLabサーバー）からPages server（Pagesサーバー）にコピーします。

    # 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

12. 変更を有効にするには、Pages server（Pagesサーバー）を再設定します。

13. GitLab server（GitLabサーバー）で、/etc/gitlab/gitlab.rbを次のように変更します:

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

14. 個々のGitLab Pagesサイトでカスタムドメインを有効にするには、GitLab server（GitLabサーバー）で/etc/gitlab/gitlab.rbに次の変更を加えます:

    • カスタムドメイン

         gitlab_pages['custom_domain_mode'] = 'http' # Enable custom domain mode to http

    • TLS対応のカスタムドメイン

         gitlab_pages['custom_domain_mode'] = 'https' # Enable custom domain mode to https

15. 変更を有効にするには、GitLab server（GitLabサーバー）を再設定します。

負荷を分散させたい場合は、複数のサーバーでGitLab Pagesを実行できます。これを実現するには、DNSサーバーを設定してPagesサーバーの複数のIPを返すようにするか、IPレベルで動作するようにロードバランサーを設定するなど、標準的なロードバランシング手法を使用します。複数のサーバーでGitLab Pagesをセットアップする場合は、各Pagesサーバーに対して前述の手順を実行してください。

ドメインソース設定

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

デフォルトでは、GitLab Pagesは新しいドメインがリクエストされるたびに、内部のGitLab APIを使用します。APIに接続できない場合、Pagesは起動に失敗します。また、後続のリクエストを高速化するために、Pagesデーモンはドメイン情報をキャッシュします。

一般的な問題については、トラブルシューティングを参照してください。

GitLab APIキャッシュ設定

APIベースの設定では、Pagesの配信のパフォーマンスと信頼性を高めるために、キャッシュメカニズムを使用します。キャッシュ動作は、キャッシュ設定を変更することで変更できます。ただし、推奨値が設定されているため、必要な場合にのみ変更してください。これらの値を誤って設定すると、断続的または永続的なエラーが発生したり、Pagesデーモンが古いコンテンツを配信したりする可能性があります。

例:

• 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_が付きます。

S3互換接続設定

統合されたオブジェクトストレージ設定を使用する必要があります。

プロバイダーごとの使用可能な接続設定を参照してください。

Pagesデプロイをオブジェクトストレージに移行する

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

• ローカルストレージ
• オブジェクトストレージ

既存のPagesデプロイをローカルストレージからオブジェクトストレージに移行するには、次のコマンドを実行します:

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

PostgreSQLコンソールを使用して、進行状況を追跡し、すべてのPagesデプロイを正常に移行したことを確認できます:

• Linuxパッケージインストールの場合: sudo gitlab-rails dbconsole --database main。
• 自己コンパイルによるインストールの場合: 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ローカルストレージを無効にする

オブジェクトストレージを使用する場合は、不要なディスクの使用や書き込みを防ぐため、ローカルストレージを無効にできます:

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

   gitlab_rails['pages_local_store_enabled'] = false

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

マルチノード環境でPagesのネットワークストレージを有効にする

オブジェクトストレージは、ほとんどの環境において推奨される設定です。ただし、要件によってネットワークストレージが必要であり、別のサーバーでPagesを実行する必要がある場合は、次の手順に従います:

1. 使用する予定の共有ストレージボリュームが、プライマリサーバーと目的のPagesサーバーの両方にすでにマウントされ、使用可能であることを確認します。

2. 各ノードの/etc/gitlab/gitlab.rbに、次の設定を追加します:

   gitlab_pages['enable_disk'] = true
   gitlab_rails['pages_path'] = "/var/opt/gitlab/gitlab-rails/shared/pages" # Path to your network storage

3. Pagesを別のサーバーに切り替えます。

別のサーバーでPagesの設定が正常に完了した後、共有ストレージボリュームへのアクセスが必要なのはそのサーバーのみとなります。将来的に単一ノード環境へ移行する可能性を考慮し、共有ストレージボリュームはプライマリサーバーに引き続きマウントしておくことを検討してください。

ZIPストレージ

GitLab Pagesの基盤となるストレージ形式は、プロジェクトごとに1つのZIPアーカイブです。

これらのZIPアーカイブは、ローカルのディスクストレージ、またはオブジェクトストレージ（設定している場合）に保存できます。

Pagesサイトが更新されるたびに、ZIPアーカイブが保存されます。

バックアップ

GitLab Pagesは定期バックアップに含まれているため、追加のバックアップを個別に設定する必要はありません。

セキュリティ

クロスサイトスクリプティング攻撃を防ぐために、GitLab PagesをGitLabとは異なるホスト名で実行することを強くおすすめします。

レート制限

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

GitLab Pagesでは、次の種類のレート制限をサポートしています:

• source_ipごと: 1つのクライアント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: ホストしているPagesドメインごとに、1秒あたりのリクエスト数の最大しきい値を設定します。この機能を無効にするには、0に設定します。
• rate_limit_domain_burst: ホストしているPagesドメインごとに、リクエストが一度に多数発生する初期のタイミングで許可される、リクエスト数の最大しきい値を設定します。

TLS接続ベースのレート制限は、以下の設定を使用して適用されます:

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

特定のIP範囲（サブネット）がすべてのレート制限を回避できるようにするには、次の手順に従います:

• rate_limit_subnets_allow_list: すべてのレート制限を回避させるIP範囲（サブネット）を指定する許可リストを設定します。例: ['1.2.3.4/24', '2001:db8::1/32']。GitLab Pagesチャートの例が利用可能です。

IPv6アドレスには、128ビットのアドレス空間の中で大きなプレフィックスが割り当てられます。通常、プレフィックス長は少なくとも/64です。使用可能なアドレス数が多いため、クライアントのIPアドレスがIPv6の場合、IPv6アドレス全体ではなく、長さ64のIPv6プレフィックスに対して制限が適用されます。

送信元IPごとのHTTPリクエストレート制限を有効にする

1. /etc/gitlab/gitlab.rbに、次のようにレート制限を設定します:

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

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

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

1. /etc/gitlab/gitlab.rbに、次のようにレート制限を設定します:

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

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

送信元IPごとのTLS接続レート制限を有効にする

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接続レート制限を有効にする

1. /etc/gitlab/gitlab.rbに、次のようにレート制限を設定します:

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

2. ファイルを保存して、GitLabを再設定し、変更を有効にします。

関連トピック

• GitLab Pagesの管理のトラブルシューティング
• GitLab Pagesのユーザードキュメント
• カスタムドメインとSSL/TLS証明書
• GitLab Pagesへのアクセス制御
• ジョブアーティファクト
• OAuthプロバイダーインテグレーション
• GitLabアプリケーションの制限
• オブジェクトストレージ
• 並列デプロイ
• デフォルトフォルダーをカスタマイズする
• Pagesでのリダイレクト