見出し画像
Photo by yakitorigacha

GitLabでレガシー環境でのGitOps事始め 《第3回》CI/CDの実行

SHIFT Group 技術ブログ


こんにちは。CAT推進グループ 小田柿 です。

またまただいぶ間が空いてしまいましたが、GitLabでレガシー環境でのGitOps事始め 第3回 です。今回は作成したCI/CDコードを使って開発環境と本番環境にデモアプリをデプロイする手順を紹介します。



1. 各サーバーの準備

今回のCI/CDのデモ実行では簡略化のため第1回に記載した構成図の通りにはせずデモアプリサーバーを開発・本番で共有する形で実施します。

画像1


1.1. GitLabサーバー

GitLabと開発CI/CD実行用GitLab-RunnerのインストールとRunner登録については第1回を参照ください。ここではサーバーそのものの設定を記載します。

1.1.1. ビルドアーカイブ出力先ディレクトリ

デモアプリのビルド用Runnerのビルドアーカイブの出力先ディレクトリを用意します。所有者はGitLab-CI/CD の実行者＝gitlab-runnerとなります。またデプロイ時のアーカイブ取得用SSH接続ユーザーが読み取り可能になるようにパーミッションを設定します。

画像2


1.1.2. Hosts設定

GitLabのドメインがDNS登録されていない場合は、Runnerが対象のGitLabにHTTPアクセスするために以下のようにhostsを定義します。

/etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.10.11  gitlab.example.com


1.1.3. SSH設定

デプロイ用Runnerがビルドアーカイブ取得（GitLabサーバーへの接続）とデプロイ（デモアプリサーバーへの接続）に使用するSSH設定を定義します。

/home/gitlab-runner/.ssh/config

Host gitlab                         # GitLabサーバー(gitlab)へのSSH接続設定
 HostName 192.168.10.11
 User gitlab                       # 接続用ユーザー
 IdentityFile ~/.ssh/gitlab.rsa    # SSH秘密鍵
 Port 22
Host dev-server                     # 開発用サーバー(dev-server)へのSSH接続設定
 HostName 192.168.10.12
 User demo                         # 接続用ユーザー（sudoer）
 IdentityFile ~/.ssh/demo.rsa      # SSH秘密鍵
 Port 22


1.2. 本番踏み台サーバー

GitLabサーバーと同様に、本番CI/CD実行用のGitLab-RunnerのインストールとRunner登録が必要です。こちらも詳細は第1回を参照ください。必要な設定もほぼ同様で、以下のようにhostsファイルとgitlab-runnerユーザーのSSHコンフィグを用意すればOKです。

/etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.10.11  gitlab.example.com

/home/gitlab-runner/.ssh/config

/home/gitlab-runner/.ssh/config
Host gitlab                         # GitLabサーバー(gitlab)へのSSH接続設定
 HostName 192.168.10.11
 User gitlab                       # 接続用ユーザー
 IdentityFile ~/.ssh/gitlab.rsa    # SSH秘密鍵
 Port 22

Host prod-server                    # 本番用サーバー(prod-server)へのSSH接続設定
 HostName 192.168.10.12            # 今回はデモアプリサーバーを開発環境と共有する
 User demo                         # 接続用ユーザー（sudoer）
 IdentityFile ~/.ssh/demo.rsa      # SSH秘密鍵
 Port 22


1.3. デモアプリサーバー（開発・本番兼用）

Tomcatをインストールします。インストールおよび設定の詳細については割愛しますが、設定は以下のようにします。（※CentOS 7での設定です）

<Tomcat設定>

画像3

これでCI/CD実行のための事前準備は完了です。


2. CI/CDパイプラインの起動

では実際にCI/CDがどのように実行されるか見ていきましょう。今回作成したCI/CDパイプラインには以下の4パターンの起動方法がコードとして定義されています。これらを一つずつ試してみます。

画像4


2.1. demoプロジェクトのプロテクトしたブランチを更新またはマージ（自動起動）

まずはパターン1です。demoプロジェクトのdevelopブランチ（プロテクトブランチ）に変更をマージしてみます。

画像5

マージをトリガーにdemoプロジェクトのCI/CDパイプラインが起動されたのが確認できました。

画像6

ではこのパイプラインの中身を確認してみましょう。Test → Build → Trigger (Dev-Deploy-Trigger) の3ジョブが順番に実行されていく様子が可視化されています。

画像7

最後のDev-Deploy-Triggerジョブでは、後続のdeployプロジェクトのCI/CDパイプライン（masterブランチ）を起動しています。

画像8

後続プロジェクトのパイプラインが起動されると、一覧にDownstreamパイプラインが追加表示されます。

画像9

このときdeployプロジェクト側を見ると、新規のCI/CDパイプラインが生成されているのが確認できます。

画像10

開発デプロイジョブが完了するまで待って結果を確認していきます。
まずはGitLabの画面でデプロイパイプラインのステータスを確認します。

画像11

次に指定したブランチ・タグ名を含んだデモアプリのビルドアーカイブ（demo-<branch/tag>.war）がGitLabサーバーの出力先ディレクトリ (/mnt/archives/) に（上書き）保存されていることを確認します。

GitLabサーバー

[root@gitlab ~]# ls -l /mnt/archives
total 90928
-rw-rw-r-- 1 gitlab-runner gitlab-runner 23274582 Aug 20 11:03 demo-develop.war
-rw-r--r-- 1 gitlab-runner gitlab-runner 23274581 Aug 19 09:06 demo-master.war
-rw-r--r-- 1 gitlab-runner gitlab-runner 23274582 Apr 24 01:16 demo-v1.0.1.war
-rw-rw-r-- 1 gitlab-runner gitlab-runner 23274582 Aug 20 11:39 demo-v1.0.2.war

