GitLab Runnerをコンテナで実行します。

このようにして、GitLab RunnerをDockerコンテナ内で実行することができます。

一般的なGitLab Runner Dockerイメージの使い方

GitLab Runner Dockerイメージ（UbuntuまたはAlpineLinuxベース）は、GitLab Runnerがホストに直接インストールされている場合のように、標準的なgitlab-runner コマンドのラッパーとして設計されています。

一般的なルールとして、GitLab Runner のコマンドは通常次のように実行されます： 

gitlab-runner <Runner command and options...>

で実行できます： 

docker run <chosen docker options...> gitlab/gitlab-runner <Runner command and options...>

例えば、GitLab Runnerコマンドのトップレベルのヘルプ情報を取得するには次のように実行します： 

docker run --rm -t -i gitlab/gitlab-runner --help

NAME:
   gitlab-runner - a GitLab Runner

USAGE:
   gitlab-runner <global options> command <command options> <arguments...>

VERSION:
   10.7.0 (7c273476)

(...)

要するに、コマンドのgitlab-runner の部分がdocker run [docker options] gitlab/gitlab-runnerに置き換えられ、残りのRunnerのコマンドはregisterのドキュメントに記述されている通りになります。唯一の違いは、gitlab-runner コマンドがDockerコンテナの内部で実行されることです。

Dockerイメージをインストールし、コンテナを起動します。

始める前に、Dockerがインストールされていることを確認してください。

Docker コンテナ内部でgitlab-runner を実行するには、コンテナの再起動時に設定が失われないようにする必要があります。 そのためには、以下の 2 つのオプションがあります。

GitLab Runnerのよくある問題を説明したFAQセクションを必ずお読みください。

注session_serverを使用している場合は、docker run コマンドに-p 8093:8093 を追加して、8093 ポートも公開する必要があります。

オプション1：ローカルシステムのボリュームマウントを使用してRunnerコンテナを起動します。

この例では、gitlab-runner コンテナにマウントされる設定ボリュームにローカルシステムを使用します。 このボリュームは設定やその他のリソースに使用されます。 

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest
ヒント：MacOSでは、/srvの代わりに/Users/Shared を使用してください。

オプション2：Dockerボリュームを使用してRunnerコンテナを起動します。

この例では、構成コンテナを使用してカスタム・データ・ボリュームをマウントできます。

  1. Dockerボリュームを作成します： 

    docker volume create gitlab-runner-config

  2. 先ほど作成したボリュームを使用して、Runnerコンテナを起動します： 

    docker run -d --name gitlab-runner --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest

ランナーの登録

最後のステップは新しいRunnerを登録することです。 GitLab Runnerコンテナは登録されるまでジョブを受け取りません。

設定の更新

config.tomlで設定を変更した場合、変更を適用するためにランナーを再起動する必要がある場合があります。gitlab-runner restartを使用するのではなく、コンテナ全体を再起動するようにしてください： 

docker restart gitlab-runner

アップグレード版

最新バージョン（または特定のタグ）を取り出します： 

docker pull gitlab/gitlab-runner:latest

既存のコンテナを停止し、取り外します： 

docker stop gitlab-runner && docker rm gitlab-runner

コンテナを元通りにスタートさせます： 

docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest
注：データボリュームのマウントには、元と同じ方法（-v /srv/gitlab-runner/config:/etc/gitlab-runner または--volumes-from gitlab-runner-config）を使用する必要があります。

GitLab Runner のログを読む

GitLab Runnerが（ローカルにインストールされたバイナリであろうとDockerコンテナ内であろうと）フォアグラウンドタスクとして起動された場合、ログは標準出力に出力されます。 GitLab Runnerが（Systemdなどで）システムサービスとして起動された場合、ログはほとんどの場合、Syslogやその他のシステムロギング機構を通して記録されます。

GitLab Runner を Docker ベースのサービスとして起動すると、gitlab-runner ... コマンドがコンテナのメインプロセスとなるため、docker logs コマンドを使ってログを読むことができます。

例えば、GitLab Runnerを次のコマンドで起動した場合： 

docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

でログを取得することができます： 

docker logs gitlab-runner

ここで、gitlab-runner はコンテナの名前で、最初のコマンドで--name gitlab-runner 。

コンテナ・ログの扱いについての詳細は、Docker ドキュメントページを参照してください。

信頼できるSSLサーバ証明書のインストール

GitLab CIサーバーが自己署名SSL証明書を使用している場合は、GitLab CIサーバー証明書がGitLab Runnerコンテナから信頼されていることを確認してください。

gitlab/gitlab-runner イメージは/etc/gitlab-runner/certs/ca.crtで信頼できる SSL 証明書を探すように設定されていますが、これは-e "CA_CERTIFICATES_PATH=/DIR/CERT" 設定オプションを使って変更できます。

ca.crt ファイルをデータボリューム（またはコンテナ）上のcerts ディレクトリにコピーします。このca.crt ファイルには、GitLab Runner に信頼させたいすべてのサーバのルート証明書が含まれて ca.crtいるはずです。 GitLca.crt ab Runner コンテナは ca.crt起動時にファイルをインポートするので、コンテナがすでに起動している場合は、変更を有効にするために再起動する必要があるかもしれません。

Dockerイメージ

以下のマルチプラットフォームDockerイメージが利用可能です：

  • gitlab/gitlab-runner:latest Ubuntuをベースにしています。
  • gitlab/gitlab-runner:alpine UbuntuはAlpineをベースにしており、フットプリントははるかに小さくなっています（圧縮/解凍したUbuntuの160/350 MBに対してAlpineの45/130 MB）。
ヒント：UbuntuとAlpine両方のイメージのビルド手順については、GitLab Runnerのソースを参照してください。
注意:IBM Z イメージにはdocker-machine 依存が含まれていません。Linux s390x プラットフォーム用のメンテナンスがまだ行われていないためです。 現在の状況については、イシューを参照してください。

セリナックス

一部のディストリビューション（CentOS、RedHat、Fedora）では、基盤となるシステムのセキュリティを強化するため、デフォルトでSELinuxを使用しています。

このようなコンフィギュレーションを扱う際には、特別な注意が必要です。

  1. コンテナでビルドを実行するためにDockerexecutorを使用したい場合は、/var/run/docker.sockにアクセスする必要があります。 しかし、SELinuxが強制モードになっていると、/var/run/docker.sockにアクセスする際にPermission denied エラーが表示されます。 この問題を解決するには、selinux-dockersockをインストールしてください。
  2. ホスト上に永続ディレクトリが作成されていることを確認してください:mkdir -p /srv/gitlab-runner/config。
  3. ボリューム上で:Z 、Dockerを実行します： 
docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner:Z \
  gitlab/gitlab-runner:latest

原因と解決策についての詳細はこちらをご覧ください：http://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/