1. 記事一覧 >
  2. ブログ記事
category logo

Kotlin+Spring Bootのアプリを GitLab CI/CD によるDockerデプロイまで全手順

(更新) (公開)

はじめに

Kotlin + SpringBoot で REST API 実装

GitLab CI/CD パイプライン発動

テスト/ビルド

Docker ビルド

デプロイ
の流れを


最初から最後までやってみましたので、その全手順になります。


Kotlin + SpringBoot で REST API 実装については、別記事「Kotlin + Spring Boot + Docker ビルド(Gradle, Fat JAR)まで全手順」にありますので、省略して、その続きからになります。
/home/admin/demo にソースコードが有る状態とします。


全体像は以下です。
・develop ブランチにソースコードが push されたら、GitLab CI/CD パイプライン発動
  →localhost の docker ビルド&デプロイのみ
・master ブランチにソースコードが push されたら、GitLab CI/CD パイプライン発動
  →localhost の docker ビルド&デプロイ + 本番サーバの docker ビルド&デプロイ(ただし、本番サーバーについては、手動起動とする。)

GitLab CI/CD 完成図


本記事にベストプラクティス的な趣旨は有りません。

本番サーバのdockerビルド&デプロイは、AWS ECS、AWS EKSなどにデプロイすれば、実運用っぽくなると思いますが、そこまでは実施しません。

全て一つのマシンにインストールする必要はありません。一つのUbuntuマシンにIntelliJ IDEA、Docker、GitLab、GitLab Runnerと詰め込み過ぎて、最初メモリ4GBにしていましたが、8GBにしないとまともに動かなくなりました。


【検証環境】

Ubuntu 20.04.2 LTS

 IntelliJ IDEA 2022.1.2(Community Edition)

 Docker version 20.10.17, build 100c701

 GitLab CE 15.0.2

 gitlab-runner 15.0.0

 gradle:7.3.3-jdk17-alpine


GitLab CI/CD 基本

まずおさえておきたい基本用語です。作業進行中にもなるべく説明していますので、ここで去らないでください...。


【CI(継続的インテグレーション)】

リポジトリへのプッシュごとに、アプリケーションにエラーが発生する可能性を減らすために、

アプリケーションを自動的にビルド、テストするためのスクリプトを作成できます。


【CD(継続的デリバリー)】

コードベースに変更がプッシュされるごとにビルド、テストされます。

それだけではなく、手動でデプロイを開始するステップを追加して、継続的にデプロイされます。


【継続的デプロイ】

継続的デリバリーとの違いは、アプリケーションを手動でデプロイするのではなく、

自動的にデプロイされるように設定することです。アプリケーションをデプロイするために、

人の介入は全く必要ありません。


【パイプライン】

CI/CD一連の自動化された工程の事です。

設定ファイル .gitlab-ci.yml をリポジトリに追加すると、

GitLabがそれを検出して GitLab Runner というツールを使ってスクリプトを実行します。

スクリプトはジョブとしてグループ化され、パイプラインの構成要素となります。

.preは、常にパイプラインの最初のステージであることが保証されています。

.postは、常にパイプラインの最後のステージであることが保証されています。

GitLab CI/CD 設定ファイル .gitlab-ci.yml の説明

Runner(CI/CD 実行体)は、以下の3種類ありますが、今回は、Specific runners を利用します。

Runner 種類利用可能範囲
Specific runners特定のリポジトリ
Group runners特定のグループ
Shared runnersすべてのリポジトリ

Docker インストール

GitLab CI/CD Dockerインストール 図

GitLab、GitLab Runner(GitLab CI/CD を実行するもの)を Docker でインストールしようと思いますので、Docker をインストールします。
アプリのデプロイも Docker でビルド&デプロイしますので、Docker インストールが必要です。

# apt update
# apt install -y apt-transport-https ca-certificates software-properties-common
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
# apt update
# apt install -y docker-ce
# docker -v
Docker version 20.10.17, build 100c701

docker-compose up で GitLab、GitLab Runner を起動しますので、docker-compose 1.29.2 をインストールします。

# curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose
# docker-compose --version
docker-compose version 1.29.2, build 5becea4c

GitLab インストール

GitLab CI/CD GitLabインストール 図

