• カスタム環境変数の設定
  • systemd のカスタマイズ
  • upstart のカスタマイズ
• デフォルトの停止動作のオーバーライド
  • systemd のオーバーライド
  • upstart のオーバーライド

GitLab Runnerのシステムサービス

GitLab Runner はGoservice ライブラリ を使って内部 OS を検出し、最終的に init システムに基づいてサービスファイルをインストールします。

GitLab Runnerがインストールされると、サービスファイルが自動的に作成されます：

• systemd： /etc/systemd/system/gitlab-runner.service
• upstart： /etc/init/gitlab-runner

カスタム環境変数の設定

カスタムの環境変数で GitLab Runner を実行したいこともあるでしょう。例えば、GOOGLE_APPLICATION_CREDENTIALS を Runner の環境に定義したいとします。これはenvironment の設定とは異なるもので、Runner が実行するすべてのジョブに自動的に追加される変数を定義するものです。

systemd のカスタマイズ

systemdを使うRunnerの場合、エクスポートする変数ごとにEnvironment=key=value 1行を使って/etc/systemd/system/gitlab-runner.service.d/env.conf 。例えば

[Service]
Environment=GOOGLE_APPLICATION_CREDENTIALS=/etc/gitlab-runner/gce-credentials.json

次に設定をリロードします：

systemctl daemon-reload
systemctl restart gitlab-runner.service

upstart のカスタマイズ

upstart を使用する Runner では、/etc/init/gitlab-runner.override を作成し、必要な変数をエクスポートします。例えば

export GOOGLE_APPLICATION_CREDENTIALS="/etc/gitlab-runner/gce-credentials.json"

これを有効にするには、ランナーを再起動します。

デフォルトの停止動作のオーバーライド

場合によっては、サービスのデフォルトの動作をオーバーライドしたいかもしれません。

例えば、GitLab Runner をアップグレードするときには、実行中のジョブがすべて終了するまで、GitLab Runner を優雅に停止させるべきです。しかし、systemd や upstart などのサービスは、ほとんど気づかずにプロセスを再起動してしまうかもしれません。

そのため、GitLab Runner をアップグレードすると、インストールスクリプトはおそらくその時点で新しいジョブを処理していたであろう runner プロセスを強制終了して再起動します。

systemd のオーバーライド

systemdを使用するRunnerでは、以下の内容で/etc/systemd/system/gitlab-runner.service.d/kill.conf ：

[Service]
TimeoutStopSec=7200
KillSignal=SIGQUIT

これら2つの設定をsystemdユニットの設定に追加した後、Runnerを停止することができ、systemdはkillシグナルとしてSIGQUIT 、プロセスを停止します。さらに、stop コマンドには 2h のタイムアウトが設定されており、このタイムアウトまでにジョブが優雅に終了しない場合、systemd はSIGKILL を使用してプロセスを kill します。

upstart のオーバーライド

upstart を使用する Runner のために、以下の内容で/etc/init/gitlab-runner.override を作成します：

kill signal SIGQUIT
kill timeout 7200

これら2つの設定を upstart ユニット設定に追加した後、Runner を停止することができ、upstart は上記の systemd と全く同じことを行います。