今回はGitLab CI/CDを使い始めるため、GitLabの案内するチュートリアルをやってみたのでそちらの紹介です。

GitLab CI/CDとは

GitLabのCI/CDを理解するうえで、事前にいくつかの用語を整理しておきます。

.gitlab-ci.yml

GitLab CI/CDを利用するには、GitLab Projectのルート直下に .gitlab-ci.yml というファイルを配置する必要があります。このファイルはGitLab CI/CDの設定や処理内容を定義するファイルであり、ここに記載された内容に従ってCI/CDを実行します。なお、 .gitlab-ci.yml というファイル名は別のものでも利用可能で、その場合はCI/CDの設定からファイル名を変更して実現します。

Runner

RunnerはGitLab CI/CDを実行するエージェントです。このエージェントは物理・仮想環境どちらでも利用可能です。

.gitlab-ci.yml にはジョブを実行するのに利用するコンテナイメージを指定できます。Runnerは指定されたイメージを取得し、GitLab Projectを取得し、エージェントのローカル、またはコンテナイメージ上でジョブを実行します。

SaaSを利用する場合、ユーザーが設定することで外部のホストをRunnerとして利用することもできますが、GitLabのホストする共有Runnerを最初から利用できます。共有Runnerは、複数のOSやCPU/GPU、インスタンスサイズの違うものから好きなものを利用できます。特に指定がない場合は Smallサイズ (2vCPU / 8GB)の Linux インスタンスが選択されます。なお、共有Runnerの利用できる上限は、契約しているプランによって変動します。

docs.gitlab.com

GitLab Self-managedの場合、新たにRunnerを登録するか、GitLabをホストするサーバー上にRunnerを導入することが可能です。

Pipeline

Pipelineは主に Job と Stage から成り立ちます。

Job には、例えば「Dockerfileからコンテナイメージをビルドする」「Pythonのアプリケーションに対して単体テストを実行する」「AWS上のEC2インスタンスにデプロイする」など、CI/CDの中で実行したいことを定義します。

Stage は1つ以上のJobを含み、いつJobを実行するかを決定します。同じStageに含まれるJobは同じタイミングで実行されます。典型的なStageは build test deploy などになります。

docs.gitlab.com

CI/CD variables

GitLab CI/CDではいくつかの環境変数が利用できます。これらの環境変数はどのJobからも呼び出し可能であり、これを利用することでJobやPipelineのふるまいを制御したり、Pipeline内で再利用したい値を一時的に保存したりすることができます。

docs.gitlab.com

CI/CD component

CI/CD componentsは再利用可能な単一のPipelineを構成するユニットです。componentsを利用することで、同一のPipelineコードを繰り返し記載することを避けることができたり、小さなPipelineを組み合わせて巨大なPipelineを構成することもできます。

docs.gitlab.com

チュートリアルの流れ

ここからはGitLabのチュートリアルに沿って .gitlab-ci.yml の作成からCI/CDの実行までを行います。

docs.gitlab.com

前提条件

チュートリアルを実施するには、いくつか前提条件があります。

(特に記載ありませんが) GitLab SaaSが利用可能な状態であること
GitLab Projectを作成済みであること
操作するアカウントが、プロジェクトに対して Maintainer または Owner Roleを付与されていること

今回は saas-cicd-example というプロジェクトを作成しました。またアカウントは Owner Roleを付与しています。

Runnerの確認

まず利用可能なRunnerがあるかを確認します。

Runnerの情報を表示するには、Projectの 設定 から CI/CD を選択し、その先にある Runner の項目を確認します。

Runner という項目の 展開 をクリックすると、利用可能なRunnerが表示されます。

今回は利用可能なRunnerは78台あることが表示されています。ここで最低1台、緑色で表示されているRunnerが存在すれば、利用可能なRunnerがあることを意味します。

.gitlab-ci.ymlの作成

Runnerの存在を確認したので、次に .gitlab-ci.yml を作成します。といってもここではアプリケーションコードやリソースなどの作成は行わず、テキストメッセージをログ上に出力するだけになります。

まず、今回の .gitlab-ci.yml を以下に示します。

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch,"
  environment: production

上記ファイルをProject上で作成し配置します。今回はGitLab UI上で新規ファイルを作成し、ファイル作成後は main ブランチに対し直接コミットします。

コミットするとPipelineが起動します。

ここで、今回の .gitlab-ci.yml について補足します。

Job

まずこのファイルを見ると、大きく以下のような構成となっていることがわかります。

<Jobの名称>:
  stage: <stageの名称>
  script: <scriptの内容>

.gitlab-ci.yml の基本的な使い方として、Job単位で処理を分けます。そして各Jobの中でStageやscriptを定義し、いつ・どんな処理を行うか定義します。

さらに一番最後の deploy-prod というJobは、stage・scriptに加えて environment という項目があります。これはJobがデプロイする先のenvironmentを定義しています。

environment はコードがデプロイされた場所を示すものです。これを利用すると、各環境に対するデプロイ履歴を管理し、どのサーバに何がデプロイされているかを知ることができます。またenvironmentはデプロイ先のURLを表示したり、使わなくなったenvironmentを簡単に削除したりもできます。

docs.gitlab.com