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

法律: IT 解説記事 GitLab CI フノス(訳者) マニュアル

GitLab Runner>エクゼキュータ>Shell 

  シェルは、ランナーがインストールされたマシン(ローカル環境)でビルドする時に使うものの中では、簡潔な部類に入ります。
 ランナーがどのようなマシンにインストールされていようと、確実に使えるエクゼキュータです。

 このエクゼキュータを選択すると、Bash、Windows PowerShell、並びにWindows Batchで作成されたスクリプトをビルドに利用することが可能になります。

 

  概要

  スクリプト自体は、特権を持たないユーザーでも「--user」パラメータを追加することでgitlab-runner runコマンドを扱えるようになることから、比較的容易に動かすことができます。ただし、この機能はBashでのみ対応されています。
 

 プロジェクトのソースの確認方法:<working-directory>/builds/<short-token>/<concurrent-id>/<名前空間>/<プロジェクト名>

 プロジェクトのキャッシュの収容場所:<working-directory>/cache/<名前空間>/<プロジェクト名>

 場所について:

 「<working-directory>/builds」と「<working-directory/cache」はそれぞれ、config.toml[[runners]] セクションで、「builds_dir」「cache_dir」というオプションを追加すると具体的な指定ができる。

 

 

  非特権ユーザーがランナーを動かす場合

  GitLab RunnerをLinuxにインストールする場合、まずは公式の「.deb 」あるいは「.rpm」パッケージを入手するものと思われます。その際にインストーラーが「gitlab_ci_multi_runner」を発見できれば、極力それを使うように設定されているはずです。
 それが見つからなかった場合は、代わりに「gitlab-runner user」を作成していただくとよろしいでしょう。
 

  シェルでのビルドは「gitlab-runner」でも「gitlab_ci_multi_runner」ユーザーでも実行されるはずです。

  ただし、Docker EngineやVirtualBoxを利用したテストなどでは、たびたび特権が必要なリソースにアクセスする必要が出る可能性があります。
 その際には、「gitlab-runner」ユーザーを的確なグループに追加してください。

======================
usermod -aG docker gitlab-runner

usermod -aG vboxusers gitlab-runner
======================

 

  セキュリティの問題

  シェルを用いてテストを実施することは、おおむね危険を伴います。jobの実行にユーザーの特権(gitlab-runner)が必要な場合が多く、これは同じサーバーに置かれている他のプロジェクトからコードを"盗まれる"隙になりうるものです。

  シェル・エクゼキュータは、皆さんが管理・所有していて、信頼のおけるサーバーのみで取り扱うようにしましょう。

 Edit this page

 

 2018-03-23 21:40:39 / Hnoss
原文サイトを表示
[ 原文 ] https://docs.gitlab.com/runner/executors/shell.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。