さらにデモアプリサーバーにデプロイされたビルドアーカイブ（/opt/tomcat/webapps/ROOT.war）の更新時刻とtomcatデーモンの再起動時刻（systemctlステータスの「Active: active (running) since …」）を確認します。

デモアプリサーバー

$ ls -l /opt/tomcat/webapps/
total 22736
drwxr-xr-x  5 tomcat tomcat       48 Aug 20 11:56 ROOT
-rw-rw-r--  1 demo   demo   23274582 Aug 20 11:56 ROOT.war
drwxrwxrwx 15 tomcat tomcat     4096 Apr  1 14:10 docs
drwxrwxrwx  7 tomcat tomcat       99 Apr  1 14:10 examples
drwxrwxrwx  6 tomcat tomcat       79 Apr  1 14:10 host-manager
drwxrwxrwx  6 tomcat tomcat      114 Apr  1 14:10 manager

$ sudo systemctl status tomcat
● tomcat.service - Apache Tomcat 9
  Loaded: loaded (/etc/systemd/system/tomcat.service; enabled; vendor preset: disabled)
  Active: active (running) since Fri 2021-08-20 11:56:36 JST; 5h 30min ago
 Process: 1556 ExecStop=/opt/tomcat/bin/shutdown.sh (code=exited, status=0/SUCCESS)
 Process: 1656 ExecStart=/opt/tomcat/bin/startup.sh (code=exited, status=0/SUCCESS)
Main PID: 1670 (java)
  CGroup: /system.slice/tomcat.service
          └─1670 /usr/bin/java -Djava.util.logging.config.file=/opt/tomcat/conf/...

Aug 20 11:56:36 demo systemd[1]: Starting Apache Tomcat 9...
Aug 20 11:56:36 demo systemd[1]: Started Apache Tomcat 9.

最後にブラウザで開けること（HTTPポート：8080）が確認できればOKです


2.2. demoプロジェクトのCI/CD画面からビルドパイプラインを実行

demo > CI/CD > Pipelines画面右上の「Run Pipeline」ボタンを押してパイプライン実行画面を開きます。

画像12

「Run for branch name or tag」でビルド対象のブランチまたはタグを指定し、「Run Pipeline」ボタンを押してパイプラインを起動します。（demoパイプラインでは実行時に設定する変数を用意していないので「Variables」は指定不要です）

画像13

ビルドパイプラインが生成されます。

画像14

この後はパターン1と同様にビルド後に開発デプロイパイプラインがトリガーされます。


2.3. deployプロジェクトのCI/CD画面から開発デプロイパイプラインを実行

deployプロジェクトのパイプライン実行画面を開き、以下の項目を指定してパイプラインを実行します。

画像15
画像16

↓

画像17

指定したアプリ・バージョンのビルドアーカイブがGitLabサーバーの /mnt/archives/ に存在しないとエラーになります。基本的には過去のバージョンに戻すときにこの起動パターンを実行するイメージです。


2.4. deployプロジェクトのCI/CD画面から本番デプロイパイプラインを実行

本番環境へのデプロイが実行できるのはこのパターンだけです。

deployプロジェクトのパイプライン実行画面で Variables > ENVIRONMENT に dev の代わりに prod を指定します。他の設定は開発デプロイパイプラインと同じです。

画像18

実行したらProd-Deploy-Demoジョブ画面を開き、開発パイプラインでなく本番パイプラインが起動したこと（本番踏み台サーバー上の本番用Runnerがジョブを実行していること）を確認します。

画像19

あとはこれまでと同様にデプロイジョブの完了と本番デモアプリサーバー（今回は開発と同じ）のTomcatの更新・起動状態、本番ブラウザアクセスを確認すればOKです。


3. 終わりに

GitLabでレガシー環境でのGitOps事始め、いかがでしたでしょうか。アプリのソースコードと一緒にCI/CDコードを同じGitリポジトリ上で管理できるため構成管理が非常にラクになる点も非常に良いのですが、何より、特別なCIツールを導入しなくてもいいのですぐにトライアルできたのが良かったです。皆さんもぜひお試しを。

最後に自社サービスの宣伝です。株式会社SHIFTでは当社が受注したテスト案件を管理するのに使用している統合型ソフトウェアテスト管理ツール「CAT」を、一般の開発チーム向けにSaaSとしても提供しています。加えて、テスト設計支援ツール「TD」を近日ローンチ予定です。無料トライアルも可能なのでぜひお試しください。

■統合型ソフトウェアテスト管理ツール「CAT」： https://www.catcloud.net/

■テスト設計支援ツール「TD」： https://www.testdesigner.io/


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

執筆者プロフィール：小田柿 敦士
株式会社SHIFT で統合型ソフトウェアテスト管理ツール「CAT」の製品開発およびインフラ管理に携わっています。

《このライターの他の記事を読む》

《第1回》 GitLab CI/CD環境構築｜GitLab-CI/CDでレガシー環境でのGitOps事始め
《第2回》CI/CDコードの作成・登録｜GitLab-CI/CDでレガシー環境でのGitOps事始め

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

最後まで読んでくださり、ありがとうございます！

御社サービスのご相談はお気軽に。
ソフトウェア品質のプロがお伺いします。