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

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

カテゴリ一覧

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

一覧

2017/07/28

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

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

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます!④ / Marcia Ramos

GitLab DocumentationUser documentationProjectsGitLab Pages 説明書>GitLab Pages のこと全部教えます!④

   記事の 種類: 取扱説明書 || 対象: 初心者 || 作者: Marcia Ramos || 投稿日: 2017/02/22



  .gitlab-ci.yml ファイルを作成し、GitLab Pages を工夫する
 

  GitLab CIの機能をうまく使いこなせば、様々な場面で活用できます。
 ビルド、テスト、継続的インテグレーションを通じてあなたのアプリを展開する方法などの設定が可能です。
 そこまで応用的な使い方はしないにしても、GitLab Pagesでサイトをビルドしたり、サーバーに展開する時には、CIの設定が必要です。

  CI設定では、GitLab ランナーを動作させるためのスクリプトを指定できます。ターミナルからランナーを作動させると、そこで設定されたスクリプトが発動される仕組みです。
 GitLabにはこのファイルを自動的に読み取る機能があります。CI設定をした後に、ファイルの読み取り方法をどうするかなどの設定は要りません。

  このページでは、CIファイルの具体的な設定方法をいくつか掲載します。
 Yamlファイルは、Yamlシンタックスで構成されています。いくつか法則を覚えれば、.gitlab-ci.ymlの設定にも役立ちます。
 それから、CIシンタックスの合否は、 GitLab CI Lint Toolで簡易検査ができます。

 

  設定実例:

  ここでは例示として、Jekyllサイトの設定方法を紹介します。

 まずは、ここで想定しているJekyllの使用方法を大まかに説明します。
 jekyllをビルドするには、あらかじめコンピューターにJekyllをインストールしておく必要があります。
 Jekyllを入手するには、ターミナルで「gem install jekyll」と入力してください。
 そして、ターミナルから「jekyll build」と指令を出して、ローカル環境でビルドするという方法です。

 GitLab CI に書かれたことは、そのままGitLabランナーというサイトのビルドを担当するプログラムが実行してくれます。なので、ランナーに異常があった場合は、だいたいCIファイル内に原因があるとみて間違いありません。
  .gitlab-ci.yml内のスクリプトには、あなたがランナーに実行させたいことを記述します。慣れないうちは複雑に思えますが、一度設定すると後が楽になります。


 さてこの例では手始めに、次のコマンドをCI化します。
 

======================
 $ gem install jekyll
 $ jekyll build   
======================



  スクリプトに変換する

  これらのコマンドをYamlで使えるスクリプトにしてみましょう。

======================
 script:    
  - gem install jekyll
  - jekyll build   
======================



  Job設定

  さて、スクリプトといっても、案外そのままコマンドを入力しているだけということがわかりましたね。
 GitLab CIには「job」という機能があります。
 たくさんのスクリプトを「job」というグループとして、ひとまとめにできます。
 たびたび使います。覚えておきましょう。

======================
job:
  script:
  - gem install jekyll
  - jekyll build
======================

  だからといって、「複数のスクリプトを指定するなら『job』を使えばいいや」というわけではありません。
 指定する場面によって名称を変えないと、システムが識別できないからです。

 ここで最も大切な、ランナーに取らせる動作を指定するグループには、「pages」という名前がついています。こちらを積極的に使いましょう。

======================
pages:
 script:
 - gem install jekyll
 - jekyll build

======================


 

  public ディレクトリ

  「public」ディレクトリにあるファイルだけをウェブサイトとしてビルドしたいときがありますね。
 この設定はビルドに関係することなので、ランナーに指示を送る必要があります。「pages」でタスクを指定してください。
 Jekyllの場合、buildコマンドに宛先を指定する(-d)フラグを追加すれば、その操作が可能です。

======================
pages:
  script:
  - gem install jekyll
  - jekyll build -d public

======================


 

  アーティファクツ

  サイトジェネレータが生産したサイトのことを、「生産物(artifacts)」と言い表すことがあります。あんまり”サイト”などと連呼されても、紛らわしくなってくるんでしょうね。

 サイトをビルドするためには、アーティファクツの置き場所をきちんと指定しなくてはなりません。
 宛先としては「public」ディレクトリが妥当でしょう。

 version3.4.0 以前のJekyllでは、次の設定が必要です。

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

   Jekyll 3.4.0以降では、インストール方法にBundlerが採用された関係上、設定方法が少し異なります。
 インストールにも、ビルドにも、「bundle」コマンドを使うようになったことを頭の隅に置いといてください。

======================
pages:
  script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