docker-compose.yml を作成します。


Docker Hub の gitlab/gitlab-ce:latest を利用します。
ホスト名: gitlab-ci.example.com
URL: https://gitlab-ci.example.com
GitLab のコンテナレジストリ API URL: https://gitlab-ci.example.com:5005
redirect_http_to_https=true により、GitLab Container Registry を有効化しています。)
初期パスワード: adminadmin


【GitLab Container Registry】

GitLabのコンテナレジストリ。GitLabのコンテナレジストリとは、Docker Hubのようにコンテナをpushできる場所になります。オフライン運用できるプライベートDockerレジストリです。

# mkdir /home/admin/gitlab
# cd /home/admin/gitlab
# vi docker-compose.yml
docker-compose.yml
services:
  web:
    image: 'gitlab/gitlab-ce:latest' # gitlab/gitlab-ceイメージ最新バージョンをDocker Hubからpull
    restart: 'always' # 自動起動on
    hostname: 'gitlab-ci.example.com' # GitLabサーバーホスト名
    environment:
      # /etc/gitlab/gitlab.rbの設定を環境変数GITLAB_OMNIBUS_CONFIGに記述
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab-ci.example.com' # GitLabのURL
        registry_external_url 'https://gitlab-ci.example.com:5005' # GitLabのコンテナレジストリAPI URL
        gitlab_rails['gitlab_ssh_host'] = '192.168.11.6' # GitLab sshホスト名(本記事では使わない。)
        gitlab_rails['initial_root_password'] = 'adminadmin' # rootユーザーパスワード(後から変更可)
        gitlab_rails['registry_enabled'] = true # GitLab Container Registry を有効化
        nginx['redirect_http_to_https'] = true # http://で来たら、https://にリダイレクト
        nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab-ci.example.com.crt" # ssl証明書
        nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab-ci.example.com.key" # ssl秘密鍵
    ports:
      - '80:80'
      - '443:443'
      - '2222:22' # sshポート(Ubuntu標準の22ポートと被るため、2222に変更)
      - '5005:5005' # GitLab Container Registryポート(registry_external_urlに合わせる。)
    volumes:
      # 永続化したいデータとSSL証明書関係をホスト側で共有
      - './config:/etc/gitlab'
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'
      - './ca.crt:/etc/gitlab/ssl/gitlab-ci.example.com.crt'
      - './ca.key:/etc/gitlab/ssl/gitlab-ci.example.com.key'
      - './ca.csr:/etc/gitlab/ssl/gitlab-ci.example.com.csr'
    shm_size: '256m' # コンテナが使用する共有メモリサイズ(適当。)

ssl key を作成します。
今回、自己署名証明書作成になります。既に有る場合、./ca.crt, ./ca.key, ./ca.csr を配置します。

# openssl genrsa -out ca.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
................................................................................................................................................+++++
.............................+++++
e is 65537 (0x010001)

# openssl req -new -key ca.key -out ca.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Aichi
Locality Name (eg, city) [Default City]:Toyota
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:gitlab-ci.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

# echo "subjectAltName=DNS:*.example.com,IP:192.168.11.6" > san.txt
# openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt -extfile san.txt
Signature ok
subject=C = JP, ST = Aichi, L = Toyota, O = Default Company Ltd, CN = gitlab-ci.example.com
Getting Private key

今回の場合ですが、80 ポートが apache2 に使われていて、起動に失敗するため、apache2 を削除します。

# lsof -i :80
apache2  947     root    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
apache2 1101 www-data    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
apache2 1102 www-data    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
apache2 1103 www-data    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
apache2 1105 www-data    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
apache2 1108 www-data    4u  IPv6  44939      0t0  TCP *:http (LISTEN)
# apt list --installed | grep ^apache2-
apache2-bin/now 2.4.41-4ubuntu3.1 amd64 [installed,upgradable to: 2.4.41-4ubuntu3.11]
apache2-data/now 2.4.41-4ubuntu3.1 all [installed,upgradable to: 2.4.41-4ubuntu3.11]
apache2-utils/now 2.4.41-4ubuntu3.1 amd64 [installed,upgradable to: 2.4.41-4ubuntu3.11]
# apt update
# apt -y remove apache2-*
# lsof -i :80

起動します。

