GitLab RunnerでKubernetesを使う時の注意

Tips
目次

概要

GitLabでリポジトリの管理をしていて、GitLab Runnerを使っていますか。

私の場合、テストの実行など、CIを回すために利用しています。

私の環境ではKubernetesを使ってサーバを構築しているのですが、GitLab Runnerは、Kubernetesで実行することもできます。

ここでは、KubernetesでGitLab Runnerを使う時の注意を紹介します。

設定

通常GitLab Runnerは、Docker環境がインストールされているサーバにインストールし、Runnerが実行された際は、Dockerのコンテナとして実行されます。

この設定は、/etc/gitlab-runner/config.toml中のexecutorという項目で設定されています。

ここを書き換え、さらに適切な設定を追加すれば、Kubernetesなど他の環境をCIの実行環境にすることができます。

GitLa Runnerの登録の際に、Kubernetesで実行するように登録する場合は、executorの設定の時に、dockerと入力せずに、kubernetesと入力します。

注意

通常、Dockerを使うようにGitLab Runnerを設定しますが、Kubernetesも内部ではDockerを使っているため、そのままconfig.tomlだけ書き換えてサーバの方に適切な設定を付け加えれば動くと思うかもしれませんが、実はあるCIではうまく動きません。

そのCIとは、servicesを指定して、そのservicesとして実行しているコンテナにアクセスしているようなCIです。

実際に、Kubernetesで構築したGitLab RunnerでCIを回すと分かるのですが、servicesのコンテナにアクセスできません。

なぜこのようになるのかというと、Kubernetesではひとつ以上のコンテナをまとめたPodという考え方があり、例えばservicesのコンテナひとつとスクリプトを実行するコンテナのひとつの合計ふたつのコンテナはまとめて1つのPodとしてKubernetesで実行され、Podでは、ひとつのPodに複数のコンテナがある場合、それぞれのコンテナで通信をする際に127.0.0.1などのローカルループバックアドレスとポート番号でアクセスするからです。

そのため、例えばDockerでmysqlイメージを元にmysqlという名前でコンテナを作成して、そこに外部のコンテナからアクセスする時にはmysqlというホスト名を指定すればアクセスできますが、Kubernetesの場合、mysqlというホスト名でアクセスできないので127.0.0.1と指定する必要があるということです。

GitLab RunnerのExecutorとしてKubernetesを指定する場合は、ここに気をつけて、Kubernetesの環境に対応できるように.gitlab-ci.ymlなどを書き換える必要があります。

もちろん、servicesを指定していないような時にはこの限りではないので、Dockerの時と同じようなCIで大丈夫です。

さいごに

私はこの仕様を知るまで、なぜCIがうまくいかないのかかなり苦しみました。

誰かの参考になれば幸いです。