======================

  さて、これらのいずれかが、Jekyllサイトを作成する時に必要になる”最低限の”設定です。exampleページにも、同じCI設定が掲載されています。
 通例ここからさらにオプションを追加するなどして、サイトに磨きをかけていきます。

  ですがこの段階ですでに、サイト自体は問題なく展開できるようになっているはずです。


 

  Image で言語のバージョンを指定する

  たとえば、Jekyllの動作にはRubyが必要ですよね。そして、新しいJekyllをインストールした場合は相応のバージョンのRubyが必要になるはずです。
 「必要になる言語のバージョンを指定しなくて大丈夫?」と案じた方もいらっしゃることでしょう。
 ですが、答えは簡単です。GitLab ランナーが従っている.gitlab-ci.ymlですが、実は1つのDockerイメージになっています。それに使用させる言語を指定すればよいのです。次のスクリプトを追加しましょう。

======================
image: ruby:2.3

pages:
  script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
======================

  この設定をすることで、ランナーは「image」の情報を参考に、Ruby 2.3をファイルシステムの一部として認識するようになります。imageを指定しなかった場合、ランナーはデフォルトイメージであるRuby 2.1を使います。

  同じような設定を、NodeJSが必要な静的サイト・ジェネレータでも使用できます。imageの部分をNodeJSと設定すれば、ファイルシステムにNodeJSが組み込まれます。
 たとえば、Hexoサイトを作成する時には、image: node:4.2.2とするとよいでしょう。

  注意:このページではDockerイメージの使い方について、あくまでCI設定に役立つ範囲でしか説明しないつもりです。Dockerイメージについて詳しく知りたい方は、こちらのページにかいつまんだ説明が載っていますので、そちらを参考にしてください。

  このようにして、少しずつ設定を増やして、理想のCIを作り上げていくんです。
 この調子で、他の設定も追加してみましょう。

 
 

  Branching

  GitLabにはバージョン管理プラットフォームが搭載されています。それを使えば、プロジェクトをいくつかのバージョンに分岐させて、その中から最も良いものを公開用のウェブサイトにすることも可能になります。
 しかし、それには公開用にするメインのバージョンとそうでないものとを分別しなくてはなりませんね。
 いくつかの分岐バージョン(branch)から、もっとも重要な(master)分岐を選択することから、メインのバージョンには「master branch」という名前がつけられています。
 そして、複数のパラレルバージョンが発生してしまうことから、ランナーが迷わずビルドできるように、masterバージョンのことだけ(only)追い求めるように設定します。

======================
image: ruby:2.3

 pages:
  script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
  only:
  - master
======================
 一番下にonlyの項目が増えましたね。

 
 

  Stages

  しかし、この先たくさんの「job」やら「pages」やらのグループが増え続ければ、何をいつ実行すればよいのやら曖昧になってきます。
 特にウェブアプリなどを作ったときには、たくさんの「test」や他のタスクが待ち受けています。
 そこで、タスクグループを”どの段階(stage)”で実行するかを指定すると心強いです。
 GitLab CIがデフォルトで使えるステージは3つあります。

  • build
  • test
  • deploy 


 これらのステージ情報を「job」の中に組み込むと、そのグループをどの手順で行うかが明確になります。
 それらの手順をどのような順番で実行するかについては、また別のところで決めた方が、手順の変更などに柔軟に対応できます。なので、下手に番号をつけたりはしません。

  CI設定に次の行を追加します。

======================
image: ruby:2.3

 pages:
  stage: deploy
  script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
  only:
  - master
======================
 「pages:」のすぐ下に、「stage:deploy」という項目が追加されたのがわかりましたか。

 

  次に、「stage:test」の使い方を説明します。
 たとえば、実験的に作成したパラレルバージョンをビルドするときには、けしてマスターブランチには反映されずに「テスト用デプロイ」をしたいものです。
 そのようなときは、CIファイルにもう一つjobグループを作成します。「master以外の(except)ブランチをビルドする時にはテスト用」と設定する内容です。
 

======================
image: ruby:2.3
pages:
  stage: deploy
  script:
  - bundle install
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
  only:
  - master

test:
  stage: test
  script:
  - bundle install
  - bundle exec jekyll build -d test
  artifacts:
   paths:
   - test
  except:
  - master
