GitLab CI/CDのGitLab Runnerでジョブを動かす方法
仕事のソースコード管理にGitLabを使っていて、CI/CDに関してもGitLab CI/CDを使っているのですが、いまいち仕組みがよく分からなかったので学習のために以下のQuick Startチュートリアルをやってみました。その時の手順を書いてみます。
また、普段はセルフホストのGitLabを使っていますが、今回は手頃なGitlab.com環境で試してみます。
事前に行ったこと
- Gitlab.comのアカウント取得
- 任意のプロジェクトを作成し、リポジトリ作成
作成したGitLabリポジトリ
以下の手順で作成したCI/CDプロジェクトを作ってみました。もし、よろしければ実際にどのように結果が出力されるか等確認してみてください。 gitlab.com
CI/CDプロセスの概要
GitLab CI/CDを使うために以下を行いました。
- CI/CDジョブを動かすGitLab Runnerが利用可能か確認
- リポジトリのルートに
.gitlab-ci.yml
(ジョブを定義するファイル) 作成
CI/CDジョブを動かすGitLab Runnerが利用可能か確認
GitLab公式のドキュメントによると、GitLab RunnerとはGitLab CI/CDと連携し、パイプラインでジョブを実行するためのアプリケーションとのことです。
GitLab.comのリポジトリを開き、[設定]=>[CI/CD]の Runner
の箇所で稼働中のRunnerを確認できます。
GitLab Runnerには以下の2種類のRunnerがあるようで、GitLabでリポジトリを作成した時点で最初からShared runnersは利用可能なようでした。
- Shared runners (複数プロジェクトのジョブを共有のRunnerで処理する方式)
- Specific runners (特定のプロジェクトのジョブのみ実行する方式)
Shared runnersでCI/CDジョブを処理する分には、gitlab.comでRunnerに関する事前作業は必要なさそうです。次に.gitlab-ci.yml
(ジョブを定義するファイル)を作成していきます。
リポジトリのルートに.gitlab-ci.yml 作成
.gitlab-ci.yml
はGitLab CI/CDの具体的な指示を設定するYAMLファイルとのことです。
リポジトリのルートに以下内容の .gitlab-ci.yml
を作成します。作成方法は、GitLabのUI上で作成する、またはローカルでファイルを作成してgit pushするでもどちらでもOK。
build-job: stage: build script: - echo "Hello, $GITLAB_USER_LOGIN!" test-job1: stage: test script: - echo "このジョブは何かをテストする" test-job2: stage: test script: - echo "このジョブは何かをテストしますが、test-job1より時間がかかります" - echo "echoコマンドの後、20秒のsleepコマンドを実行します" - echo "これはtest-job1より20秒長いテスト実行をシミュレートしてます" - sleep 20 deploy-prod: stage: deploy script: - echo "このジョブは $CI_COMMIT_BRANCH ブランチから何かをデプロイします"
commitが作られると自動的にパイプラインが作られます。
パイプラインの確認
CI/CD > パイプラインを選択すると実行されているパイプラインを表示できます。
ステータスをクリックすると、パイプラインの詳細情報を表示できます。
stageがbuild, test, deployの順でジョブが実行され、全てのジョブが成功するとパイプラインのステータスも「成功」に変わります。
.gitlab-ci.yml tips
ここまででQuick Startは終わりですが、記事中の.gitlab-ci.yml tipsという項目を読んでおくと、色々なCI/CDを実装する上でのベースとなる知識が得られて良さそうでした。内容を記載しておきます。
- .gitlab-ci.ymlファイルを作成したら、それ以降の編集はすべてパイプラインエディタで行ってください。パイプラインエディタを使用すると、次のことができます。
- パイプラインの設定を、自動的な構文強調表示と検証を使用して編集する。
- CI/CD設定の視覚化、.gitlab-ci.ymlファイルのグラフィック表示の表示。
- ランナーがDockerコンテナを使ってジョブを実行する場合は、.gitlab-ci.ymlファイルを編集してイメージ名を記述してください。
default: image: ruby:2.7.4
- 各ジョブにはスクリプトとステージが含まれます。
- default キーワードは、before_script や after_script などのデフォルトの設定をカスタムするためのものです。
- ステージは、ジョブの順次実行を記述します。1つのステージのジョブは、利用可能なランナーがある限り、並行して実行されます。
- ステージの順序から外れてジョブを実行するには、Directed Acyclic Graphs (DAG)キーワードを使用します。
- ジョブやステージの実行方法をカスタマイズするために、追加で設定できます。
- rules キーワードを使用して、ジョブを実行またはスキップするタイミングを指定します。従来のキーワードであるonlyとexceptはまだサポートされていますが、同じジョブでルールと一緒に使用することはできません。
- キャッシュとアーティファクトを使用して、ジョブやステージ間の情報をパイプラインで永続的に維持します。これらのキーワードは、各ジョブでエフェメラルランナーを使用している場合でも、依存関係やジョブ出力を保存するための方法です。
- .gitlab-ci.ymlの完全な構文については、.gitlab-ci.ymlの完全なリファレンス・トピックを参照してください。
実際のプロジェクトへの適用に際して
WEB IDEでテンプレートが用意されているため、プロジェクトに適したテンプレートを選択すると楽にCI/CDを導入できそうです。
感想
Github Actionsの.github/workflows
とあまり変わらないのでYAMLの定義は難しくなさそうと感じましたが、日本語のドキュメントが少なく細かい設定を調べるのが少し大変そうだなと思いました。
また、Github Actionsと異なる点として、Runnerの種類(Shared Runners・Specific Runners)があったりと色々なことができそうですが、その反面設定が複雑で分かりにくく感じました。