# docker-compose up -d

GitLab を hosts に登録します。

# vi /etc/hosts
127.0.0.1 gitlab-ci.example.com

ログインします。(注意:ホストマシンの性能によっては、起動後、数分レベルでしばらく待つ必要があるかもしれません。)
https://gitlab-ci.example.com/
Username: root
Password: adminadmin


GitLab ログイン1


GitLab ログイン2


docker クライアントが使う証明書を配置します。
配置場所は、/etc/docker/certs.d/<ホスト名>
ディレクトリになります。
拡張子が .crt であれば、ファイル名は何でも良いようです。

# cd /home/admin/gitlab
# mkdir -p /etc/docker/certs.d/gitlab-ci.example.com:5005
# cp -p ca.crt /etc/docker/certs.d/gitlab-ci.example.com:5005/ca.crt

docker クライアントで GitLab Container Registry へのログインを試みます。

# docker login gitlab-ci.example.com:5005
Username: root
Password: adminadmin
Authenticating with existing credentials...
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

GitLab インストールOK!!


docker login 後、docker pushdocker pull を行うと、gitlab-ci.example.com:5005 に対しての操作になります。


ソースコード push

GitLab CI/CD ソースコードpush 図

IntelliJ IDEA からソースコードを push します。
git commit → GitLab へ push です。(少し説明を端折ります。)
このやり方である必要はありません。
なお、この時点では、パイプラインの設定を一切していませんので、CI/CD に関しては、何も起きません。


ソースコードは、Kotlin + SpringBoot が demo ディレクトリにあるものとして、
プロジェクト名は、demo とします。
リポジトリ URL は、https://gitlab-ci.example.com/gitlab-instance-10d4eff5/demo.git とします。


push 先の gitlab-ci.example.com が https:// かつ、自己署名証明書のため、あらかじめ、sslVerify を off にして操作しました。

$ git config --global http.sslVerify false

git commit → GitLabへpush1


git commit → GitLabへpush2


git commit → GitLabへpush3


Gitlab Runner インストール

GitLab CI/CD Gitlab Runnerインストール 図

GitLab CI/CD 実行体 Gitlab Runner をインストールします。こちらも Docker コンテナで実行します。GitLab の docker-compose.yml に一緒に書けば良いですが、あえて個別に起動しています。


docker-compose.yml を作成します。
${CI_SERVER_URL} のような変数の部分は、後で .env に値を記述します。

# mkdir /home/admin/gitlab-runner
# cd /home/admin/gitlab-runner
# vi docker-compose.yml
docker-compose.yml
version: '3'
services:
  runner:
    image: 'gitlab/gitlab-runner:latest' # gitlab/gitlab-runnerイメージ最新バージョンをDocker Hubからpull
    restart: 'always' # 自動起動on
    # 環境変数でgitlab-runner registerのオプション設定
    environment:
      - CI_SERVER_URL=${CI_SERVER_URL} # CI/CDをしたいリポジトリがあるサーバー e.g. https://gitlab-ci.example.com
      - REGISTRATION_TOKEN=${REGISTRATION_TOKEN} # GitLabが発行したトークン(後述)
      - RUNNER_EXECUTOR=docker # Gitlab Runnerの実行方式(後述)
      - RUNNER_TAG_LIST=${RUNNER_TAG_LIST} # Gitlab Runnerのタグ(パイプライン設定で紐付けに使うもの。)
      - RUNNER_NAME=${RUNNER_NAME} # Gitlab Runnerの名前(パイプライン設定では使わない。画面に表示されるもの。)
      - DOCKER_IMAGE=docker:stable # Gitlab Runnerの中で使うdocker。dockerイメージ安定版をDocker Hubからpull
      - DOCKER_VOLUMES=/var/run/docker.sock:/var/run/docker.sock # DooD(Docker outside of Docker)でホスト側dockerdを使うため、ホストのソケットと共有(後述)
      - DOCKER_EXTRA_HOSTS=${DOCKER_EXTRA_HOSTS} # GitLabのコンテナレジストリ名前解決用設定 e.g. gitlab-ci.example.com:192.168.11.6
    volumes:
      - ./etc/gitlab-runner/config:/etc/gitlab-runner # 設定が ./etc/gitlab-runner/config/config.toml に永続保存される。
      - /var/run/docker.sock:/var/run/docker.sock # ホストのソケットと共有(上記のDOCKER_VOLUMES設定に関連)
      - ./certs:/etc/gitlab-runner/certs # Gitlab Runnerが使う証明書置き場

