Hnoss

Hnoss

GitLabのドキュメントが、CC BY-SA 4.0.になったー!やったー!
カレンダー

文書タグ

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

first-time visitors
user guide
謝辞

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

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

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

バナー

logo

ポスター

poster

フライヤー

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

Valid XHTML 1.0 Transitional


GitLab Documentation>GitLab Continuous Integration (GitLab CI)>GitLab Runnerを設定する

 GitLab CIにおいて、Runner(ランナー)とは「.gitlab-ci.yml」で定義したjobを実行する機関です。ランナーは独立した(仮想)マシンにインストールされます。これがjobを検出し、何が必要とされているかを抜き出してくれるのです。

 ランナーは、1つのプロジェクト専用にしたり、複数のプロジェクトを処理するものにすることもできます。全てのプロジェクトを処理するランナーのことを、共有ランナーをいいます。

 セキュリティの心配さえなければ、GitLabランナーはGitLabとは別のマシンに入れた方が良いでしょう。
 GitLabランナーは機械のリソースを大きく消費します。
 詳しくは、GitLab稼働条件ページの『GitLab Runner』の章をご覧ください。

 共有ランナー VS プロジェクト専用 ランナー

 ランナーをインストールしたら、その次に”登録”する工程があります。ここで、そのランナーを共有ランナーにするか、プロジェクト専用にするかを選択します。共有ランナーとして登録する場合は、GitLabインスタンスに管理者権限でアクセスしている必要があります。

 それでは、共有ランナーとプロジェクト専用ランナー の違いを確認しましょう。

  • 共有ランナーには、どのプロジェクトにも共通して必要なjobが入っている。逆に言うなら特徴がない。ビルド工程に変わり映えのないプロジェクトをいくつも所有していて、そこに沢山のランナーを用意していても、ほとんど使いどころがない。このような場合、共有ランナーを用意して、ランナーを統合するとよいだろう。ランナーそのもののメンテナンスやアップデートも簡単になる。共有ランナーは複数のjobを、fair usage queue(後述)という仕組みで処理するため、大量のjob処理に適している。それに比べて、プロジェクト専用ランナーはFIFOキューを使っているため、jobが立て込むと、共有ランナーよりも多くのリソースを消費してしまう。
  • プロジェクト専用ランナーは、どうしてもそのプロジェクトでしか使わないjobを処理する際に効果的である。共有ランナーには入れたくないjob、滅多に使われないjobなどを、このランナーに任せるとよい。たとえば、似たようなビルド方法をとるアプリでも、デプロイ先には違いがあることだろう。プロジェクトをデプロイする際に、プロジェクト専用ランナーを使うと、より正しいデプロイ先に適切な方法で展開しやすくなる。「タグ」機能(後述)を使えば、アプリケーションごとに必要な処理を自動振り分けすることができるので、有効に使っていこう。プロジェクト専用ランナーは、jobの処理にFIFOキューを使っている。


 プロジェクト専用ランナーについては、そこでビルドさせるプロジェクトを限定した方が、効率的に扱えます。

共有ランナーは、どのようなプロジェクトでも必要なビルド要件を満たしたランナーです。プロジェクトで利用するには、「Settings ➔ CI/CD」からAllow shared Runnersオプションに許可を出して下さい。

 CI設定により高い自由度を求めるのなら、プロジェクト専用ランナーを使うとよいでしょう。そのランナーが他のプロジェクトでの流用が効くかどうかについては保証しませんが、プロジェクトをより完璧に自動化するにはこのランナーが有効です。

 ”プロジェクト専用ランナー”とは言いつつも、これは設定次第で、複数のプロジェクトから利用できるようになります。
 これはあくまで、「いくつかのプロジェクトで利用できる」専用ランナーという扱いです。「全てのプロジェクトに使える」わけではないので、共有ランナーとは言えません。

 専用ランナーは、プロジェクトをフォークしたところで、自動的に引き継がれないところには注意してください。CIの設定(jobs, allow shared, etc)のコピーだけが、レポジトリと一緒に引き継がれます。

 共有ランナーを登録する

 共有ランナーを登録する際には、GitLabインスタンスに管理者権限でアクセスしている必要があります。

1.「admin/runners」ページで共有ランナーのトークンを取得します。
 (写真1)共有ランナー認証エリア

