Amazon EKSクラスターにHelmを使ってGitLab Runnerをインストールしてみる

佐藤雅樹
2025.03.18
 GitLab Runnerとは以下の記事をご確認ください。
https://dev.classmethod.jp/articles/kubernetes-executor/
 やってみた GitLab Web GUIからRunnerを作成・トークン発行GitLabとGitLab Runnerの通信は「プル型」アーキテクチャを採用しています。
Runner側からGitLabへ接続をする形です。
接続のためにGitLab側では、Runnerの作成及びトークン発行を行う必要があります。
今回はGitLabインスタンス内のすべてのプロジェクトで利用できる共有ランナーを設定します。
Search -> Admin Area ->CI/CD -> Runners -> New instance runner の順に選択します。
任意のTagsを設定します。
Run untagged jobsをチェックして、タグ付けされていないジョブも実行できるようにします。
Create runnerを選択します。
Registrer runnerの画面に遷移します。
Helmインストール時にTokenを使いますので、控えておいてください。
ここまでできたら、EKS側の作業にはいります。
https://docs.gitlab.com/ci/runners/runners_scope/
 GitLab RunnerをHelmでインストールまずはgitlab-runner用のnamespaceを作成します。
kubectl create namespace gitlab-runner
values.yamlを用意します。今回は検証用のため、最低限の設定とします。
GitLabのURLと、先ほど発行したTokenをセットします。
 values.yaml
gitlabUrl: https://gitlab.example.com/ # 環境に合わせて置き換える
runnerRegistrationToken: "<Token>"
rbac:
  create: true
helmでリソースをデプロイします。
helm install --namespace gitlab-runner gitlab-runner -f values.yaml gitlab/gitlab-runner
 出力例
NAME: gitlab-runner
LAST DEPLOYED: Mon Mar 17 19:31:53 2025
NAMESPACE: gitlab-runner
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Your GitLab Runner should now be registered against the GitLab instance reachable at: "https://gitlab.example.com/"

Runner namespace "gitlab-runner" was found in runners.config template
helm repoの追加がまだの場合や、Helmチャートの詳細が気になる場合は以下をご確認ください。
https://docs.gitlab.com/runner/install/kubernetes/
deploymentsやpodsが稼働していれば、正常です。
kubectl get deployments.apps -n gitlab-runner
 出力例
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
gitlab-runner   1/1     1            1           4m39s
kubectl get pod -n gitlab-runner
 出力例
NAME                             READY   STATUS    RESTARTS   AGE
gitlab-runner-6887758ccf-hctk6   1/1     Running   0          5m27s
 動作確認GitLab上からRunnerを確認してみます。
Search -> Admin Area-> CI/CD -> Runners の順に確認すると、以下のようにRunnerが表示されます。
実際にRunnerを動かしてみます。
テスト用の設定ファイルを作成して、GitLabにMerge Requestを作成します。
 .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

# 簡単なテストジョブ
test_job:
  stage: test
  image: alpine:latest
  script:
    - echo "Running test job..."
    - ls -la
    - pwd

# ビルドジョブの例
build_job:
  stage: build
  image: node:16-alpine
  script:
    - echo "Running build job..."
    - node -v
    - npm -v
    - echo "Building application..."
    - sleep 10  # 擬似的なビルド時間
    - echo "Build completed!"

# デプロイジョブの例
deploy_job:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Running deploy job..."
    - echo "Deploying to test environment..."
    - sleep 5  # 擬似的なデプロイ時間
    - echo "Deploy completed!"
  environment:
    name: test
Merge Requestを確認するとパイプラインが動作していることを確認できました。
 おまけ: EKSクラスターにデプロイしたGitLab側のGitLab Runnerを無効化するGitLab自体もEKSクラスターでセルフホストしている場合もあると思います。
Helmデプロイ時にデフォルトでEKSクラスター上でGitLab Runnerは有効になります。
別で管理したい場合は、以下を追加することでGitLab側のGitLab Runnerを無効化できます。
 values.yaml
gitlab-runner:
  install: false
https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/2k.yaml
ちなみに、公式ドキュメントには以下の記載があり、本番環境ではGitLabとは別のマシンで稼働させることが推奨されています。
The default configuration of the included GitLab Runner chart is not intended for production. It is provided as a proof of concept (PoC) implementation where all GitLab services are deployed in the cluster. For production deployments, install GitLab Runner on a separate machine for security and performance reasons.
付属の GitLab Runner チャートのデフォルト構成は、本番環境向けではありません。これは、すべての GitLab サービスがクラスターにデプロイされる概念実証 (PoC) 実装として提供されています。本番環境のデプロイメントでは、 セキュリティとパフォーマンス上の理由から、GitLab Runner を別のマシンにインストールしてください。
Using the GitLab Runner chart | GitLab Docs
 おわりにGitLab RunnerをEKSクラスターにインストールしてみました。
次の記事では、GitLabとGitLab Runnerを同一EKSクラスターで動作させつつ、別ノードで実行する方法を検証しようと思います。