environment: のところは、この後、GitLab に登録するときに使う、gitlab-runner register コマンドのオプションです。
通常、gitlab-runner register に対話モードで回答したり、以下のようにコマンドラインオプションにしたりすると思いますが、ここでは、docker-compose.ymlenvironment: に指定します。


gitlab-runner registerのオプション指定例:

$ sudo gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.com/" \
  --registration-token "PROJECT_REGISTRATION_TOKEN" \
・・・

docker run&gitlab-runner registerのオプション指定例:

$ docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
・・・

.env に値を記述します。

# vi .env
CI_SERVER_URL=https://gitlab-ci.example.com
REGISTRATION_TOKEN="GR1348941qvyWnPYzWbj7-2rFkdyB"
RUNNER_TAG_LIST=runner1
RUNNER_NAME="GitLab CI/CD Sample Runner"
DOCKER_EXTRA_HOSTS=gitlab-ci.example.com:192.168.11.6

REGISTRATION_TOKEN は、GUI に管理者権限でログインして、プロジェクト(リポジトリ)の画面から
Settings → CI/CD → Runners → Set up a specific runner for a project に表示されている文字列です。

REGISTRATION_TOKEN 表示


DOCKER_EXTRA_HOSTS は、docker 内から GitLab を名前解決するのに必要です。
注意点として、DOCKER_EXTRA_HOSTS を 127.0.0.1 ではなく、IP アドレスで記述する必要がありました。


RUNNER_EXECUTOR=docker
Executor とは、Runner のジョブ実行方式のことになります。


Executor=docker
Docker コンテナを使って、ジョブを実行していきます。今回、これでやっていきます。
docker コマンドを使えれば良いため、DOCKER_IMAGE=docker:stable です。


Executor=Shell
Runner が起動している環境のシェルを使ってジョブを実行します。

GitLab CI/CD Executor=Shell 図


Executor=SSH Runner が起動している環境から SSH 接続してジョブを実行します。

GitLab CI/CD Executor=SSH 図

※図は、あくまでイメージで、今回の環境に即して、ホストが Ubuntu、Runner が Docker 内になっていますが、そうとは限りません。Executor は、他にもありますが、省略します。


DOCKER_VOLUMES=/var/run/docker.sock:/var/run/docker.sock
DooD(Docker outside of Docker) でジョブを実行するため、ホスト側の UNIX ソケットを共有します。
それにより、Runner の docker クライアント(docker コマンド)を使って、ホスト側の dockerd を操作できます。
Runner の中の docker からホスト側のイメージを見たり、作ったり、削除したりできるということです。
今回、これでやっていきます。

GitLab CI/CD DooD(Docker outside of Docker) 図


DinD(Docker in Docker) というのもあります。
その場合、Runner の docker クライアント(docker コマンド)を使って、Runner の中にあるコンテナを操作します。

GitLab CI/CD DinD(Docker in Docker) 図


Runner が使う証明書を配置します。

# mkdir certs
# cp -p /etc/docker/certs.d/gitlab-ci.example.com:5005/ca.crt certs/

Runner を起動します。

# docker-compose up -d

現時点では、単に Runner が起動しただけで、GitLab に Runner として登録されていませんので、gitlab-runner register コマンドで登録します。


まず、gitlab-runner register コマンドで https://gitlab-ci.example.com/api/v4/runners にアクセスが行きますので、hosts に登録します。

# vi /etc/hosts
192.168.11.6 gitlab-ci.example.com

注意点として、127.0.0.1 ではなく、IP アドレスで記述する必要がありました。


Runner を GitLab に登録します。

GitLab CI/CD RunnerをGitLabに登録 図

# docker-compose exec runner gitlab-runner register --non-interactive

Runner のコンテナ内で gitlab-runner register コマンドを起動しています。
docker-compose exec runnerrunner は、docker-compose.yml に書いてある名前です。

runner は、docker-compose.yml に書いてある名前