2.ランナーを登録する

 共有ランナーは、GitLab 8.2からデフォルトで使用が許可されています。これを取りやめたいときには、各プロジェクトの「Settings ➔ CI/CD」ページから、「Disable shared Runners」をクリックしてください。
 それ以前のGitLabについては、共有ランナーの使用がデフォルトで否定されています。

 プロジェクト専用ランナーを登録する

 専用ランナーの登録方法は、主に2つあります。

  1. プロジェクトの認証トークンから登録する
  2. 共有ランナーを(管理者権限が必要)専用ランナーに転換させる


 プロジェクトの認証トークンから登録する

 GitLabのインスタンスから、権限の認証を通過せずに、特定ランナーのトークンを作成するには、

  1. プロジェクトの「Settings ➔ CI/CD」に移動
  2. ランナーを登録する


 共有ランナーを専用ランナーに転換させる

 GitLabインスタンスに管理者権限でアクセスできる方なら、どの共有ランナーもプロジェクト専用ランナーに変えることができます。(一般ユーザーには不可能)
 権限がない方でも、「こういう方法もある」と分かっているだけで、チームでの提案に差が出てきますよ。

  1. 管理者エリアから、「Overview ➔ Runners (/admin/runners)」に移動して、希望のランナーを探す。
  2. Restrict projects for this Runner」という項目から、どのプロジェクトにランナーを使わせるかを選択する。


 以上の方法で、共有ランナーを専用ランナーに変化させられます。

 ”プロジェクト専用ランナー”を複数のプロジェクトで使用可能にする設定

 プロジェクト専用ランナーは、設定次第で複数のプロジェクトでも利用できるようになります。
 この設定をしないでいると、他のプロジェクトでの使いまわしが一切できません。
 結果、いくつもの専用ランナーがぶちぶちと無駄に増殖していく原因になります。

 設定は、ランナーを登録する際にも受け付けられますし、あとから各ランナーの設定で変更をかけることもできます。

 ランナーの流用を許可する(取りやめる)方法:

  1. プロジェクトの「Settings ➔ CI/CD」に移動
  2. 設定を加えたいランナーを選択する
  3. 鉛筆マークをクリックする
  4. Lock to current projects」にチェックを入れる
  5. Save changes」をクリックして変更を適用


 専用ランナーが使えるプロジェクトを追加する

 上の操作で作成したランナーに、こんどはプロジェクトを追加していきます。
 ただし、この操作をするには、プロジェクトのマスターであることが必要です。

 プロジェクトで専用ランナーが使えるようにする手順:

  1. プロジェクトの「Settings ➔ CI/CD」に移動
  2. 利用可能な専用ランナーの中から、使いたいものを選ぶ
  3. Enable for this project」「Disable for this project」の2択がある。どちらか正しい方を選ぶこと。

注:プロジェクト専用ランナーを複数プロジェクトに開放している限り、皆さんのプロジェクトのマスター権を持っているユーザーならば誰でも、あなたの同意なしに専用ランナーを使えてしまいます。十分ご注意ください。


 保護ランナー

 GitLab 10.0より導入

 ランナーの情報が、あまり外部に公開されたくない場合に使います。 保護されたランナーがビルドできるjobは、保護ブランチ または保護タグのプロジェクトで作成されたjobのみです。保護されていないプロジェクトについては、jobを実行しません。

 ランナーの保護/非保護を設定するには:

  1. プロジェクトの「Settings ➔ CI/CD」に移動
  2. 設定を加えたいランナーを選択する
  3. ランナー名横の鉛筆マークをクリックする
  4. Protected」にチェックを入れる。または外す。
  5. Save changes」をクリックして変更を適用


 (写真2)「Protected」の欄

 手動でランナーのキャッシュをクリアする

 GitLab 10.4以降に導入

 GitLab ランナーは、キャッシュをjobの処理速度向上のために使います。処理の過程で何度も使うデータについては使いまわすようにしているのです。ところが、時としてそれがランナーの誤作動の引き金になることがあります。

 キャッシュはGitLabのUIから削除することができます。何か動作不良が起きた時に試してみてください。

  1. プロジェクトの「CI/CD > Pipelines」に移動
  2. Clear Runner caches」をクリック
  3. 次回のプッシュから、CI/CD jobは新しいキャッシュを使用するはずです。


 なお、キャッシュをクリアしても、「.gitlab-ci.yml」に設定したキャッシュキーが変更されることはありません。また、キャッシュキーを手動で変更することがさらに誤作動を招くことがありますので、変更しないでください。

 上の工程を実行すると、GitLabランナーのバックグラウンドが、データベースから必要なデータを集めて、もう一度新しいキャッシュキーを作り始めます。次のプッシュから新たなキーが使われて、以前のキーは使用不可になります。
 この段階では、まだ古いキーは残存していますが、じきにランナーのガベージコレクターによって、ファイルシステムごと除去されるでしょう。

 共有ランナーのjob検出方法(fair usage queue)

 共有ランナーでは処理の順位付け(キュー)に「fair usage」という仕組みを採用しています。
 これにより、ランナーに複数のプロジェクトがほぼ同時にビルドの申請があった場合は、共有ランナーはそれぞれのプロジェクトで最初にしなくてはならないjobから順番に実施していくようになっています。

