【GitOps】GitLab RunnerでCFn変更スタックを作成するCIパイプラインを作ってみた！

近年、CI/CD(継続的インテグレーション/継続的デリバリー)という概念がよく使われるようになってきました。

CI/CDというとAWSのCodePipelineやCircleCIのサービスを想像する方が多いと思うのですが、GitLabでもCI/CDサービスを利用することができます。

本記事では、GitLab CI/CDを利用したCloudFormationの変更セットを自動作成する簡易CIパイプラインを組んでみようと思います。

概要
ハンズオン
まとめ
1. 参考

概要

GitLab CI/CDについて

GitLab CI/CDとは、GitLabの組み込みツールで、サードパーティ製品を用いずに継続的な開発手法(継続的インテグレーション、継続的デリバリーetc..)を利用することができます。

実態は、.gitlab-ci.ymlというファイルで構成されています。
ファイル内に記載されている内容に従って、後述のrunnerがジョブを実行してパイプラインを構成します。

勿論無料で利用できます。

GitLab Runnerについて

上述の通り、GitLabではGitLab CI/CDというCI/CDを実行するツールがありますが、あくまでツールであり、GitLab CI/CD自体がビルド等のジョブを実行するわけではありません。
この実際にジョブ処理を実行するアプリケーションがGitLab Runnerです。

分かりやすく言うとJenkinsに近い機能ですね。

また、GitLabには2種類の動作モードが存在します。
それぞれの動作モードの違いを以下に記載します。
※本記事では、”Shared Runners”を使用します

Shared Runners
プロジェクト毎にrunner実行用の環境を用意しなくてもよい。
Specific Runners
プロジェクト毎にrunner実行用の環境を立てる必要があります。
runner実行用の環境にプロジェクト固有の設定ができます。

executorについて

GitLab Runnerにはジョブの実行方式であるexecutorを選択することができます。
executorには下記7種類が存在します。

Shell
Docker
Docker Machine and Docker Machine SSH (autoscaling)
Parallels
VirtualBox
SSH
Kubernetes

本記事の概要

本記事では、GitLab Runnerを利用して、CIパイプラインを構築するハンズオン手順を公開します。
具体的には、以下の目標とハンズオン手順を公開します。

目標
GitLabへのpushをトリガーにCloudFormation 変更セットを自動作成するCIパイプラインを構築する。
経路：[GitLab] –> [CodeBuiled] –> [CloudFormation]

ハンズオン手順
1. GitLab Runner環境を構築
  ※GitLab自体にrunnerを組み込むことも可能ですが、一般的にはrunner用のEC2インスタンスを別途構築するのが一般的とされています。
  ※RunnerのexecutorはDockerを選択します。
2. Runnerの設定
3. CIパイプラインの構築
4. パイプラインの動作確認
  実際にGitLabにソースコードをpushして、変更セットが作成されるのかを確認します。

本記事での実行環境

環境：AWS
GitLab(OSS)
- EC2インスタンス(GitLab)
  GitLabは既に構築済みであり、基本的な利用方法は理解している前提
  ※作成手順参考 –> https://chibinfra-techblog.com/gitlab-build-to-amazon-linux-2/
GitLab Runner(Docker)
- EC2インスタンス(runner)
  本記事で作成します

ハンズオン

GitLab Runner環境を構築

概要でも説明しましたが、Runnerはそれ自体がアプリケーションとして動作します。
なので一般的には、Runner用のサーバを別途で立てて、GitLabと連携させて使用します。

とりあえず、Runner用のEC2インスタンスを別途立てて、DockerとRunnerのインストールまでを行います。

下記最低限のスペックのEC2インスタンスを構築します。
- OS：AmazonLinux2
- インスタンスサイズ：t2.micro
- EBS(ストレージサイズ)：8GB
- NW：GitLabインスタンスと通信が取れる環境、または通信が取れるようなNW構成にすること
EC2インスタンスにSSH接続します。
GitLab Runnerをインストールします。

