Hnoss

Hnoss

今さらながら題名間違いに気がづいて、大量修正を加えたところ。
カレンダー

文書タグ

フノス(訳者)(142) IT(114) 解説記事(69) オープンソース(49) メディア(31) Linux(30) ウェブ制作(23) GitLab CI(21) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(17) 百科事典(14) プラグイン(13) 文化(12) コンテナ(12) ソフトウェア(11) 録音(11) ミキシング(11) MIDI(10) 西アジア/中東(10) グルジア(9) 東ヨーロッパ(9) 料理(9) ジョージア(9) セキュリティ(8) シーケンス(8) 芸能(8) 音楽編集(8) 音楽(7) マスタリング(7) 経済(6) WordPress(5) アプリ(5) 業務効率化(5) JACK(5) コマンド(5) Google(4) 映像制作(4) Android(4) 音楽プレーヤー(4) マイクロサービス(4) 北米(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Windows(3) Java(3) ワークフロー(3) ソーシャルメディア(3) GNU(3) DAW(3) 欧州(3) Ubuntu(3) Python(3) 牛(2) ニュース(2) GNOME3(2) 歴史(2) 仮想通貨(2) マーケティング(2) PlayStation(2) 古代エジプト(2) 有角神(2) ERPシステム(2) 電子ブック(2) エジプト(2) ALSA(2) OS X(2) トヨタ(2) Krita(2) 電子書籍(2) ERP(2) バト(2) ウィッカ(2) Twitter(2) GPL(2) オカルト(2) ロスレス音源(2) スマホ(2) 魔女宗(1) アクティブSETI(1) バイノーラル(1) アップストリーム・パッケージング(1) 画像(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) サウンドフォント(1) ヤーウェ(1) CD(1) タブレット(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) ポータブルソフトウェア(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) リーナス・トーバルズ(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) スタジオジブリ(1) クヌム(1) 魔女裁判(1) オンデマンド(1) 政治(1) バフォメット(1) 国際(1) クリエイティブ・コモンズ(1) 黙示録(1) Synfig(1) 独占(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) EU(1) イボ人(1) 国際公文書館会議(1) マイナビ(1) キリスト教(1) レビ記(1) アマナイ(1) 広告(1) KXStudio(1) 絵文字(1) サンフランシスコ(1) イケンガ(1) リクルート(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) Blender(1) 出エジプト記(1) 観光案内(1) ツイッター(1) Youtube(1) パキスタン(1) CC(1) ハトホル(1) パン(1) 地方(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ゲーム(1) 法律(1) 中南米(1) モヘンジョ=ダロ(1) 悪魔(1) ラジオ(1) OpenToonz(1) 電子教材(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) パシュパティ(1) アピス(1) 宗教(1) テレビ(1) BountySource(1) 船乗りの柱(1) シリア(1) GPS(1) 日記(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) 教育(1) bi-modal IT(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) Papagayo(1) 写真(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) iOS(1) 聖書(1) 任天堂 DS(1) 学校(1) 日本(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


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 のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」

原文: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)

Hugo Static Site Generator with CI Deployment using GitLab | Leow Kah Man - Tech Blog
 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポ...
Using Docker images
GitLab Documentation > GitLab Continuous Integration (GitLab CI) > Docker integration >Dockerイメージを使う  GitLab CIは、Gi...
Configuration of your jobs with .gitlab-ci.yml
 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン ...
GitLab CI/CD Variables
GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CDで使えるAPI変数  GitLab ランナーは、CIから送られてきたj...

新着文書

Revisit to resist: Histories of the movement to end gender-based violence
抵抗のための再検討:ジェンダーに基づく暴力を終わらせるための活動の歴史 2017年11月8日 記憶は抵抗である。あなたの話が沈黙させられ挑まれたな...
What do women’s rights have to do with the SDGs and the internet?
女性の権利はSDGsとインターネットにどのような関係があるか? 2017年8月2日、スリランカ 女性は均質な集団ではなく、科学技術へのアクセスもまた、...
Sexual rights and the internet: Third EROTICS global survey now launched!
性的権利とインターネット:第3回EROTICS国際調査、現在開始! 2017年7月19日 EROTICS国際調査が戻ってきた! もしあなたが、インターネットを自ら...

新着Wikipedia翻訳

Air gap (networking)
エアギャップ(ネットワーク関係) エアギャップ(air gap:空隙)またはair wall(空気壁)、エア・ギャッピング[1]とは、ネットワーク・セキュリ...
HTTP Public Key Pinning
HTTP公開鍵ピニング HTTP公開鍵ピニング(HPKP: HTTP Public Key Pinning)[1]とは、HTTPヘッダによって実現されるセキュリティの仕組みであり、HT...
Double Ratchet Algorithm
ダブル・ラチェット・アルゴリズム 「ダブル・ラチェット」はこの項目へ転送されています。工具については レンチ を参照下さい。 暗号技術におい...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2017-10-27 21:02:19 Hnoss
2 2017-09-23 11:17:22 Hnoss
3 2017-09-10 22:17:53 Hnoss
4 2017-09-10 22:06:39 Hnoss
5 2017-09-10 22:06:28 Hnoss
6 2017-09-10 22:06:03 Hnoss
7 2017-09-10 22:05:53 Hnoss
8 2017-09-10 22:05:37 Hnoss
9 2017-09-10 22:05:08 Hnoss
10 2017-09-10 22:02:47 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →