「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

yasukazu

English⇒Japanese

shikimi

English⇒Japanese

ajhjhaf

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

【GitLab Pages 公式 を訳してみた】GitLab Pages 一般利用者ガイド

   GitLab DocumentationUser documentationProjectsGitLab Pages 説明書>GitLab Pages の 概要
 

  まず最初に

 

  GitLab Pagesは、無料で静的ウェブサイトをホスティングできるGitLabのサービスです。GitLab CIとGitLabランナーの力も借りて、ぜひあなた個人や、皆さんが所属しているグループのウェブページを作ってください。

  このページの終わりごろに『GitLab.comでGitLab Pagesを利用する』というコーナーがあります。
 そこでは、GitLab.comというクラウドサービスを使ってウェブサイトを作成する方法を詳しくお教えいたします。

  GitLabPagesについて、皆さんに知っていただきたいことをこちらのページにまとめました。
 (ウェブページ、記事、ガイド、ブログ、ビデオチュートリアルなど、様々なコンテンツがありますが)ぜひ、全部読んで、これからのウェブサイトの制作にお役立てください。

 

  GitLab Pagesの始め方

 注:この文章では、ドメインの説明に「example.io」を使っていきます。頭の中で皆さんのドメインに変換して考えてください。
 

  GitLabで作れるページには、主に2つの種類があります。
 *いずれもドメインですので、()内はすべて半角英数であることを念頭においてください

  • ユーザーごとのページ(ユーザー名.example.io)、グループごとのページ(グループ名.example.io
  • プロジェクトごとのページ(ユーザー名.example.io/プロジェクト名 あるいは グループ名.example.io/プロジェクト名


 GitLabでは、ユーザー名やグループ名を複数持つことはできない決まりになっていますが、名前空間を作ることは可能です。

 以下の表は、GitLab Pagesの種類ごとに、GitLab上に作られるプロジェクト名と、サイトのURLとを比較したものです。
 

GitLab Pagesの種類 GitLab上に作られるプロジェクト名 ウェブサイトの URL
ユーザーごとのページ username.example.io http(s)://username.example.io
グループごとのページ groupname.example.io http(s)://groupname.example.io
個人ユーザーがプロジェクトを有している場合 projectname http(s)://username.example.io/projectname
グループがプロジェクトを有している場合 projectname http(s)://groupname.example.io/projectname

 

  警告:名前空間で作成したドメインには、HTTPSの使用に制限があります。詳しくは、同文以下の『GitLab Pagesにおける制限』をご覧ください。

 

  GitLab Pagesで必要なもの

  GitLab Pagesでウェブサイトをアップロードするには、これらの工程が必要です。:

  1. 作成したページにたどり着くまでの一般ドメイン名を知ること。管理者に尋ねること。ほとんどこれが最重要事項なので、最初に聞いておく。
  2. プロジェクトを作成すること。
  3. レポジトリのルートディレクトリに.gitlab-ci.yml fileをプッシュすること。その際、 pagesというjobタスクグループを設定しておくことを忘れない。
  4. ランナーをウェブサイトのビルドに向けて設定すること。


 注:ランナーは、管理者から勧められたものがあるなら、なるべくそれを使用すること。

 

  ユーザーごとのページ、グループごとのページについて

  ユーザーやグループごとにウェブページを作成する場合、プロジェクト名と一般ドメイン名とにユーザー名やグループ名が冠されるのが普通です。
 たとえば、ユーザー名でプロジェクトを作成すると、「username.example.io」というレポジトリが作られます。
 ここでプロジェクト名をつけてプロジェクトを作った場合は、必ずしもユーザー名がつけられるわけではないので、それも考慮に入れておくとようでしょう。
 

  グループページも同様に、グループ名が入ったプロジェクト名とドメインとがつけられます。グループの名前空間の中にプロジェクトを作成すると、自動的にそのような設定になります。

(写真1)新しくプロジェクトを作る
 

  レポジトリの中に何らかの静的コンテンツをプッシュすると、GitLabランナーがGitLab CIの設定を元にアップロードします。
 あとは、「http(s)://username.example.io」などのアドレスでウェブサイトにアクセスして、出来栄えを確認しましょう。
 

  注:ユーザー名やグループ名にドット「.」がついている場合(「foo.bar」など)、ワイルドカードドメインでHTTPSが使えません。詳しくは同文以下『GitLab Pagesにおける制限』を読んでください。

 

  プロジェクト名からページを作る

  ユーザーアカウントでも、グループアカウントでも、名前の付いたプロジェクトを作成することは可能です。
 同じように、GitLab Pagesを利用する時にも、まずはプロジェクトを作成してからページの作成に取り掛かることができます。

 ウェブページの作り方自体は、ユーザー/グループごとに作るページと変わりません。:

  1. 新しくプロジェクトを作成する
  2. レポジトリのルートディレクトリに.gitlab-ci.yml fileをプッシュする。その際、 pagesというjobタスクグループを設定しておくことを忘れない。
  3. ランナーをウェブサイトのビルドに向けて設定する。


 そうして作られたプロジェクトは、「http(s)://username.example.io/projectname」あるいは、「http(s)://groupname.example.io/projectname」というようなドメインで配信される。
 

  プロジェクトから作成したウェブページがどのようなドメインになるかは、『GitLab Pages のこと全部教えます!①「静的ウェブサイトとは何か」「デフォルトのドメイン設定」』が参考になります。

 

  手っ取り早く始めるには

  まずは、GitLab Pagesが発表しているガイダンスや、GitLab.comでウェブサイトを公開する方法を映像で説明したビデオも公開されていますので、ぜひ内容をご確認ください。

  また、GitLab Pagesの機能についてさらに詳しく知りたい方は、GitLab Pagesのリソースリストから様々な記事にアクセスいただけます。

 

  .gitlab-ci.ymlファイルでできること

  GitLab Pagesを使う上でのかなめになるのが、.gitlab-ci.ymlファイルの設定です。これを使うことでビルドプロセスを効果的に操作できます。
 これからウェブサイトをビルドするうえで大切な、CI job の大まかな作り方を紹介します。

  GitLab Pages用の CI/CD 例は『【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます!④ 「GitLab CI を作成し、工夫する」』が参考になります。

 注:この説明を読むか前に、GitLab CIの使い方と、「.gitlab-ci.yml」ファイルのシンタックスについて目を通しておいてください。こちらのクイックスタートガイドが参考になります。

  GitLab Pages用の「.gitlab-ci.yml」を作成していく上で、守っていただきたいルールがあります。

  • pages」というGitLab Pagesでしか使われないjobを設定すること
  • GitLab Pagesで扱われる静的コンテンツは、すべて「public/」ディレクトリ配下に入れること
  • artifacts」というキーワードの下に、「public/」へのパスを設けること
     

  最も単純な設定例はこちらです。ひな型にしてください。

======================
pages:
 script:
 - my_commands
 artifacts:
  paths:
  - public
======================

  ランナーがページを組み立てるには、何にせよ「pages」jobがなくてはなりません。ビルドに必要なコマンド類は「script」パラメータに記入します。
 jobの成果が0ではなかった時に限り、「public/」ディレクトリにアップロードが行われ、GitLab Pagesに反映される仕組みです。

  「public/」ディレクトリには、皆さんのウェブサイトにある静的コンテンツを全て収蔵します。
 ウェブサイトを”技術的な意味で”どのように発表させるかについては、「script」パラメータを使います。

  Pagesはデフォルトの状態では、branch/tagに対応しておりません。ウェブページのデプロイは、基本的に「.gitlab-ci.yml」で定義したものにのみ従うようにされています。
 そこで、branchやtagにプッシュをしたいときには、コンフィグファイルの「only」パラメータをその通りに定義する必要があります。

 以下に示しますのは、masterブランチにプッシュがあったときにのみ、ウェブページをデプロイさせる設定です。
 

======================
pages:
 script:
 - my_commands
 artifacts:
  paths:
  - public
 only:
 - master
====================== 

  ウェブページを構築するパラメータは、すべて「pages」jobに入れることで始めて、ランナーは「これからウェブページをビルドするんだ」ということを感知できます。
 特に、「public/」ディレクトリについては、「pages」job配下に入れないと、ランナーが静的コンテンツの収容場所と認識してくれません。

 

  静的コンテンツを全部「public/」ディレクトリに入れる方法

 ごく一般的な静的サイトジェネレータなどを使っている場合などは、レポジトリ内には次のようなファイルがあることでしょう。

======================
├── index.html
├── css
│   └── main.css
└── js
└── main.js
======================

  拡張子を見ると、それぞれ「html、css、js。」これらはすべて静的コンテンツに当てはまりますね。だいたい、プロジェクトのrootディレクトリのどこかに収容されています。
 こういうものたちを「.gitlab-ci.yml」ファイルの設定で、ビルド時に「public/」ディレクトリに送付されるようにしなくてはなりません。

  以下はその一例です。
 「public/」ディレクトリをコピーし続ける無限ループを防止するために、「.public」のコピーを一時的に抑制する設定(- cp -r* .public)をしてあります。

======================
pages:
 script:
 - mkdir .public
 - cp -r * .public
 - mv .public public
 artifacts:
  paths:
  - public
 only:
 - master
======================

 

  とくに静的サイトジェネレータを使う時に必要な設定

  GitLab Pagesは、ほぼ全種類の静的サイトジェネレータに対応しています。
 「.gitlab-ci.yml」で静的サイトジェネレータを使う上で必要なコマンドを設定すると効率的です。

  サイトジェネレータのソースファイルは、Gitレポジトリのrootディレクトリに収納しましょう。
 どのジェネレータを使うかについては、主に「.gitlab-ci.yml」ファイルで設定します。

  たとえば、Jekyllサイトジェネレータを使う場合は、次のような設定が入ります。

======================
pages:                      # ビルドjobは「pages」にしなきゃだめ。
 script:
 - gem install jekyll      # Jekyllをインストールするコマンド
 - jekyll build -d public/ # Jekyllでサイトをビルドするコマンド。対象ディレクトリが「public/」になっている。
 artifacts:
  paths:
  - public                # これはランナーがウェブサイトのアップロード先を認識するのに必要。
 only:
 - master                  # 以上のスクリプトはmasterブランチにしか影響しないことを明示する。
======================

  このように、必要なライブラリをDockerコンテナで用意することがあります。
 他のプロジェクトならともかく、ウェブページを立ち上げる際には、ランナーでDockerエクゼキュータが使えることが求められるかもしれません。

  静的サイトジェネレータでサイトを作る時は、scriptの段階からして「public/」ディレクトリに全てのコンテンツが組み立てられるように注意しなくてはなりません。(例:- jekyll build -d public/)
 「paths:    - public」は、あくまでランナーだけを対象にした指令であることを忘れないでください。

 「script」に記載する、静的サイトジェネレータ向けのコマンドは、ソフトによって異なります。
 ディレクトリの指定方法を重点的に、各自で調べて入力してください。

 一部ジェネレータでは、ディレクトリを指定するオプションが存在しない可能性があります。その際は「script」に、結果ディレクトリを「public/」にするコマンドを挿入してください。
 

  そして「artifacts: paths:    - public」の入れ忘れで、ランナー自体がコンテンツの収容場所を認知できずに、ビルドが果たされないケースもよくあります。こちらも十分ご注意ください。

  jekyllの機能や仕組みについて、より理解を深めたい方はjekyll example projectをご覧ください。

  Pagesプロジェクトに簡単に導入できるジェネレータは、後述「プロジェクト実例」の章で紹介いたします。

 

  GitLab Pagesの「レポジトリ」を立ち上げるコマンド

  先ほど、GitLab Pagesはよほど「.gitlab-ci.yml」ファイルに定義しないかぎり、「branch/tag」を無視するように設計されていると述べました。
 「pages」jobが働くのは、onlyパラメータで定義されたブランチに更新があったときだけです。

  これらの条件を念頭に、ウェブページ用の独立ブランチ(仮に『pages』と名付ける)で、静的サイトジェネレータで作ったサイトをホストする手順をご紹介します。

 

  まずは、新しい空白ブランチを作成します。

======================
git checkout --orphan pages
====================== 

  最初のコミット時点では、rootディレクトリには何のファイルもプログラムもありません。もちろん、このままでは何の機能の果たしませんよ。

 そこで静的サイトジェネレータのバイナリを、このブランチに挿入するとサイトが一気に形に近づきます。

 バイナリの導入には「.gitlab-ci.yml」を使用します。
 ジェネレータがjekyllの場合は、次のようなコンフィグが基本となるでしょう。

======================
image: ruby:2.1

pages:
 script:
 - gem install jekyll
 - jekyll build -d public/
 artifacts:
  paths:
  - public
 only:
 - pages
====================== 

  同じJekyllをソースにしたウェブページといえども、masterブランチでビルドするものと、pagesブランチでビルドするものではソースファイルが違います。.gitlab-ci.ymlで指定する際には、ご注意ください。


 

  次の段階

  ウェブサイトのデプロイで大前提となる条件は以上です。うまくいったでしょうか?
  GitLab Pagesの更なる使い方を見てみましょう。

 

  例示プロジェクト

  GitLab Pagesでは、主に以下のようなジェネレータの例示プロジェクトを掲載しています。
 ごく普通のHTMLサイトから、様々な静的サイトジェネレータを扱っています。
 どれもたくさんの人にフォークされるものです。改良案がございましたら、ぜひコミットしてください。

  その他の例示プロジェクト: https://gitlab.com/groups/pages  

 
 

  制作したウェブサイトに独自ドメインをつける

  Pagesのドメイン変更方法については、『GitLab Pages のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」』に詳細な情報がありますが、ここではGitLabのUIを使って、ドメインを変更する手順を追っていきます。

  まず、この操作には、皆さんがGitLabプロジェクトの管理者であることが求められます。
 皆さんがウェブページプロジェクトの管理者なら、プロジェクト設定画面の「Pages」という項目の右上に、「+ New Domain」ボタンが表示されているはずです。

  (写真1) 「+ New Domain」ボタン

  GitLabでホストしているウェブサイトを示すドメインは、複数個を登録することができます。
 一度登録したドメインは、「Domains」という項目にまとめて表示されます。
 (写真2)「Domains」に表示されたドメイン
 

  最後に、DNS設定と、CNAMEをuser/groupページを指すように登録します。
 ドメイン横の「Details」ボタンをクリックしてください。
  (写真3)DNS設定画面

 注:独自ドメインは現在、プロジェクトごとに登録する形態をとっております。たとえば、「username.example.io/foo」というドメインがついているPagesプロジェクトがあったとします。ここに独自ドメイン(例:example.com)を追加すると、ユーザーのウェブサイト(username.example.io)のプロジェクトのドメインが変更されることになるので、元の「username.example.io/foo」ではプロジェクトにアクセスできなくなります。

 

  TLS証明書で独自ドメインをより安全に運用する

  新たに独自ドメインを登録した方は、ぜひともTLS証明書を追加することをお勧めします。
 ウェブページプロジェクトの管理の方なら、ドメインに公開証明書とプライベートキーを付加させられます。

  (写真4) TLS設定画面

  詳しくは、GitLab Pages のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」をご覧ください。

 

  エラーコードの設定

  GitLab Pagesでは、403や404エラーの設置は個人に任せられています。
 これらは、「public/」ディレクトリの「root」ディレクトリ内に、「403.html」「404.html」ファイルを設けることで構築します。

 これらのファイルはプロジェクトの「root」ディレクトリに設置することがほとんどですが、静的サイトジェネレータによってその仕様が異なる可能性があります。

  特に「404.html」の設置方法は、状況に応じて変化しますのでご注意ください。

  • プロジェクトのPages(仮に、/projectname/)を使っており、「/projectname/non/existing_file」へのアクセスを試みるとします。すると、GitLab Pagesはまず「/projectname/404.html」を表示しようするので、結果的に「/404.html」ファイルにありつけるようになります。
  • ユーザーあるいはグループのPages(/の配下に具体的なページが示される)を使っており、「 /non/existing_file」へのアクセスを試みるとします。すると、GitLab Pagesは「/404.html」を送信します。
  • 独自ドメインを使っており、「/non/existing_file」へのアクセスをするならば、GitLab Pagesは「/404.html」を送信します。
     

  ウェブサイトの削除方法

 サイトをどうしても削除しなくてはならない場合、プロジェクトの右上にある歯車型アイコンから「Pages」を選択、設定ページに進みます。
 そこから、「Remove pages」ボタンを押せば、ウェブサイトの削除が実行されます。たったこれだけなので、判断は慎重に。
 (写真5)ウェブサイトを削除する

 

  GitLab.comでGitLab Pagesを利用する

  GitLab.comでウェブサイトをホストすると、次のような機能が使えます。

  • GitLab.comにホストされたPagesの一般ドメイン名には、「gitlab.io」がつく。
  • 独自ドメインと、そこにTLS証明書をつけること。
  • デフォルトで共有ランナーの使用(無料)が許可されている。個人で作成したランナーを使用してもよい。ウェブサイトのビルドでお金を取られる心配はない。
     

  さらに詳細については、次のガイドをご覧ください。

 参照:GitLab Pages のこと全部教えます!①「静的ウェブサイトとは何か」「デフォルトのドメイン設定」

 

  GitLab Pagesにおける制限

  GitLabが提供している一般ドメイン(*.example.io)でPagesを作成した場合は、サブドメインにHTTPSを使用することができません。
 特にユーザー名やグループ名にドット「.」がついている場合(例:『foo.bar』など。URLは『https://foo.bar.example.io』にしたいけれど…)では、ドメインにHTTPSが使えません。
 この制限については、TLSプロトコルを使ったHTTP通信の性質によるものです。
 以上の場合については、HTTPからHTTPSへのリダイレクトが発生しないため、通信が暗号化されません。
 

  GitLab Pagesプロジェクトには、サブグループを設けることができません。ウェブサイトについては、最上位グループを設けるにとどまります。

 

  GitLab Pagesのリダイレクト

  「.htaccess」や「.conf」ファイルなど、何らかの独自サーバー設定ファイルが使えない際に、ページをリダイレクトする場合は、HTTP meta refreshをお使いください。

  静的サイトジェネレータによっては、あらかじめリダイレクト専用のプラグインを用意しているものがありますので、HTMLファイルを正確に作成する自信がない場合は、それを使うとよいでしょう。
 たとえば、Jekyllなら「redirect-from plugin」というものがあります。

 

  よくある質問

  作成したウェブページはダウンロードできますか?

  もちろん。アーティファクトをダウンロードすることで、あなたが作成したページをアーカイブ保存しておくことが可能です。
 

  GitLab Pagesはプロジェクトのソースを非公開にして構いませんか?

  はい。GitLab Pagesのプロジェクトは、非公開(private)、一部公開(internal)、完全公開(public)のいずれかから公開レベルを選択できます。
 

  ウェブサイトのプロジェクトを作成する前に、ユーザー/グループのウェブサイトを作っておく必要はありますか?

  いいえ。そのような操作はできません。
 まずはページのプロジェクトを作成してから、「http(s)://namespace.example.io/projectname」のようなURLでアクセスができるようになります。


 

  この機能に関するご意見

  すでにお寄せいただいているご意見、議論につきましては、GitLab's public issue trackerに掲載されています。


 Edit this page

 

PDF
更新日:2018-01-31 00:12:30 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://docs.gitlab.com/ee/user/project/pages/introduction.html 原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL: https://gitlab.com/gitlab-com/gitlab-docs/commit/1ecee98751ee89d91de5bfb272535c16b94981ab)この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より: Qiitaにてynott様が公開されたバージョン もありますよ。向こうのほうが先輩です)  目次: > .gitlab-ci.yml とは  > image と services  > before_scr…2018-02-18 23:08:02

【GitLab 公式 を訳してみた】GitLab CI/CD の使い方

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CD の使い方 注: GitLab バージョン 8.0から、 GitLab 継続的インテグレーション (CI)機能が登…2018-02-18 22:59:06

【GitLab 公式 を訳してみた】job artifacts の概要

GitLab Documentation > User documentation > Projects > job artigacts の概要 注: この機能は、GitLab 8.2 並びに GitLab Runner 0.7.0以降から導入されたものです。G…2018-02-14 23:24:21

【GitLab 公式 を訳してみた】GitLab CI で Git submodules を使う

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI で Git submodules を使う 注: この機能は、新しい CI job の権限モデル として、GitLab 8.12に…2018-02-12 23:54:13