例1

 次のjobを実施することになっている場合

  • Project 1 に Job1
  • Project 1 に Job2
  • Project 1 に Job3
  • Project 2 に Job4
  • Project 2 に Job5
  • Project 3 に Job6


 共有ランナーのアルゴリズムは、このようにjobを処理します。

  1. Job 1    全てのプロジェクトの中で、最もjobの数字が小さい。最初に選ばれる。
  2. Job 4    Project 2 の中では、最もjobの数字が小さい。Project 1 のjobは既に実施されてしまっていることから、これが次に選ばれる。
  3. Job 6    Project 3 の中では、最もjobの数字が小さい。Project 1,2 のjobは実施されていることから、これが次に選ばれる。
  4. Job 2    Project 1 の中では、次にjobの数字が小さい。
  5. Job 5    Project 2 の中では、次にjobの数字が小さい。
  6. Job 3    全てのプロジェクトのjobを均等に処理してきたため、これが最後となる。

例2

  • project 1 に Job1
  • project 1 に Job2
  • project 1 に Job3
  • project 2 に Job4
  • project 2 に Job5
  • project 3 に Job6


 この場合、共有ランナーのアルゴリズムは、次のようにjobを処理します。

  • Job 1    全てのプロジェクトの中で、最もjobの数字が小さい。最初に選ばれる。
  • 何らかの理由でjob1はすでに終了していた。
  • Job 2    ランナーはまだ一つもjobを処理できていない。この場合、次にjobの数字が小さいものが実施される。
  • Job 4    Project 2 の中では、最もjobの数字が小さい。Project 1 のjobは既に実施されたことから、これが次に選ばれる。
  • job 4も何らかの理由で終了していた。
  • Job 2    ランナーはまだProject 2のjobを処理できていない。この場合、同じプロジェクト内で次にjobの数字が小さいものが実施される。
  • Job 6    Project 3 の中では、最もjobの数字が小さい。Project 1,2 のjobは実施されていることから、これが次に選ばれる。
  • Job 3    全てのプロジェクトのjobを均等に処理してきたため、これが最後となる。(ワンは、なんじょうさむしい数さ~♪という古い歌があったけど、この方式でいくとそうでもない。)


 共有ランナーをより効果的に使う

 共有ランナーをより多くのプロジェクトに対応させるには、これから説明するいくつかのワザが欠かせません。

 タグを使う

 実際、プロジェクトでランナーをまともに使っていこうと考えると、ランナーは様々なタイプのjobに対応できなくてはなりません。この課題を放置すると、プロジェクトを共有する段になれば、ますます大きな問題として直面することになるでしょう。
 大量のプロジェクトを目の前に、何の分類もかけずに放置しておくことは、作業の非効率化を招きます。そこで活用するのが、tagです。

 ランナーにタグをつけることで、実行するjobに分類を設けることができます。
 これにより、jobを必要なだけものだけに絞って実施することが可能になります。中でも大量のjobを設定している、共有ランナーなどの場合は、より大幅な削減が期待できるでしょう。

 たとえば、GitLabランナーでRailsのテストが実施できるようなコードをそろえてあった状態なら、ランナーに"rails"タグを設けるだけで適切なテストが行われるようになります。

 タグが付いていないjobのみを実行する

 先ほど、「タグがついているjobだけを実施できる」と述べましたが、その逆はできないのかと気になったと思います。これからその設定方法をお教えしますね。
 この設定は、ランナーを登録する際にも受け付けられますし、あとから各ランナーの設定で変更をかけることもできます。

 タグ付き/タグなし jobを抜き出して実行させる方法:

  1. プロジェクトの「Settings ➔ CI/CD」に移動
  2. 設定を加えたいランナーを選択して、稼働を許可する
  3. 鉛筆マークをクリックする
  4. Run untagged jobs」という選択肢にチェックを入れる
  5. Save changes」をクリックして変更を適用


 ランナーの脆弱性について

 一部のランナーエクゼキュータでは、ランナーでjobを実行すると、全てのコードにアクセスが図れて、ランナーのトークンを奪い取られてしまうことがあります。
 特に共有ランナーを奪い取られると、そのランナーに通される全てのコードが読み取られてしまうので、より危険です。

 皆さんはランナーのトークンにアクセスすることができます。それゆえにランナーをクローンすることもできるし、jobの失敗なども確認できるのです。
 このアプリの基本的な機能を構成している要素が、セキュリティリスクの元にもなっていることを、きちんとご理解ください。

 この脆弱性は、機能性を追い求める過程で生じてしまった欠点です。当面直せそうにありません。

 ですが、きちんと気をつけていれば、リスクを大幅に回避することができます。
 まず、1つ目。これは皆さんがお持ちの共有ランナーにアクセス制限をかけることです。ランナーにはいくつか種類があることは先ほどもお伝えしました。その中でも共有ランナーは、デフォルトでアクセスに制限がかけられていません。これが主な弱点になります。GitLabのインスタンスから、アクセスに制御をかけてください。
 2つ目が、よりセキュリティ性が高いランナーエクゼキュータを採用することです。

