トップ > GitLab > GitLabランナーについてまとめてみた

GitLabランナーについてまとめてみた

GitLab CI/CD DevOps
記事タイトルとURLをコピーする

はじめに

こんにちは！サーバーワークス橋本です。
5月に入り、爽やかな暑さを感じるまでになってきました。
梅雨に入るとじめっとしてくるので個人的にはこの季節が一番好きだったりします。

今回は、今まで理解が曖昧になっていたランナーについて理解を深めてみたのでまとめてみました。
少し前に書いたブログにもランナーについて触れていますが、改めて焦点を当ててみようと思います。

GitLabの種類について

GitLabの種類によって使えるランナーが変わります。 GitLabは以下の種類があります。
まずは、これらの違いを押さえておくとランナーを学ぶ上で理解度が高くなります。

SaaS

GitLab社が提供するSaaS版のGitLabです。 アカウントを作成するだけでWebブラウザから手軽に利用することができます。
SaaS版からさらに以下が分かれます。

Gitlab.com（共有版）

個人とかお試しで使われる場合は大体こちらが利用されています。

GitLab Dedicated（顧客専用版）

SaaS環境で厳格なセキュリティやコンプライアンスを求める場合に利用されます。

Self-Managed（自己管理版）

所有するサーバにインストールして運用する自己管理版のGitLabです。
より柔軟なカスタマイズやセキュリティ要件に対応できます。
セキュリティが厳しい企業が使っているのは大体こちらです。

GitLab Runnerとは何か？

GitLab RunnerはGitLab CI/CDと連携してパイプラインでジョブを実行するアプリケーションです。（公式抜粋）

これをもう少しわかりやすくすると、 GitLab CI/CDはプロジェクトの.gitlab-ci.ymlファイルにどういうパイプラインを行うか指示書を記載するのですが、当然これだけでは動作しません。
その指示書を使って実際に動かすのがGitLabランナーの仕事ということになります。

具体的に言うと、以下の流れとなります。

  1. ユーザーがソースをプッシュ
  2. gitlab-ci.ymlの指示内容を読み込む
  3. ランナーにパイプラインを実行指示する。
  4. ランナーがパイプラインを実行する。
  5. パイプラインの実行結果を返却する。
  6. 実行結果をユーザーにステータスとして表示する。

このようにランナーはGitLabのパイプラインを実行するために必要不可欠な存在となります。

ランナーの種類

GitLabのパイプラインを利用するために必要不可欠なランナーですが、利用形態によって様々な種類があります。
それぞれの特徴や用途を踏まえて最適なランナーを利用します。

GitLab-hosted runners

GitLab.com（SaaS GitLab）でCI/CDの処理を実行する際、特に何も設定しなくてもパイプラインが動作します。
これはGitLabがデフォルトで用意している「GitLab-hosted runners」（別名SaaSランナー）と呼ばれるランナーが動作しているから可能となります。

このSaaSランナーについてはプロジェクトを作成した時点で自動的に「有効」になっているため特に何かを設定する必要はありません。
非常に手軽にGitLabパイプラインを利用することができます。
ただし、使用できるのはGitlab.com（共有版）を利用する場合のみです。
※残念ながら同じSaaSのGitLab Dedicated（顧客専用版）では利用できません。
また、利用料がかかるためその点も注意する必要があります。

利用料の詳細は公式を参照ください。

ちなみに呼称が結構あるのですが全部同一です。

  • SaaSランナー（SaaS runners）
  • 共有ランナー（Shared runners）
  • ホストランナー（GitLab-hosted runners）

Self-managed runners

GitLabランナーをインストールし、SaaS版GitLabや自己管理版GitLabにランナーを登録して利用します。

プライベートネットワークで利用したい場合などのセキュリティ制御が必要である場合やカスタマイズしたい場合に利用します。

また、様々なExecutorsをサポートしているのでShell以外にDockerやKubernetesなどをパイプラインで利用したい場合はこちらを利用します。
※Executorについては後ほど説明します。

こちらも呼称が結構あるのですが全部同一です。

  • オンプレミスランナー（On-premises runners）
  • 専用ランナー（Dedicated runners）
  • マネージドランナー（Self-managed runners）

Executorについて

Executer（エグゼキューター）とは、パイプラインを実行する際に使用する実行環境です。

代表的には以下があります。

  • Shell
  • Docker
  • VirtualBox
  • Kubernetes

これらのExecuterを適切に選択することで実行環境を柔軟に管理することが出来ます。
図はDockerをExecuterに使用した例となります。
Dockerを利用することで異なる環境でも同じようにビルド・テストを実行したい場合に有効です。

Self-managed runnersのExecuterについて

Self-managed runnersの場合、どのExecuterを使用するかはconfig.tomlの設定内容から判断します。 ※config.tomlとは、GitLabランナーをインストールしたサーバーの設定ファイルです。
以下はconfig.tomlでExecuterにdockerを設定した例です。 通常はランナー登録時に対話形式により設定を入力する過程でconfig.tomlが作成されます。

# ジョブの最大同時実行数
concurrent = 5

# Runnerの設定
[[runners]]
  # Runnerの名前
  name = "example-runner"
 
  # GitLabサーバーのURL
  url = "https://gitlab.example.com/"
  
  # Runnerの登録トークン
  token = "example-token"
  
  # 実行環境のタイプ
  executor = "docker"

  # ビルドディレクトリのパス
  builds_dir = "/builds"
  
  # キャッシュディレクトリのパス
  cache_dir = "/cache"


  # Dockerの実行環境設定
  [runners.docker]

    # Dockerイメージ
    image = "ubuntu:20.04"
    
    # TLS検証の有効化
    tls_verify = false
    
    # 特権モードの有効化
    privileged = false
    
    # ボリューム設定
    volumes = ["/cache:/cache:rw", "/var/run/docker.sock:/var/run/docker.sock"]

    # ネットワーク設定
    network_mode = "bridge"

GitLab-hosted runnersのExecuterについて

GitLab-hosted runnersについてはSaaSになるため、ランナーの設定内容はGitLab社管理となるためユーザー側で変更は出来ません。

SaaSランナーのExecuterについては実行環境のOSを選択することで以下の様に変わります。
OSの選択は、gitlab-ci.ymlのタグにOSを指定することで判断するようになっています。（何も指定しない場合はLinuを使います。）

  • Linuxを選択した場合 ExecuterはDockerになり、実行環境のコンテナを生成してジョブを実行します。
# Linux設定例
stages:
  - build
job:
stage: build
 tags:
  - saas-linux-large-amd64
  • MacOSを選択した場合 ExecuterはShellになり、GitLabが用意されたMacOS環境に実行されます。
# MacOS設定例
.macos_saas_runners:
  tags:
    - saas-macos-medium-m1
  • Windowsを選択した場合 ExecuterはPowerShellになり、GitLabが用意されたWindows環境に実行されます。
# WindowsOS設定例
.shared_windows_runners:
  tags:
    - shared-windows
    - windows-1809

さいごに

今回のブログでは、GitLab CI/CDにおけるGitLabランナーの役割と種類、そしてExecutorについて共有しました。なんとなくランナーのイメージがつかめたでしょうか？
GitLabランナーは、CI/CDパイプラインを実際に動かすエンジンであり、その種類やExecutorの選択は、開発ワークフローを構築する上で非常に重要です。
引き続き学習を深めていこうと思います。

はしもと しんご(記事一覧)

アプリケーションサービス部ディベロップメントサービス２課

猫が好きです。