docker-compose exec runner gitlab-runner register だけの場合、Executor などの設定した内容をインタラクティブモード(対話モード)で聞かれますので、--non-interactive で聞かれないようにしています。


プロジェクト → Settings → CI/CD → Runners
で確認すると、
Available specific runners

GitLab CI/CD Sample Runner
が追加されています。

GitLab CI/CD Sample Runner 追加


パイプライン設定

GitLab CI/CD パイプライン設定 図

CI/CD パイプライン設定は、
.gitlab-ci.yml
に記述します。


リポジトリに push すれば良いですが、今回は、GUI で登録します。


リポジトリ画面から
CI/CD → Editor → Configure pipeline
でとりあえず、そのまま登録してみます。(echosleepしかしていません。)


...と、その前に、Specific Runner ですので、Runner を指名しないといけません。先ほどセットアップした Runner のタグを runner1 としましたので、全てのジョブに tags で runner1 を指定します。

tags:
  - runner1

全てのジョブにtagsでrunner1を指定

このままコミットすると、.gitlab-ci.yml に反応して、パイプラインが実行されます。


View pipeline で見てみます。

View pipeline 画面


Good!!


本番用の設定に更新します。(いきなり長い設定になりますが、説明が必要な場合、コードブロックの下に説明がありますので、スクロールしてください。)

.gitlab-ci.yml
workflow:
  rules:
    - if: $CI_COMMIT_TAG
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

variables:
  IMAGE_OPENJDK_GRADLE: gradle:7.3.3-jdk17-alpine

stages:
  - clean
  - build
  - test
  - build-image
  - publish-image
  - deploy

.tags_template:
  tags:
    - runner1

clean job:
  extends: .tags_template
  image: $IMAGE_OPENJDK_GRADLE
  stage: clean
  script:
    - echo "Cleaning leftovers from previous builds"
    - sh $CI_PROJECT_DIR/gradlew clean

