GitLabページの管理

  • GitLab EE 8.3で導入されました。
  • GitLab EE 8.5でTLSをサポートするカスタムCNAMEが導入されました。
  • GitLab PagesはGitLab 8.17でCommunity Editionに移植されました。
  • GitLab 11.8でサブグループプロジェクトのウェブサイトがサポートされました。

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

注：このガイドはOmnibus GitLabインストール用です。 GitLabをソースからインストールした場合は、ソースインストール用のGitLabPages管理を参照してください。

概要

GitLab PagesはGitLab Pagesデーモンを利用しています。これはGoで書かれたシンプルなHTTPサーバーで、外部のIPアドレスをリッスンし、カスタムドメインやカスタム証明書をサポートします。 SNIを通して動的な証明書をサポートし、デフォルトではHTTP2を使ってページを公開します。 GitLab Pagesの動作を完全に理解するために、READMEを読むことをお勧めします。

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

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

カスタムドメインをサポートしない場合、セカンダリIPは必要ありません。

前提条件

Pagesの設定に進む前に、以下のことが必要です：

  1. GitLabのインスタンスドメインのサブドメインを使用することはできません。
  2. ワイルドカードDNSレコードを設定します。
  3. (オプション）HTTPSでPagesを提供する場合は、そのドメインのワイルドカード証明書を用意してください。
  4. (オプションですが、推奨）共有ランナーを有効にすることで、ユーザーが自分のランナーを持参する必要がなくなります。
  5. (カスタムドメインのみ)セカンダリIPを持ちます。
注意：GitLabインスタンスとPagesデーモンが非公開ネットワークやファイアウォールの背後にデプロイされている場合、GitLab Pagesウェブサイトには、非公開ネットワークにアクセスできるデバイス/ユーザーのみがアクセスできます。

公開サフィックスリストへのドメインの追加

Public Suffix Listは、ブラウザがサブドメインをどのように扱うかを決定するために使用されます。 GitLabインスタンスで一般ユーザーがGitLab Pagesサイトを作成することを許可している場合、それらのユーザーがpagesドメイン(example.io)にサブドメインを作成することも許可されます。 Public Suffix Listにドメインを追加することで、ブラウザがsupercookieを受け付けないようにすることなどができます。

以下の手順に従って、GitLab Pagesのサブドメインを申請してください。 インスタンスンスンスのドメインがexample.ioの場合、example.io を公開サフィックスリストに追加するようリクエストしてください。 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::1

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

注意：GitLabドメインをユーザーページの提供に使ってはいけません。 詳しくはセキュリティのセクションを参照してください。

設定

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

以下の例は、最も簡単なセットアップから最も高度なものまでリストアップされています。 ワイルドカードDNSのセットアップは、すべての構成で必要とされるため、絶対的な最小要件です。

ワイルドカードドメイン

必要条件

URLスキーム：http://page.example.io

これは、Pagesを使用するための最小セットアップです。 これは、以下で説明する他のすべてのセットアップのベースとなります。 Nginxは、すべてのリクエストをデーモンにプロキシします。 Pagesデーモンは、外部からのリッスンを行いません。

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

    pages_external_url 'http://example.io'

  2. GitLabを再設定します。

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

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

必要条件

URLスキーム：https://page.example.io

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

  1. 証明書と鍵を/etc/gitlab/ssl

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

    pages_external_url 'https://example.io'

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

    ここで、pages-nginx.crt とpages-nginx.key はそれぞれSSL証明書と鍵です。

  3. GitLabを再設定します。

Dockerコンテナの追加設定

GitLab Pages デーモンは、Docker コンテナで実行するとマウントをバインドする権限を持っていません。 このイシューを克服するには、chroot の動作を変更する必要があります：

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

  2. GitLab Pagesのinplace_chroot をtrue ： 

    gitlab_pages['inplace_chroot'] = true
  3. GitLabを再設定します。
Note:inplace_chroot オプションは、Pages Access Controlのような他の機能では動作しないかもしれません。GitLab Pages READMEに注意点や回避策についての詳細があります。

グローバル設定

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

設定 説明
pages_external_url GitLab Pages にアクセスできる URL。プロトコル (HTTP / HTTPS) を含みます。https:// を使用する場合は、gitlab_pages['ssl_certificate'] とgitlab_pages['ssl_certificate_key']も設定する必要があります。
gitlab_pages[]  
access_control アクセス制御を有効にするかどうか。
api_secret_key GitLab APIの認証に使用する秘密鍵のファイルへのフルパス。 未設定の場合は自動生成されます。
artifacts_server GitLab Pagesでアーティファクトを表示できるようにしました。
artifacts_server_timeout アーティファクト・サーバーへのプロキシされたリクエストのタイムアウト（秒）。
artifacts_server_url アーティファクトリクエストのプロキシ先となる API URL。 デフォルトは GitLabexternal URL +/api/v4で、例えばhttps://gitlab.com/api/v4。
auth_redirect_uri GitLab で認証するためのコールバック URL。デフォルトはプロジェクトのサブドメインpages_external_url +/auth。
auth_secret 認証リクエストに署名するための秘密鍵です。 OAuth登録時にGitLabから自動的に取得する場合は空白のままにしておいてください。
dir 設定ファイルと秘密ファイルの作業ディレクトリ。
enable 現在のシステムで GitLab Pages を有効または無効にします。
external_http HTTP リクエストを提供する 1 つ以上のセカンダリ IP アドレスにバインドするように Pages を設定します。 複数のアドレスを、正確なポートとともに配列として指定できます (例:['1.2.3.4', '1.2.3.5:8063'].listen_httpの値を設定します)。
external_https HTTPS リクエストを提供する 1 つ以上のセカンダリ IP アドレスにバインドするように Pages を設定します。 複数のアドレスを、正確なポートとともに配列として指定できます (例:['1.2.3.4', '1.2.3.5:8063'].listen_httpsの値を設定します)。
gitlab_client_http_timeout GitLab APIのHTTPクライアント接続タイムアウトを秒単位で指定します（デフォルト：10秒）。
gitlab_client_jwt_expiry JWTトークンの有効期限を秒単位で指定します（デフォルト：30秒）。
gitlab_id OAuthアプリケーション公開ID。 PagesがGitLabと認証するときに自動的に入力されるように、空白のままにしておきます。
gitlab_secret OAuth アプリケーションの秘密。 Pages が GitLab で認証するときに自動的に入力されるように、空白のままにしておきます。
gitlab_server アクセス制御が有効な場合に認証に使用するサーバー。デフォルトは GitLabexternal_url。
headers 各レスポンスでクライアントに送信する追加の http ヘッダを指定します。
inplace_chroot bind-mounts をサポートしていないシステムでは、GitLab Pages にpages_path ディレクトリに chroot するように指示します。inplace chroot を使う際にはいくつかの注意点があります。詳しくは GitLab PagesREADMEを参照してください。
insecure_ciphers 3DESやRC4のような安全でない暗号スイートが含まれている可能性があります。
internal_gitlab_server APIリクエスト専用に使用される内部GitLabサーバーアドレス。 内部ロードバランサー経由でトラフィックを送信したい場合に便利です。 デフォルトはGitLabexternal_url。
listen_proxy Pagesはこれらのアドレスのネットワークソケットにバインドし、そこか らのリクエストを受け取ります。$nginx-dir/conf/gitlab-pages.confのproxy_pass の値を設定します。
log_directory ログディレクトリへの絶対パス。
log_format ログ出力フォーマット：text またはjson。
log_verbose 冗長ロギング、true/false。
max_connections HTTP、HTTPS、またはプロキシリスナーへの同時接続数を制限します。
metrics_address メトリクス要求をリッスンするアドレス。
redirect_http ページをHTTPからHTTPSにリダイレクトします。
sentry_dsn Sentryクラッシュレポーターの送付先。
sentry_enabled Sentryによるレポーターとロギングを有効にします。
sentry_environment Sentryのクラッシュレポートの環境。
status_uri ステータスページの URL パスは、例えば/@status.
tls_max_version SSL/TLSの最大バージョン（”ssl3”、”tls1.0”、”tls1.1”、または “tls1.2”）を指定します。
tls_min_version SSL/TLSの最小バージョン（”ssl3”、”tls1.0”、”tls1.1”、または “tls1.2”）を指定します。
use_http2 HTTP2 サポートを有効にします。
gitlab_pages['env'][]  
http_proxy PagesとGitLab間のトラフィックを仲介するためにHTTPプロキシを使用するようにGitLab Pagesを設定します。 Pagesデーモンを起動するときに環境変数http_proxy 。
gitlab_rails[]  
pages_domain_verification_cron_worker カスタムGitLab Pagesドメインの検証スケジュール。
pages_domain_ssl_renewal_cron_worker GitLabドメインのLet’s EncryptによるSSL証明書の取得と更新のスケジュールです。
pages_domain_removal_cron_worker 検証されていないカスタムGitLab Pagesドメインの削除スケジュール。
pages_path ページが保存されるディスク上のディレクトリで、デフォルトはGITLAB-RAILS/shared/pagesです。
pages_nginx[]  
enable NGINX内部にPages用のバーチャルホストserver{} ブロックを含めます。 NGINXがPagesデーモンにトラフィックをプロキシバックするために必要です。カスタムドメインを使用している場合など、Pagesデーモンがすべてのリクエストを直接受信する必要がある場合は、false に設定します。

高度な設定

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

カスタムドメイン

必要条件

URLスキーム：http://page.example.io およびhttp://domain.com

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

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

    pages_external_url "http://example.io"
nginx['listen_addresses'] = ['192.0.2.1']
pages_nginx['enable'] = false
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001::2]:80']

    ここで、192.0.2.1 はGitLabがリッスンしているプライマリIPアドレスで、192.0.2.2 と2001::2 はGitLab PagesデーモンがリッスンしているセカンダリIPです。IPv6がない場合は、IPv6アドレスを省略することができます。

  2. GitLabを再設定します。

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

必要条件

URLスキーム：https://page.example.io およびhttps://domain.com

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

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

    pages_external_url "https://example.io"
nginx['listen_addresses'] = ['192.0.2.1']
pages_nginx['enable'] = false
gitlab_pages['cert'] = "/etc/gitlab/ssl/example.io.crt"
gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001::2]:80']
gitlab_pages['external_https'] = ['192.0.2.2:443', '[2001::2]:443']

    ここで、192.0.2.1 はGitLabがリッスンしているプライマリIPアドレスで、192.0.2.2 と2001::2 はGitLab PagesデーモンがリッスンしているセカンダリIPです。IPv6を持っていない場合は、IPv6アドレスを省略することができます。

  2. GitLabを再設定します。

