GitLab Pages

GitLab Pagesでは、GitLabのリポジトリから静的ウェブサイトを直接公開できます。

静的ウェブサイト:

• GitLab CI/CDパイプラインを使用して自動的にデプロイします。
• 静的サイトジェネレーター（Hugo、Jekyll、Gatsbyなど）またはプレーンなHTML、CSS、JavaScriptをサポートします。
• GitLabが提供するインフラストラクチャ上で、追加費用なしで実行できます。
• カスタムドメインとSSL/TLS証明書に接続します。
• 組み込みの認証によってアクセスを制御します。
• 個人、ビジネス、またはプロジェクトのドキュメントサイトを確実にスケールします。

Pagesでウェブサイトを公開するには、Gatsby、Jekyll、Hugo、Middleman、Harp、Hexo、Brunchなどの静的サイトジェネレーターを使用します。Pagesは、プレーンなHTML、CSS、JavaScriptで直接記述されたウェブサイトもサポートしています。動的なサーバーサイドの処理（.phpや.aspなど）はサポートされていません。詳細については、静的ウェブサイトと動的ウェブサイトの比較を参照してください。

はじめに

GitLab Pagesのウェブサイトを作成するには:

GitLab Pagesのウェブサイトを更新するには:

詳細については、以下を参照してください:

GitLab Pagesを使用する

GitLab Pagesを使用するには、ウェブサイトのファイルをアップロードするプロジェクトをGitLabに作成する必要があります。これらのプロジェクトは、パブリック、内部、またはプライベートのいずれかになります。

デフォルトでは、GitLabはリポジトリ内のpublicという特定のフォルダーからウェブサイトをデプロイします。Pagesでデプロイするカスタムフォルダーを設定することもできます。GitLabで新しいプロジェクトを作成すると、リポジトリが自動的に利用可能になります。

サイトをデプロイするために、GitLabはGitLab CI/CDと呼ばれる組み込みツールを使用してサイトをビルドし、GitLab Pagesサーバーに公開します。GitLab CI/CDがこのタスクを実行するために実行するスクリプトのシーケンスは、.gitlab-ci.ymlという名前のファイルから作成されます。このファイルは作成と変更が可能です。設定ファイル内のpages: trueプロパティを持つユーザー定義のjobによって、GitLabはGitLab Pagesのウェブサイトをデプロイしていることを認識します。

GitLab Pagesのウェブサイトには、デフォルトドメイン、*.gitlab.io、または独自のドメイン（example.com）を使用できます。その場合、Pagesで設定するには、ドメインのレジストラ（またはコントロールパネル）の管理者である必要があります。

Pagesサイトへのアクセス

GitLab Pagesのデフォルトドメイン（.gitlab.io）を使用する場合、ウェブサイトは自動的に保護され、HTTPSで利用できます。独自のカスタムドメインを使用している場合は、オプションでSSL/TLS証明書を使用して保護することができます。

GitLab.comを使用している場合、ウェブサイトはインターネット上で公開されています。ウェブサイトへのアクセスを制限するには、GitLab Pagesアクセス制御を有効にします。

GitLab Self-Managedインスタンスを使用している場合、あなたのウェブサイトは、システム管理者が選択したPagesの設定に従って、あなた自身のサーバーで公開されます。システム管理者は、そのサイトを公開または非公開に設定できます。

Pagesの例

以下のGitLab Pagesウェブサイトの例では、独自のニーズに応じて使用したり適合したりするための高度なテクニックを学ぶことができます:

• iOSからGitLab Pagesブログに投稿する
• GitLab CI: ジョブを順番に実行する、ジョブを並列実行する、またはカスタムパイプラインをビルドする
• GitLab CI: デプロイと環境
• Nanoc、GitLab CI、 GitLab Pagesを使用して新しいGitLabドキュメントサイトをビルドする
• GitLab Pagesを使用してコードカバレッジレポートを公開する

GitLab Self-Managedインスタンス用のGitLab Pagesを管理する

GitLab Self-Managedインスタンスを実行している場合は、管理手順に従ってPagesを設定します。

GitLab Pagesの管理を開始する方法についてのチュートリアル動画をご覧ください。

Helm Chart（Kubernetes）インスタンスでGitLab Pagesを設定する

Helm Chart（Kubernetes）を使用してデプロイしたインスタンスでGitLab Pagesを設定するには、以下のいずれかを使用します:

• gitlab-pagesサブチャート。
• 外部のGitLab Pagesインスタンス。

GitLab Pagesのセキュリティ

.を含むネームスペース

ユーザー名がexampleの場合、GitLab Pagesウェブサイトは、example.gitlab.ioにあります。GitLabでは、ユーザー名に.を含めることができるため、bar.exampleというユーザーが、実質的にexample.gitlab.ioウェブサイトのサブドメインとなるGitLabPagesウェブサイトbar.example.gitlab.ioを作成することができます。JavaScriptを使用してウェブサイトのCookieを設定する場合は注意が必要です。JavaScriptでCookieを手動で設定する安全な方法は、domainをまったく指定しないことです:

// Safe: This cookie is only visible to example.gitlab.io
document.cookie = "key=value";

// Unsafe: This cookie is visible to example.gitlab.io and its subdomains,
// regardless of the presence of the leading dot.
document.cookie = "key=value;domain=.example.gitlab.io";
document.cookie = "key=value;domain=example.gitlab.io";

このイシューは、カスタムドメインを持つユーザーや、JavaScriptで手動でCookieを設定しないユーザーには影響しません。

共有Cookie

デフォルトでは、グループ内のすべてのプロジェクトは、group.gitlab.ioなどの同じドメインを共有します。これは、グループ内のすべてのプロジェクトでCookieも共有されることを意味します。

各プロジェクトで異なるCookieを使用するようにするには、プロジェクトのPagesの一意のドメイン機能を有効にします。

一意のドメイン

デフォルトでは、すべての新しいプロジェクトはページの一意のドメインを使用します。これは、同じグループのプロジェクトがCookieを共有しないようにするためです。

プロジェクトのメンテナーは、この機能を無効にできます:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. デプロイ > Pagesを選択します。
3. 一意のドメインを使用チェックボックスをオフにします。
4. 変更を保存を選択します。

URLの例については、GitLab Pagesのデフォルトドメイン名を参照してください。

プライマリドメイン

カスタムドメインでGitLab Pagesを使用する場合、GitLab Pagesへのすべてのリクエストをプライマリドメインにリダイレクトできます。プライマリドメインを選択すると、ユーザーは、選択したプライマリドメインにブラウザをリダイレクトする308 Permanent Redirect状態を受信します。ブラウザはこのリダイレクトをキャッシュする場合があります。

前提要件:

• プロジェクトのメンテナーロール以上を持っている必要があります。
• カスタムドメインが設定されている必要があります。

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. デプロイ > Pagesを選択します。
3. プライマリドメインドロップダウンリストから、リダイレクト先のドメインを選択します。
4. 変更を保存を選択します。

期限切れのデプロイ

pages.expire_inで期間を指定すると、一定期間が経過した後、Pagesデプロイが自動的に削除されるように設定できます:

create-pages:
  stage: deploy
  script:
    - ...
  pages:  # specifies that this is a Pages job and publishes the default public directory
    expire_in: 1 week

期限切れのデプロイは、10分ごとに実行されるcronジョブによって停止されます。その後、停止したデプロイは同じく10分ごとに実行される別のcronジョブによって削除されます。これを復元するには、停止したデプロイを復元するで説明されている手順に従ってください。

停止または削除されたデプロイは、Web上で利用できなくなります。同じURL設定で別のデプロイが作成されるまで、ユーザーにはそのURLで404 Not foundエラーページが表示されます。

以前のYAMLの例では、ユーザー定義のジョブ名を使用しています。

停止したデプロイを復元する

前提要件:

• プロジェクトのメンテナーロール以上を持っている必要があります。

まだ削除されていない停止したデプロイを復元するには、以下を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. デプロイ > Pagesを選択します。
3. デプロイの近くにあるInclude stopped deployments（停止したデプロイを含める）切替をオンにします。デプロイがまだ削除されていない場合は、リストに含まれているはずです。
4. 復元するデプロイを展開し、復元を選択します。

デプロイを削除する

デプロイを削除するには、以下を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. デプロイ > Pagesを選択します。
3. デプロイで、削除するデプロイの任意のエリアを選択します。デプロイの詳細が展開されます。
4. 削除を選択します。

削除を選択すると、デプロイはすぐに停止します。停止したデプロイは、10分ごとに実行されるcronジョブによって削除されます。

まだ削除されていない停止したデプロイを復元するには、停止したデプロイを復元するを参照してください。

ユーザー定義のジョブ名

任意のジョブからPagesデプロイをトリガーするには、ジョブ定義にpagesプロパティを含めます。これは、trueに設定されたブール値またはハッシュのいずれかになります。

たとえば、trueを使用します:

deploy-my-pages-site:
  stage: deploy
  script:
    - npm run build
  pages: true  # specifies that this is a Pages job and publishes the default public directory

たとえば、ハッシュをを使用します:

deploy-pages-review-app:
  stage: deploy
  script:
    - npm run build
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: '_staging'

pagesというジョブのpagesプロパティがfalseに設定されている場合、デプロイはトリガーされません:

pages:
  pages: false

並列デプロイ

プロジェクトの複数のデプロイを同時に作成する場合は（たとえば、レビューアプリを作成するなど）、並列デプロイのドキュメントを参照してください。