build job:
  extends: .tags_template
  image: $IMAGE_OPENJDK_GRADLE
  stage: build
  script:
    - echo "Compiling the code..."
    - sh $CI_PROJECT_DIR/gradlew bootJar
    - mkdir -p build/dependency
    - cd build/dependency
    - jar -xf ../libs/*.jar
  artifacts:
    paths:
      - build/dependency

test:
  extends: .tags_template
  image: $IMAGE_OPENJDK_GRADLE
  stage: test
  script:
    - echo "Running unit tests..."
    - sh $CI_PROJECT_DIR/gradlew test

build image job:
  extends: .tags_template
  stage: build-image
  script:
    - echo "Building Docker Image..."
    - docker build --build-arg DEPENDENCY=build/dependency -t $CI_REGISTRY_IMAGE:$CI_PIPELINE_IID .
    - docker build --build-arg DEPENDENCY=build/dependency -t $CI_REGISTRY_IMAGE:latest .

.docker-login: &docker-login-command
  - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin

.docker-deploy: &docker-deploy-command
  - docker rm -f spring-boot-kotlin || true
  - docker run -d --name spring-boot-kotlin -p 8080:8080 --restart always $CI_REGISTRY_IMAGE:latest

publish image job:
  extends: .tags_template
  stage: publish-image
  script:
    - echo "Publishing Docker Image..."
    - *docker-login-command
    - docker push $CI_REGISTRY_IMAGE:$CI_PIPELINE_IID
    - docker push $CI_REGISTRY_IMAGE:latest

deploy review job:
  extends: .tags_template
  stage: deploy
  script:
    - echo "Deploying Review App...."
    - *docker-deploy-command
  environment:
    name: review
    url: http://192.168.11.6:8080/api

deploy production job:
  stage: deploy
  script:
    - echo "Deploying Production App...."
    - *docker-login-command
    - *docker-deploy-command
  tags:
    - runner2
  environment:
    name: production
    url: http://192.168.11.9:8080/api
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

.gitlab-ci.ymlの説明

Commit changes でコミットしたら、また CI/CD パイプラインが動き始めます。


この時点では、タグ名= runner2 の Runner が存在しないため、deploy production job を起動すると、エラーになりますが、こうなればひとまず成功です。

runner1だけ起動した状態

次は、deploy production job も起動できるようにしていきます。


Runner 追加

GitLab CI/CD Runner追加 図

タグ名= runner2 の Runner を追加します。引き続き、同じマシンに追加しても良いですが、処理能力がパンクしますので、別の Ubuntu マシンに追加しました。runner1 と同じ手順ですので、細かい説明は省略します。
RUNNER_TAG_LIST=runner2 のところだけ重要で、IP アドレス、証明書関係で対応漏れが無ければOKです。

# apt update
# apt install -y apt-transport-https ca-certificates curl software-properties-common
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
# apt update
# apt install -y docker-ce
# curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose
# docker-compose --version
docker-compose version 1.29.2, build 5becea4c
# vi /etc/hosts
192.168.11.6 gitlab-ci.example.com
# mkdir /home/admin/gitlab-runner
# cd /home/admin/gitlab-runner
# vi .env
CI_SERVER_URL=https://gitlab-ci.example.com
REGISTRATION_TOKEN="GR1348941qvyWnPYzWbj7-2rFkdyB"
RUNNER_TAG_LIST=runner2
RUNNER_NAME="GitLab CI/CD Sample Runner2"
DOCKER_EXTRA_HOSTS=gitlab-ci.example.com:192.168.11.6
# vi docker-compose.yml
version: '3'
services:
  runner:
    image: 'gitlab/gitlab-runner:latest'
    restart: always
    environment:
      - CI_SERVER_URL=${CI_SERVER_URL}
      - REGISTRATION_TOKEN=${REGISTRATION_TOKEN}
      - RUNNER_EXECUTOR=docker
      - RUNNER_TAG_LIST=${RUNNER_TAG_LIST}
      - RUNNER_NAME=${RUNNER_NAME}
      - DOCKER_IMAGE=docker:stable
      - DOCKER_VOLUMES=/var/run/docker.sock:/var/run/docker.sock
      - DOCKER_EXTRA_HOSTS=${DOCKER_EXTRA_HOSTS}
    volumes:
      - ./etc/gitlab-runner/config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
      - ./certs:/etc/gitlab-runner/certs
# scp -rp admin@192.168.11.6:/home/admin/gitlab-runner/certs .
# mkdir -p /etc/docker/certs.d/gitlab-ci.example.com:5005
# cp -p /home/admin/gitlab-runner/certs/ca.crt /etc/docker/certs.d/gitlab-ci.example.com:5005/ca.crt
# docker-compose up -d
# docker-compose exec runner gitlab-runner register --non-interactive

パイプライン発動

GitLab CI/CD パイプライン発動 図

demo プロジェクトの Kotlin + Spring Boot についての説明は、
別記事「Kotlin + Spring Boot + Docker ビルド(Gradle, Fat JAR)まで全手順」にありますが、
GET /api   →   Hello world! と返す。
POST /api   →   POST パラメーターの value の値をそのまま返す。
という単純な実装です。


これを
GET /api   →   Hello GitLab CI/CD world! と返す。
に変更して、
develop ブランチに push してみます。

テストプログラムの方(src/test/kotlin/com/example/demo/DemoApplicationTests.kt)も変更が必要です。("Hello GitLab CI/CD world!"が返るかどうかテストしている)

develop ブランチがいきなり登場しましたが、develop ブランチに開発者が push しているところをイメージしています。ユーザー作成とか、権限調整、ブランチ作成とかの手順は省略しています。

push で発動して、master のジョブは反応しないということを言いたいから develop ブランチに push です。


develop ブランチを push した結果、deploy production job はパイプラインにありません。

developブランチ パイプライン

以下の条件があり、master ブランチへの push しか有効になっていないからです。

rules:
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

デプロイされたアプリを動作確認します。

$ curl http://localhost:8080/api
Hello GitLab CI/CD world!

ヨシ!


マージリクエストを出して、master へ push します。

masterへpushしたときのパイプライン


master のジョブも動きますが、master のジョブは、

rules:
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    when: manual

when: manual のため、手動で実行しないと動きません。


手動で起動します。

deploy production job手動起動1


deploy production job手動起動2


deploy production job手動起動3


deploy production job手動起動4


正常に終わったのを確認して、デプロイされたアプリを動作確認します。


$ curl http://192.168.11.9:8080/api
Hello GitLab CI/CD world!

ヨシ!!


loading...