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

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

カテゴリ一覧

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

一覧

2017/07/28

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

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

List

Hnoss

English⇒Japanese

ajhjhaf

English⇒Japanese

shikimi

English⇒Japanese

hanako

English⇒Japanese

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

新着翻訳記事

【GitLab 公式 を訳してみた】エクゼキュータ

 GitLab Runner>エクゼキュータ

  GitLab Runnerでは、複数のエクゼキュータをビルドの実行にご利用いただけます。それぞれ異なる性質があります。必要に応じて使い分けましょう。
 従って、場合によってはあまり必要がないエクゼキュータが出てくる可能性があります。後半部「どれを選べばいい?」のコーナーを参考にしてください。
 また、エクゼキュータによって対応している機能、または使えない機能がちゃんとあります。これは「対応している機能と互換性」で取り上げます。
 

  それぞれのエクゼキュータをきちんと調べたい方は、次のリンクから説明書に移動してください。

 



 

  エクゼキュータを選択する

  エクゼキュータはそれぞれ、対応しているプラットフォームが違ったり、プロジェクトをビルドする方法論に差異があったりと、何かと個性があります。
  以下の表は、それぞれのエクゼキュータがどのような操作に対応しているかを示したものです。

 

エクゼキュータ Shell Docker VirtualBox Parallels SSH Kubernetes
ビルド毎にビルド環境を整理する no no
ランナーマシンの移行 no partial partial no
並列ビルドのZeroconfに対応しているかどうか no (1) no
ビルド環境をコンパイルすること no (2) ✓ (3) ✓ (3) no
ビルドに問題が生じたときにデバック可能か 簡単 ほどほど 難しい 難しい 簡単 ほどほど

 

 no (1) - 可能ではあるが、ビルドマシンの代わりにサービスコンテナを利用するときに不利なことが多い。

 no (2) - 依存関係は全て手作業でインストールしなくてはならない
 ✓ (3) - Vagrantを使っていた場合

 

  どれを選べばいい?

  エクゼキュータを設定する上で最も簡潔な選択肢が、シェルです。ただし、ビルドに関する全ての依存関係を、ランナーが入っているマシンに手動でインストールする必要があります。
 

  そうなると、より良い選択肢はDockerであると思われます。きちんと整理されたビルド環境で開発が行える点はシェルと同じで、依存関係の管理がより簡単(プロジェクトのビルドに必要なソフトはすべてDockerイメージの中に配置することができるため)です。Dockerをエクゼキュータに採用すると、ビルド環境にサービス(MySQLなど)を封入する操作が容易になります。
 

  さらに、Dockerマシンの特殊なバージョンをお使いいただくと、オートスケーリング機能が扱えるようになります。 このバージョンは、普通のDokcerエクゼキュータと同じ使い勝手でありながら、必要に応じてDockerマシンを構築して、ビルドのホストを増やす機能もついています。
 

  Kubernetesをエクゼキュータにした場合、ビルドにKubernetesがフル活用できることは、言うまでもありません。このエクゼキュータはKubernetes cluster APIを駆使して、"Pod" という形式のビルドコンテナやサービスコンテナに相当するものを作り上げます。これがGitLab CIに課されているjobを処理していきます。
 

  ビルドシステムを完璧に仮想化したい場合は、VirtualBoxParallels の2つが選択肢に入ります。
 この種類のエクゼキュータは、すでに作成していた仮想マシンをクローンして、ビルドに使う方法も取れるところが長所です。
 この形態は、開発に使っているマシンと、開発しているアプリのプラットフォームが異なっているときなどにおすすめです。仮想マシンにはwindows、Linux、OSX、FreeBSDなどのOSを構築できます。仮想マシンとGitLab Runnerを接続させて、ビルドを行います。この仮想マシンを使った手法は、インフラのコストを抑える際の定石とも言われています。
 

  プロジェクトに更なる完璧さを求めるのなら、SSHエクゼキュータを追加しておくとよいでしょう。
 ただし、上記のエクゼキュータのいずれかを導入したうえでご検討いただくのが、使用の大前提です。
 これはGitLab Runnerを他のサーバーに接続してビルドする際に、より安全性を高めるために使われます。ビルドに採用してうまくいった例がないわけではありませんが、一般にはSSH以外のエクゼキュータをメインに使っていくことをおすすめしています。

 

  対応している機能と互換性

  それぞれのエクゼキュータが対応している機能一覧

 

エクゼキュータ Shell Docker VirtualBox Parallels SSH Kubernetes
秘密変数
GitLab Runner Exec コマンド no no no
gitlab-ci.ymlのjob: image no no no no
gitlab-ci.ymlのjob: services no no no no
gitlab-ci.ymlのjob: cache
gitlab-ci.ymlのjob: artifacts
絶対パス: caching, artifacts no no no no no
ステージ間でアーティファクトを授受する
GitLab Container Registryのプライベートイメージが使えるか n/a n/a n/a n/a

 

 

  各OSが対応しているシェル

 

シェル Bash Windows Batch PowerShell
Windows ✓ (default)
Linux ✓ (default) no no
OSX ✓ (default) no no
FreeBSD ✓ (default) no no

 

 Edit this page

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

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】API設定でパイプラインにトリガーを設ける

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >API設定でパイプラインにトリガーを設ける 注: GitLab CE 7.14にて導入。 GitLab 8.12にて「job permiss…2018-01-22 14:29:44

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

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

【GitLab 公式 を訳してみた】パイプラインのスケジュール

GitLab Documentation > User documentation > Projects > パイプラインのスケジュール 注: この機能はGitLab Runner 9.1から導入されました。当初の機能名は、「 Trigge…2018-01-16 20:15:49

【GitLab 公式 を訳してみた】CIサービス設定例

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >CIサービス設定例  ベースイメージにリンクして使うためのDockerコンテナは、GitLab CIで「 service 」キー…2018-01-14 16:19:15