カスタムドメインの検証

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

ユーザーベースが非公開またはその他の方法で信頼されている場合、認証要件を無効にすることができます。管理エリア > 設定 > 環境設定]に移動し、[ページ]セクションで[カスタムドメインの所有権を証明するユーザーを要求する]のチェックを外します。 この設定はデフォルトで有効になっています。

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

GitLab 12.1で導入されました。

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

これを有効にするには、次のことが必要です：

  1. ドメインの期限切れに関する通知を受け取る電子メールを選択します。
  2. インスタンスの管理エリア > 設定 > 環境設定に移動し、Pages設定を展開します。
  3. 通知を受け取るための電子メールを入力し、以下のLet’s Encryptの利用規約に同意します。
  4. 変更を保存する］をクリックします。

Let's Encrypt settings

アクセス制御

GitLab 11.5で導入されました。

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. プロジェクトの設定で設定できるようになりました。
重要:マルチノード設定の場合、この設定を有効にするには、Sidekiqノードだけでなく、すべてのアプリノードにも適用する必要があります。

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

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

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

これは、Pagesウェブサイトで公開された情報を、インスタンスのユーザーだけに保存するのに便利です。 そのためには、次のようにします：

  1. インスタンスの管理エリア > 設定 > 環境設定に移動し、Pages設定を展開します。
  2. Pagesサイトへの公開アクセスを無効にする] チェックボックスをオンにします。
  3. 変更を保存する］をクリックします。
