GitLab Pages
(トップページはこちら) - (アプリケーションのデプロイとリリースを始める)
GitLab Pagesは、GitLabリポジトリから直接静的Webサイトを公開できる機能です。追加コストなしで、個人ブログからプロジェクトドキュメント、ビジネスサイトまで、幅広い用途に対応します。
対応環境
- ティア: Free、Premium、Ultimate（全プランで利用可能）
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
1. GitLab Pagesの特徴
GitLab Pagesは、以下の特徴を持つ静的サイトホスティングサービスです。
- GitLab CI/CDパイプラインによる自動デプロイ: コードをプッシュするだけで、自動的にサイトが更新されます
- 静的サイトジェネレータの完全サポート: Hugo、Jekyll、Gatsby、Middleman、Harp、Hexo、Brunchなど、主要なジェネレータに対応。もちろん、プレーンなHTML、CSS、JavaScriptも利用可能です
- GitLabインフラストラクチャ上で動作: 追加費用なしで利用できます
- カスタムドメインとSSL/TLS証明書: 独自ドメインの設定と、セキュアな通信が可能です
- 組み込み認証によるアクセス制御: サイトへのアクセスを制限できます
- 高い信頼性とスケーラビリティ: 個人サイトからビジネス、プロジェクトドキュメントまで、安定して動作します
なお、動的なサーバーサイド処理（.phpや.aspなど）には対応していません。
2. 始め方
GitLab Pagesでサイトを公開する方法は、複数用意されています。プロジェクトの状況や習熟度に応じて選択できます。
2.1. 新規サイトの作成方法
既存プロジェクトにPagesを追加する場合
-
GitLab UIを使用: UIから簡単な
.gitlab-ci.ymlを設定します。最も手軽な方法です -
.gitlab-ci.ymlをゼロから作成: CIファイルの作成と設定を学びながら、自分でカスタマイズします -
.gitlab-ci.ymlテンプレートを使用: あらかじめ用意されたCIテンプレートファイルを利用します
新規プロジェクトを作成する場合
- サンプルプロジェクトをフォーク: Pagesが既に設定済みのサンプルプロジェクトをフォークして、すぐに始められます
- プロジェクトテンプレートを使用: Pagesが設定済みのテンプレートから新規プロジェクトを作成します
2.2. 最小構成の例
以下は、最もシンプルな.gitlab-ci.ymlの例です。
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- main
この設定では、mainブランチにプッシュされたすべてのファイルをpublicフォルダにコピーし、GitLab Pagesで公開します。
静的サイトジェネレータを使用する場合の例（Hugoの場合）:
pages:
stage: deploy
image: registry.gitlab.com/pages/hugo:latest
script:
- hugo
artifacts:
paths:
- public
only:
- main
3. 仕組み
GitLab Pagesを使用するには、GitLabでプロジェクトを作成し、Webサイトのファイルをアップロードします。プロジェクトは、パブリック、内部、プライベートのいずれかに設定できます。
デフォルトでは、GitLabはリポジトリ内のpublicという特定のフォルダからWebサイトをデプロイします。カスタムフォルダを設定することも可能です。
サイトのデプロイには、GitLabの組み込みツールであるGitLab CI/CDを使用します。GitLab CI/CDは、.gitlab-ci.ymlというファイルに記述されたスクリプトを実行して、サイトをビルドし、GitLab Pagesサーバーに公開します。
設定ファイル内でpages: trueプロパティを持つユーザー定義のjobを作成すると、GitLabはそれがGitLab Pagesのデプロイであることを認識します。
3.1. ドメインの選択
GitLab Pagesのデフォルトドメイン（*.gitlab.io）を使用することも、独自ドメイン（example.comなど）を使用することもできます。独自ドメインを使用する場合は、ドメインのレジストラまたはコントロールパネルで管理者権限が必要です。
4. サイトの設定と管理
4.1. ドメイン名とURL
GitLab Pagesのデフォルトドメインは以下の形式です。
-
ユーザーページ:
username.gitlab.io -
グループページ:
groupname.gitlab.io -
プロジェクトページ:
username.gitlab.io/projectname
4.2. カスタムドメインとSSL/TLS証明書
独自ドメインやサブドメインを設定し、DNSレコードを構成できます。SSL/TLS証明書も設定可能です。
4.3. Let's Encrypt統合
GitLabが自動的に取得・更新するLet's Encrypt証明書でサイトを保護できます。手動での証明書管理は不要です。
4.4. リダイレクト
HTTPリダイレクトを設定して、あるページを別のページに転送できます。サイトのリニューアルやURL変更時に便利です。
5. アクセス制御
5.1. デフォルトドメインの場合
GitLab Pagesのデフォルトドメイン（.gitlab.io）を使用している場合、WebサイトはHTTPSで自動的に保護されます。独自のカスタムドメインを使用している場合は、オプションでSSL/TLS証明書を使用して保護できます。
5.2. GitLab.comを使用している場合
Webサイトはインターネット上で公開されます。アクセスを制限するには、GitLab Pagesアクセス制御を有効にします。
5.3. GitLab Self-Managedインスタンスを使用している場合
Webサイトは、システム管理者が選択したPages設定に従って、独自のサーバー上で公開されます。パブリックまたは内部に設定できます。
6. 高度な機能
6.1. ユニークドメイン
デフォルトでは、すべての新規プロジェクトでページのユニークドメインが使用されます。これは、同じグループ内のプロジェクトがCookieを共有しないようにするためです。
グループ内のすべてのプロジェクトは、デフォルトで同じドメイン（例: group.gitlab.io）を共有します。つまり、Cookieもグループ内のすべてのプロジェクトで共有されます。
各プロジェクトで異なるCookieを使用するには、プロジェクトのPagesユニークドメイン機能を有効にします。
プロジェクトメンテナーは、以下の手順でこの機能を無効にできます。
- 左サイドバーで検索またはジャンプを選択し、プロジェクトを見つけます
- デプロイ > Pagesを選択します
- Use unique domainチェックボックスをクリアします
- 変更を保存を選択します
6.2. プライマリドメイン
GitLab 17.8で導入されたプライマリドメイン機能を使用すると、カスタムドメインを使用している場合に、GitLab Pagesへのすべてのリクエストをプライマリドメインにリダイレクトできます。
プライマリドメインが選択されると、ユーザーは308 Permanent Redirectステータスを受け取り、ブラウザが選択されたプライマリドメインにリダイレクトされます。ブラウザはこのリダイレクトをキャッシュする場合があります。
前提条件
- プロジェクトに対して少なくともメンテナーロールが必要です
- カスタムドメインが設定されている必要があります
設定手順
- 左サイドバーで検索またはジャンプを選択し、プロジェクトを見つけます
- デプロイ > Pagesを選択します
- Primary domainドロップダウンリストから、リダイレクト先のドメインを選択します
- 変更を保存を選択します
6.3. ユーザー定義のジョブ名
GitLab 17.6で一般提供が開始された機能により、任意のジョブからPagesデプロイメントをトリガーできます。ジョブ定義にpagesプロパティを含めます。これは、trueに設定されたブール値、またはハッシュのいずれかです。
ブール値を使用する例
deploy-my-pages-site:
stage: deploy
script:
- npm run build
pages: true # これがPagesジョブであることを指定し、デフォルトのpublicディレクトリを公開します
ハッシュを使用する例
deploy-pages-review-app:
stage: deploy
script:
- npm run build
pages: # これがPagesジョブであることを指定し、デフォルトのpublicディレクトリを公開します
path_prefix: '_staging'
pagesという名前のジョブのpagesプロパティがfalseに設定されている場合、デプロイメントはトリガーされません。
pages:
pages: false
注意: パイプライン内にpath_prefixの値が同じPagesジョブが複数ある場合、最後に完了したジョブがPagesでデプロイされます。
6.4. 並列デプロイメント
レビューアプリを作成するなど、プロジェクトに対して同時に複数のデプロイメントを作成することが可能です。
この機能により、本番環境に影響を与えることなく、複数のブランチやマージリクエストを同時にプレビューできます。
7. デプロイメントのライフサイクル管理
7.1. デプロイメントの有効期限
GitLab 17.4で導入された機能により、Pagesデプロイメントが一定期間経過後に自動的に削除されるように設定できます。pages.expire_inで期間を指定します。
create-pages:
stage: deploy
script:
- npm run build
pages: # これがPagesジョブであることを指定し、デフォルトのpublicディレクトリを公開します
expire_in: 1 week
期限切れのデプロイメントは、10分ごとに実行されるcronジョブによって停止されます。停止されたデプロイメントは、同じく10分ごとに実行される別のcronジョブによって削除されます。
停止または削除されたデプロイメントは、Web上で利用できなくなります。同じURL設定で別のデプロイメントが作成されるまで、そのURLで404 Not foundエラーページが表示されます。
7.2. 停止したデプロイメントの復元
前提条件: プロジェクトに対して少なくともメンテナーロールが必要です。
- 左サイドバーで検索またはジャンプを選択し、プロジェクトを見つけます
- デプロイ > Pagesを選択します
- Deploymentsの近くにあるInclude stopped deploymentsトグルをオンにします
- 復元したいデプロイメントを展開し、Restoreを選択します
7.3. デプロイメントの削除
- 左サイドバーで検索またはジャンプを選択し、プロジェクトを見つけます
- デプロイ > Pagesを選択します
- Deploymentsの下で、削除したいデプロイメントの任意の領域を選択します
- Deleteを選択します
8. セキュリティに関する考慮事項
8.1. .を含むネームスペース
ユーザー名がtanakaの場合、GitLab PagesのWebサイトはtanaka.gitlab.ioに配置されます。GitLabではユーザー名に.を含めることができるため、suzuki.tanakaという名前のユーザーがsuzuki.tanaka.gitlab.ioというGitLab PagesのWebサイトを作成できます。これは事実上、tanaka.gitlab.ioのサブドメインになります。
JavaScriptを使用してWebサイトのCookieを設定する場合は注意が必要です。JavaScriptで手動でCookieを設定する安全な方法は、domainをまったく指定しないことです。
// 安全: このCookieはtanaka.gitlab.ioにのみ表示されます
document.cookie = "key=value";
// 安全でない: このCookieはtanaka.gitlab.ioとそのサブドメインに表示されます
// 先頭のドットの有無に関係ありません
document.cookie = "key=value;domain=.tanaka.gitlab.io";
document.cookie = "key=value;domain=tanaka.gitlab.io";
この問題は、カスタムドメインを使用しているユーザー、またはJavaScriptで手動でCookieを設定しないユーザーには影響しません。
8.2. 共有Cookie
デフォルトでは、グループ内のすべてのプロジェクトが同じドメイン（例: group.gitlab.io）を共有します。つまり、Cookieもグループ内のすべてのプロジェクトで共有されます。
各プロジェクトで異なるCookieを使用するには、プロジェクトのPagesユニークドメイン機能を有効にします。
9. 実践例
GitLab Pagesの高度な技術を学べる実例が公開されています。
9.1. iOSからブログに投稿
モバイルデバイスからGitLab Pagesブログに投稿する方法を学べます。外出先でもコンテンツを更新できる柔軟性が得られます。
9.2. GitLab CI: ジョブの実行制御
ジョブを順次実行、並列実行、またはカスタムパイプラインを構築する方法を学べます。複雑なビルドプロセスを効率的に管理できます。
9.3. GitLab CI: デプロイメントと環境
デプロイメントと環境の設定方法を学べます。本番、ステージング、開発環境を適切に管理できます。
9.4. Nanocでドキュメントサイトを構築
Nanoc、GitLab CI、GitLab Pagesを使用して新しいドキュメントサイトを構築する方法を学べます。大規模なドキュメントプロジェクトに適しています。
9.5. コードカバレッジレポートの公開
GitLab Pagesでコードカバレッジレポートを公開する方法を学べます。テスト結果を視覚的に共有できます。
10. GitLab Self-Managedインスタンスの管理
GitLab Self-Managedインスタンスを実行している場合は、管理手順に従ってPagesを設定します。
10.1. Helm Chart（Kubernetes）インスタンスでの設定
Helm chart（Kubernetes）でデプロイされたインスタンスでGitLab Pagesを設定するには、以下のいずれかを使用します。
-
gitlab-pagesサブチャート: GitLabのHelm Chartに含まれるサブチャートを使用します - 外部GitLab Pagesインスタンス: 別途構築した外部のGitLab Pagesインスタンスを使用します
11. よくある質問と制限事項
11.1. 制限事項
- 動的コンテンツ: サーバーサイドの動的処理（PHP、ASPなど）は使用できません
- ファイルサイズ: デプロイメントのサイズには制限があります（GitLab.comでは1GBまで）
- ビルド時間: CI/CDパイプラインのビルド時間には制限があります
11.2. トラブルシューティング
404エラーが表示される場合
-
publicフォルダが正しく生成されているか確認します -
.gitlab-ci.ymlのartifacts設定が正しいか確認します - デプロイメントが正常に完了しているか確認します
カスタムドメインが機能しない場合
- DNSレコードが正しく設定されているか確認します
- SSL/TLS証明書が有効か確認します
- ドメインの伝播に時間がかかる場合があります（最大24時間）
12. まとめ
GitLab Pagesは、追加コストなしで静的サイトをホスティングできる強力な機能です。GitLab CI/CDとの統合により、コードをプッシュするだけで自動的にサイトが更新されます。
主な利点
- コスト効率: 追加費用なしで利用可能
- 自動化: CI/CDパイプラインによる自動デプロイメント
- 柔軟性: 主要な静的サイトジェネレータに対応
- セキュリティ: HTTPS、アクセス制御、SSL/TLS証明書のサポート
- スケーラビリティ: 個人ブログから大規模ドキュメントまで対応
個人ブログ、プロジェクトドキュメント、ビジネスサイトなど、用途に応じて柔軟に活用できます。GitLabを既に使用しているなら、追加の設定なしですぐに始められます。