======================
 これまでのCI設定に加え、後半にtest:グループが作成されました。
 

  特に重要なのは、最後の4行です。
 「paths:-test」という部分で、テスト用にデプロイされたアーティファクツが、testディレクトリに送られるように設定されています。
 また、「except:-master」という項目で、マスターブランチではないブランチ(つまり、実験用パラレルブランチ)には、この設定を適用するように指定しています。

   こうすることで、メインとパラレルを同時に、ごちゃ混ぜにせずにビルドすることができるんです。


 ウェブアプリを作成する時には、たくさんのバージョンを見比べなくてはならないこともあります。
 このようなCI設定をすることで、ランナーがブランチごとの対応を自動的に判断してくれるようになります。たくさんのバージョンを1つ1つをばらばらにビルドしなくても、一挙にビルドできるようになるので、とてもパワフルです。
 
 このように、ステージを決めておけば、CI設定にいくつかのバージョンを持たせることができるようになります。


 

  Before Scriptパラメータ

  複数のスクリプト・グループが作成されたところで、「before_script」というパラメータの説明をします。これを使うと、どのjobグループにも必要とされるコマンドを指定できるようになります。
 たとえば、先ほどの設定だと、「bundle install」というコマンドが共通していましたね。これを「before_script」に設定しましょう。
 そのかわり、pagesとtestのそれぞれのグループから、「bundle install」というスクリプトが省略されます。
 

======================
image: ruby:2.3

 before_script:
  - bundle install

 pages:
  stage: deploy
  script:
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
  only:
  - master

 test:
  stage: test
  script:
  - bundle exec jekyll build -d test
  artifacts:
   paths:
   - test
  except:
  - master
======================


 

  キャッシュ用の場所を用意しよう

  ファイルの読み込みを早めたり、ビルド時間をより短くしたいのなら、キャッシュを使えるようにするのが手近な方法です。
 今回紹介しているJekyllの場合、「bundle install」の時にキャッシュが使えると、どのブランチでも読み込みが速くなります。
 キャッシュの場所はvendorディレクトリに、そして「bundle install」発動時にそれが使われる設定をすることとします。

======================
image: ruby:2.3

 cache:
  paths:
  - vendor/

 before_script:
  - bundle install --path vendor

 pages:
  stage: deploy
  script:
  - bundle exec jekyll build -d public
  artifacts:
   paths:
   - public
  only:
  - master

 test:
  stage: test
  script:
  - bundle exec jekyll build -d test
  artifacts:
   paths:
   - test
  except:
  - master
======================
 ファイルの前半部に「cache:paths: - vendor/」という要素が追加されました。これがキャッシュの場所をvendorファイルにする設定です。

 次に、今回キャッシュを使わせる予定の「before_script: - bundle install」が来るのですが、
 行の末尾に 「--path vendor」という項目が追加されてることがわかりますか。
 これが追加されてはじめて、vendorファイルに存在するキャッシュを利用できるようになります。
 

  しかし、この方法では、「キャッシュを使うときには必ずや/vendorディレクトリを使う」ようにはしていますが、
 「サイトの中にvendorディレクトリが必要である」とは設定されていないはずです。
 次のスクリプトを追加してください。Jekyllサイトをビルドする時には、vendorファイルを常設するという内容です。

======================
exclude : - vendor
======================

 

  さて、これにてGitLab CI設定の基本的な使い方についての説明は終わりです。
 GitLab CIは、ウェブサイトをビルドするときだけでなく、パラレルバージョンを作成する時や、キャッシュを設ける時などにも活用できることがお分かりいただけたはずです。
 まず初心者の方はこれを参考に、次のマスターブランチ候補であるパラレルバージョンのストックを作りおいて、すぐさま展開できる体制づくりを整えていくことを目標にしていただけるとよろしいかもしれません。



 

  GitLab CIについてもっと知る

  GitLab CIはあなたのサイト制作を応援します。
 もしも、サイトを制作している際に、繰り返している工程が多いと感じたら、それをスクリプト化してみませんか。実に様々なタスクを自動化することができます。詳しくは公式ガイドのGit Lab CIに関連する部分をご覧ください。

  この記事を書くにあたって参考にした記事

GitLab Pages のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」

 

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

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab Pages 公式 を訳してみた】GitLab Pages 説明書 

GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLabには「GitLab Pages」という機能があります。  GitLab…2017-09-23 12:10:55

SSGを知る②:最近の静的サイト・ジェネレータ事情 | from about GitLab.com

 引き続き、静的サイト・ジェネレータ特集です。  前回は、「静的サイトとは何か」というような内容で終わってしまいましたが、いよいよ本題です。  静的サイト・ジェネレータって…2017-09-23 11:58:35

SSGを知る①:静的 vs 動的 ウェブサイト | about GitLab.com

 ウェブサイトは静的なものと、動的なもの2つに分かれますが、それらにはどのような違いがあって、どのような長所があるのでしょう。  GitLab Pagesで扱えるのはどっちだろう?  静…2017-09-23 11:23:00

【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます!①

GitLab Documentation > User documentation > Projects > GitLab Pages 説明書 >GitLab Pages のこと全部教えます!① 記事の 種類 : 取扱説明書 || 対象 : 初心者 || …2017-09-23 11:17:34