警告:この操作によって、現在公開されているすべてのウェブサイトが再デプロイされるまで非公開になるわけではありません。 このイシューは GitLab Pages の設定メカニズムを変更することで解決されます。

プロキシの後ろでの実行

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

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

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

  2. 変更を有効にするために GitLab を再設定します。

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

注：13.2以前では、Omnibusを使用する場合、回避策が必要でした。

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

通常、このようなエラーが発生します。Post /oauth/token: x509: certificate signed by unknown authority.

ソースからのインストールでは、カスタム認証局(CA) をシステム証明書ストアにインストールすることで修正できます。

Omnibusの場合は、Omnibus GitLabにカスタムCAをインストールすることで解決します。

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

冗長ロギングはOmnibus GitLab 11.1で導入されました。

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

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

    gitlab_pages['log_verbose'] = 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のプロキシリスナーを設定します。 Omnibus GitLab 11.1で導入されました。

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

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

    gitlab_pages['listen_proxy'] = nil

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

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

  2. GitLabを再設定します。

最大ページ数の設定

プロジェクトごとの解凍済みアーカイブの最大サイズは、Admin Area > Settings > Preferences >Pages のMaximum size of pages(MB)で設定できます。 デフォルトは100MBです。

プロジェクトまたはグループごとの最大Pagesサイズのオーバーライド

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

特定のプロジェクトのためにグローバルな最大ページサイズをオーバーライドするには：

  1. プロジェクトの設定 > Pagesページに移動します。
  2. ページの最大サイズを編集します。
  3. 変更を保存する］をクリックします。