(訳者より: たとえば、Shellエクゼキュータの場合は、マシンの特権を使う機会が多いことから、プロジェクトのコードが盗み出される隙をつくりやすいと言われています。
 それから拙訳の文章に、Dockerなどのコンテナ類も特権が絡むと、Dockerを展開しているマシンを危険にさらしやすいことが記されていました。)

 フォーク

 プロジェクトをフォークする際には、同時にプロジェクトのjob設定がコピーされます。
 これがきっかけで、皆さんが作成したランナーが第三者によって利用される場合があります。

 たとえば、とあるプロジェクトのマスターが、1つの共有ランナーを使ってビルドするように設定していたとします。
 そのプロジェクトを誰かがフォークしました。もちろん、jobの設定は完全にコピーされているため、その共有ランナーを使用する設定も消えてはいません。よって、そのままビルドが実行されれば、最初のプロジェクトと同じランナーを使用することが十分あり得ます。

 GitLab ランナーにおける攻撃ベクトル

 上記の他にも、現在解決策を探している案件がいくつもあります。これに取り組むことで、ランナーがさらに改良されていくことは間違いありません。
 詳しくはSecurity Considerationsをご覧ください。皆さんのコントリビューションをお待ちしております。

Edit this page

原文:https://docs.gitlab.com/ee/ci/runners/README.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
新着文書(Hnoss)

GitLab Plugin system
GitLab Documentation > Administrator documentation >GitLab Plugin system GitLab 10.6より導入。  カスタムプラグインを使えば、GitLa...
UX Department
現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...
Engineering
現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開して...

新着文書

Bristol’s Last Bookshop shares key facts on the remains of publishing
ブリストルの ラスト・ブックショップ (「最後の書店」)はたぶん、真の本好きのための残本店と言っていいだろう。それは、いくつかの出版社の名作...
Second social leader opposed to dam construction murdered in one week
一人の社会指導者は昨日プエルトリコ・バルディビアで虐殺された。これはアンティオキアで一週間以内に連続して起きた二回目の類似の殺人である。5月8...
Avianca strike leaders fired / Justice for Colombia
コロンビア第一の航空会社アビアンカは昨年9月20日から11月9日の長期にわたり行われたストに参加したパイロット14人を解雇した。解雇された一人、ハイ...

新着Wikipedia翻訳

Flutter (software)
Flutter -------- 原作者:Google 開発者:Googleとコミュニティ 最初の公開:アルファ(v0.0.6)/2017年5月;1年前(2017-05)[1] 試験版の公...
E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-03-23 21:52:26 Hnoss
2 2018-02-20 23:28:08 Hnoss
3 2018-02-20 23:27:33 Hnoss
4 2018-02-20 23:26:23 Hnoss
5 2018-02-20 23:25:51 Hnoss
6 2018-02-20 23:23:23 Hnoss
7 2018-02-20 23:13:19 Hnoss
8 2018-02-20 23:13:00 Hnoss
9 2018-02-20 23:12:02 Hnoss
10 2018-02-20 23:09:20 Hnoss

    
ブックマーク登録

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

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

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

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


言語選択

    
ファイルプロパティ

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

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


    
ノート

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

言語選択

 →