GKEでGitLab Runnerを動かしたい

2021年12月22日公開

これはドリコム Advent Calendar 2021の22日目です。
21日目は渡辺祥二郎さんのRokoko_Smartsuit Pro_Demonstrationです。

はじめに

GitLab.comで個人開発中のコード管理をしている。そこで、Shared Runnerを利用してCIを動かしていたが、制限が気になってきたことと、知的好奇心からAWSのEC2にGitLab Runnerを入れて利用していた。
cf. Autoscaling GitLab Runner on AWS EC2

しばらくそれでよかったのだが、個人開発しているWebサイトがGoogle Cloud Platform（GCP）を使っているので、請求書をGCPに全部寄せてしまいたい。（AWSはCIを動かすためだけにしか利用していないし）

ということで、GCPにある、Google Kubernetes Engine（GKE）を使ってCIが動くようにさせてみた。試験的に実施するため、AWSから引き上げる所まではせずにいる予定である。

やってみる

この記事の執筆者はKubernetes（k8s）の勉強をしながら移行作業をしているため、有識者の方から見ると不可解な設定をしているかもしれない。どうか私の右往左往する様を微笑ましくみていただければと思う。また私と同じようにやってみたい方がいるかもしれない。その時は公式ドキュメントの傍らに作業動画を流す感覚で読んでいただけると幸いだ。

基本的にはGitLab RunnerのHelmチャートを参考に実施していくので、大きく外すことはないと思う。 cf. GitLab Runner Helm Chart Helmとは、チャートと呼ばれるKubernetesパッケージを管理するためのツールであり、こちらを利用してGitLab Runnerをインストールする。ここでは「インストールするために必要なツール」ぐらいの認識で問題ないと思う。詳細はKubernetes Helm アーキテクチャを参考にしてほしい。

クラスタの作成

まず初めにクラスタを作成する。GCPからKubernetesのページに行き、作成を開始する。
cf. ゾーンクラスタを作成する

作成を開始すると、Standardまたは、Autopilotのどちらかを選択するように聞かれるので、ここではStandardを指定する。

Autopilotについては、GCPが用意している運用モードの1つで、色々自動でいい感じにやってくれるそうなのだが、k8s初心者にとって何が問題でエラーが発生するのかわからないので、シンプルに動いてくれそうなStandardを選択して進めた。
cf. クラスタのタイプ#運用モード

作成するために設定項目を設定していく。とりあえず名前については、gitlab-runner-standard-clusterとした。
マシンファミリーはe2-mediumに、ブートディスクは32GBにした。ここの値は割と適当で、とりあえず動いた後考えることにする。料金については以下のサイトで計算できるので、気になる人は諸々の設定値を決めた後、やっておいた方が良いかもしれない。
cf. Google Cloud Pricing Calculator

プリエンプティブルノードを有効にする。これは、可用性を失う代わりにコストが安くなる。AWSでいうところの、スポットインスタンスのようなもので、GCP側の都合でシャットダウンが発生する、最長24時間しか使えないなどの制限がある。
cf. プリエンプティブルVMを使用してフォールトトレラントワークロードを実行する
私の場合は、CIで短時間だけ回すため、この制限を受けづらいのではという推測と、もしシャットダウンされてジョブ失敗してもリトライすればいいだけなので、あまり気にせずに有効にした。

あとは全てデフォルトのままで、クラスタを作成する。

Helmを用意する

ここからはローカルにて作業を進める。

helm自体をインストールしていなかったので、brew経由でインストールする。
$brew install helm
cf. Helmのインストール
この時のバージョンはv3.7.1だった。

GKEへのGitLab RunnerのインストールとGitLab Runnerの登録

ここでインストールガイドの前提条件が終わったので、ドキュメントを参考にGitLab Runnerをインストールしていく。
cf. GitLab Runner Helm Chart

まず初めにGitLabHelmリポジトリを追加
$helm repo add gitlab https://charts.gitlab.io
次にGitLab Runnerのconfigファイルを用意する。以下に基本となるyamlファイルがあるので、これをベースに少し修正していく。
https://gitlab.com/gitlab-org/charts/gitlab-runner/blob/main/values.yaml

以下に変更点のみ記載する。


replicas: 3
gitlabUrl: https://gitlab.com/
runnerRegistrationToken: "<Runner Token>"
concurrent: 10
rbac:
  create: true
runners:
  tags: "gke-standard"

変更必須項目は、gitlabUrlとrunnerRegistrationTokenの2つになる。
gitlabUrlについては、私は、GitLabをGitLab.comで使っているので、https://gitlab.comを指定する。 <Runner Token>には、GitLabの Setting > CI/CD Settings > Runners > Specific Runnersにあるtokenを記入しておく。

それ以外の項目については、ベースになっているvalues.yamlにコメントアウトで諸々書いているので必要な設定をしていければ良いかと思う。

今回変更した点については、EC2で動かしていた時の設定値を参考に設定しているので、もしかしたら無駄な設定が入っているかもしれない。この辺りは今後の課題にしておいて、先に進む。

次に用意したconfigファイルを使ってインストールを実施する。最初にクラスタに接続する。
$ gcloud container clusters get-credentials gitlab-runner-standard-cluster --zone us-central1-c --project project-dev
次にnamespaceを作成しておく。ここではgitlab-runner-nsとした。
$ kubectl create namespace gitlab-runner-ns
先ほど用意したvalues.yamlファイルを使ってインストールを実行する。
$ helm install --namespace gitlab-runner-ns gitlab-runner -f ./values.yaml gitlab/gitlab-runner

この作業をすると、GitLabのAvaiable specific runnersにランナーが追加されていることを確認できる。

GitLabの設定画面にあるAvailable specific runnersで新規追加を確認

また、GCP側にも追加されていることを確認できるはず。

GitLab CIの動作確認

configファイルの中身にて、tagsにgke-standardと入れたので、このタグをCI実行時に指定することで、動作するようにしてみる。
.gitlab-ci.ymlの先頭に以下を追加する。


default:
  tags:
    - gke-standard

とりあえず動くのをテストするため、.gitlab-ci.ymlファイルを以下のようにして動かしてみることにする。


default:
  tags:
    - gke-standard

image: node:12

stages:
  - test

echo:
  stage: test
  script:
    - echo 'hello'

パイプライン見に行って動作することを確認した。

テストの動作確認はできたため、次に進む。 GKEへ移行することができるかを確認するために、元々の.gitlab-ci.ymlに戻して動作確認したところ、ジョブが成功したことを確認できた。しかし、EC2の時は4分前後かかっていたのに、GKEでは13分かかっている。単純にEC2の時にハイスペック指定していたわけでもないため、GKEのマシンファミリーを変更するだけでは解決しなさそう。 CPU、メモリ、ディスクを見にいくとこんな感じだった。