特定のグループのグローバルな最大ページサイズを上書きするには

  1. グループの[設定]>[一般]ページに移動し、[Pages]を展開します。
  2. ページの最大サイズを編集します。
  3. 変更を保存する］をクリックします。

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

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

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

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

  1. GitLab サーバーでPages を有効にするには、/etc/gitlab/gitlab.rbに以下を追加します： 

    gitlab_pages['enable'] = true

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

    gitlab_pages['access_control'] = true

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

  4. GitLabサーバー上のsecretsファイルのバックアップを作成します： 

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

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

  6. 新しいサーバー上にNFS共有を作成し、この共有がメインのGitLabサーバーからアクセスできるように設定します。この例では、新しいサーバー上の共有フォルダーとしてデフォルトのGitLab Pagesフォルダー/var/opt/gitlab/gitlab-rails/shared/pages。これをGitLabサーバーの/mnt/pagesにマウントします。

  7. PagesサーバーにGitLabをインストールし、/etc/gitlab/gitlab.rb： 

    external_url 'http://<ip-address-of-the-server>'
pages_external_url "http://<your-pages-server-URL>"
postgresql['enable'] = false
redis['enable'] = false
prometheus['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
gitaly['enable'] = false
alertmanager['enable'] = false
node_exporter['enable'] = false
gitlab_rails['auto_migrate'] = false

  8. Pagesサーバー上の secrets ファイルのバックアップを作成します： 

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

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

  10. 変更を有効にするために GitLab を再設定します。

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

    gitlab_pages['enable'] = false
pages_external_url "http://<your-pages-server-URL>"
gitlab_rails['pages_path'] = "/mnt/pages"

  12. 変更を有効にするために GitLab を再設定します。

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

バックアップ

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

セキュリティ

XSS攻撃を防ぐために、GitLab PagesをGitLabとは異なるホスト名で実行することを強く考慮すべきです。

トラブルシューティング

open /etc/ssl/ca-bundle.pem: permission denied

GitLab Pagesはchroot jail内部で実行され、通常は/tmp/gitlab-pages-*のような一意に番号付けされたディレクトリで実行されます。

jail内部で、信頼された証明書のバンドルは、/etc/ssl/ca-bundle.pem。 それは、Pagesを起動する一部として、/opt/gitlab/embedded/ssl/certs/cacert.pemからそこにコピーされます。

ソースファイルの権限が正しくない場合(それらは、0644であるべきです)、chroot jail内部のファイルもまた、間違っているでしょう。

Pagesは/var/log/gitlab/gitlab-pages/current のようなエラーを記録します： 

x509: failed to load system roots and no roots provided
open /etc/ssl/ca-bundle.pem: permission denied

chroot jailの使用は、ルートファイルシステム上の/etc/ssl を参照していないので、このエラーを誤解を招きます。

修正方法は、ソースファイルの権限を修正し、Pagesを再起動することです： 

sudo chmod 644 /opt/gitlab/embedded/ssl/certs/cacert.pem
sudo gitlab-ctl restart gitlab-pages

dial tcp: lookup gitlab.example.com と x509: certificate signed by unknown authority

inplace_chroot とaccess_control の両方をtrueに設定すると、次のようなエラーが発生することがあります： 

dial tcp: lookup gitlab.example.com on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address

または: 

open /opt/gitlab/embedded/ssl/certs/cacert.pem: no such file or directory
x509: certificate signed by unknown authority

これらのエラーの原因は、resolv.conf とca-bundle.pem というファイルが chroot 内部にないことです。修正方法は、ホストの/etc/resolv.conf と GitLab の証明書バンドルを chroot 内部にコピーすることです： 

sudo mkdir -p /var/opt/gitlab/gitlab-rails/shared/pages/etc/ssl
sudo mkdir -p /var/opt/gitlab/gitlab-rails/shared/pages/opt/gitlab/embedded/ssl/certs/

sudo cp /etc/resolv.conf /var/opt/gitlab/gitlab-rails/shared/pages/etc
sudo cp /opt/gitlab/embedded/ssl/certs/cacert.pem /var/opt/gitlab/gitlab-rails/shared/pages/opt/gitlab/embedded/ssl/certs/
sudo cp /opt/gitlab/embedded/ssl/certs/cacert.pem /var/opt/gitlab/gitlab-rails/shared/pages/etc/ssl/ca-bundle.pem

プロジェクトを別のグループまたはユーザーに転送すると、404エラーが発生します。

プロジェクトを別のグループまたはユーザーに転送した後、Pagesサイトで404 Not Found エラーが発生した場合、Pagesのアドメイン設定を更新する必要があります。そのためには、.update ファイルに何かを記述します。Pagesデーモンはこのファイルの変更を監視し、変更が発生すると設定を再読み込みします。

Pagesでプロジェクトを転送した後、404 Not Found エラーを修正するには、この例を使用してください： 

date > /var/opt/gitlab/gitlab-rails/shared/pages/.update

Pagesストレージのパスをカスタマイズしている場合は、上記のコマンドを調整してカスタムパスを使用してください。