## GitLab Runnerのリポジトリを登録します
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | bash
## GitLab Runnerのインストール
$ yum install -y gitlab-runner

Dockerをインストール、及び起動します。

## Dockerをインストールします
$ yum install -y docker
## Dockerを起動します
$ systemctl start docker
$ systemctl enable docker

GitLab Runnerの設定

インストールしたGitLab Runnerの設定を行います。
GitLabで生成された認証トークンをRunner用インスタンスに登録することで、GitLabとRunnerを連携します。

GitLabのコンソール画面を開き、プロジェクトを開き、左ペイン「Settings」→「CI/CD」→「Runnsers　settings」でトークンを取得します。
※本記事では、動作モードとしてSpecific runnersを採用します。

再度GitLab Runner用インスタンスを開き、下記GitLabで取得した認証トークンを登録します。

## トークンを登録する
$ gitlab-runner register
[root@localhost ~]# gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

http://xxx.xxx.xxx.xxx/
xxx.xxx.xxx.xxx    ★★★ 管理画面で表示されたアドレスを入力します。
Please enter the gitlab-ci token for this runner:
<Token ID>    ★★★ 管理画面で表示されたTokenを入力します。
Please enter the gitlab-ci description for this runner:
[localhost.localdomain]: CI example     ★★★ CIの説明を入力します。
Please enter the gitlab-ci tags for this runner (comma separated):
<Null>   ★★★ タグを設定します。必須ではありません。
Registering runner... succeeded                     runner=RyzTLrtE
Please enter the executor: docker, shell, virtualbox, kubernetes, docker-ssh, parallels, ssh, docker+machine, docker-ssh+machine:
docker    ★★★ executorを選択します
Please enter the default Docker image (e.g. ruby:2.1):
centos:centos7    ★★★ Dockerイメージを指定します
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

GitLab Runnerを起動します。

$ systemctl start gitlab-runner
$ systemctl enable gitlab-runner

GitLabで、Runnerが登録されたか確認します。
先程認証トークンを取得した「Specific runners」の下に、登録したRunnerの情報が追加されていることを確認します。

CIパイプラインの構築

GitLabのCI機能の実態は、.gitlab-ci.ymlというファイルです。
このファイルをアプリケーションからGitLabへpushをトリガーに、GitLab Runnerが発火し、ファイルのコードを順次実行していきます。

本記事では以下のCIパイプラインを構成します。

GitLabリポジトリへのpushをトリガーにS3バケットを作成するCloudFormation変更セットを自動ビルドする

下記構成のテストディレクトリを作成します。

TestCFnDir/
　├ README.md
　├ create_s3.yml
　├ create_s3.sh
　├ .gitlab-ci.yml

それぞれのファイルの中身を以下に記載します。

.gitlab-ci.yml

image: centos:centos7
stages:
    - test
example:
    stage: test
    script:
        - sh create_s3.sh

create_s3.yml

---
AWSTemplateFormatVersion: 2010-09-09
Description: "Launch a Test-S3-Bucket"


### Resources ###
Resources:
# ------------------------------------------------------------
# S3 Bucket
# ------------------------------------------------------------
### テスト用S3バケット ###
  TestS3Bucket01:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: tests3bucket01
      VersioningConfiguration:
        Status: Enabled

create_s3.sh

image: centos:centos7
stages:
    - test
example:
    stage: test
    script:
        - sh create_s3.sh

動作確認

ディレクトリの準備ができたらGitLabへ更新内容をpushします。
GitLabにてジョブが発火していることを確認し、しばらく待った後、CloudFormationコンソールより変更セットが作成されていることを確認します。

また、CIの実行状況は以下のページから確認することができます。

遷移方法：「GitLab」–>「プロジェクト」–>「CI/CD」–>「jobs」

概要

GitLab CI/CDについて

GitLab Runnerについて

executorについて

本記事の概要

本記事での実行環境

ハンズオン

GitLab Runner環境を構築

GitLab Runnerの設定

CIパイプラインの構築

動作確認

まとめ

参考

コメント