カスタムDockerイメージエンハンス開発作業実施（資産更新～マージリクエスト発行～CI/CDパイプライン実行確認）

この記事は、ニフクラブログで2023-01-16に公開された記事を移転したものです。

こんにちは、CRE部技術支援チームです。

前回、前々回に引き続き「ニフクラにおけるDevOps開発作業」についての記事の最終回になります。

今回はGitLabのマージリクエスト機能(他社サイトへのリンクです)を使って、実際の開発現場を想定したエンハンス開発作業を実施して、実践的なDevOps開発を紹介します。

はじめに
前提条件
検証概要
- 検証1
- 検証2
作成するニフクラリソース
環境設定
検証実施
- 検証1実施
- 検証2実施
まとめ
- 補足情報
  - gitコマンド以外での開発環境の紹介
  - 承認ルールなしでマージ実行ボタンを制御する方法の紹介
注意事項

はじめに

検証は前回までに作成した環境に開発担当者と運用管理者の役割を設定して以下の工程でエンハンス開発作業を実施します。

※開発担当者からリポジトリブランチへのアクセスについては、git(他社サイトへのリンクです)コマンドを使用するのが一般的な方法です。開発担当者の操作はマージリクエスト発行以外はgitコマンドで実施します。

開発資産作成
featureブランチからdevelopブランチへのマージリクエスト発行
マージリクエスト承認
featureブランチからdevelopブランチへのマージ実行
developブランチへのマージ実行で発生した資産更新をトリガーにWEBアプリ検証サーバーに自動デプロイ

GitLabのマージリクエスト機能は上記2～5の工程を簡易な操作と視覚的に管理ができる有用な機能です。また前回作成したCI/CDの設定と連携させることができるので、スピーディに自動デプロイが実施できます。

以上のエンハンス開発作業の検証をとおしてニフクラDevOps with GitLabにおけるDevOps開発を紹介します。

前提条件

本ブログ記事は、以下の知識がある方を想定しています。

ニフクラの基本的な操作ができる(サーバー作成、ネットワーク構築)
Dockerについての基本的な設定や操作ができる
WEBアプリ開発の経験がある
Gitコマンドで基本的な操作ができる

検証概要

検証1

以下①～➂にて、開発担当者の開発～マージリクエスト発行までの作業工程を検証＆解説します。

①. 開発担当者が開発資産を作成します。

②. 開発資産をgit pushコマンドでfeatureブランチにアップロードします。

➂. 開発担当者がGitLabサーバーでfeatureブランチをdevelopブランチにマージするためのマージリクエストを発行します。

検証2

以下④～⑦にて、運用管理者のマージリクエスト承認～承認後の自動化されたCI/CDパイプライン実行からWEBアプリ検証サーバーへのデプロイ工程を検証＆解説します。

④. 管理者がマージリクエストを承認します。featureブランチに追加された資産がdevelopブランチにマージされます。

➄. developブランチのマージで資産更新が発生したのでCI/CDパイプラインが実行されます。developブランチ内の資産でDockerイメージをビルドします。

⑥～➆. WEBアプリ検証サーバーに自動デプロイされたWEBアプリがインターネットに公開されます。

作成するニフクラリソース

検証に利用したリソースは以下の通りです。

リソース	数量
DevOps with GitLabサーバー	1
DevOpsファイアウォール	1
検証サーバー	2
ファイアウォール	1

DevOps with GitLabサーバー作成

DevOps with GitLabサーバーを作成します。
前回作成済みのDevOps with GitLabサーバーを利用します。

DevOpsファイアウォールを作成します。
作成方法は以下ヘルプサイトを参照ください。
クラウドヘルプ（ファイアウォールグループの新規作成）

DevOpsファイアウォールグループ名	INルール
dockertest-fw	TCP443：ブラウザアクセスで使用しているIPアドレス TCP443：WEBアプリ検証サーバーのグローバルIPアドレス TCP443：開発検証サーバーのグローバルIPアドレス

検証サーバー作成

WEBアプリ検証サーバーを作成します。
前回作成済みのWEBアプリ検証サーバーを利用します。

開発検証サーバーを作成します。
作成方法は以下ヘルプサイトを参照ください。
クラウドヘルプ（サーバーの作成）

開発検証サーバー

項目名	値
OS	Rocky Linux 8.5
サーバー名	DevSrv
ファイアウォール	WebAppSrvFW

検証サーバーファイアウォール作成

WEBアプリ検証サーバーと開発検証サーバーで使用するファイアウォールを作成します。前回の検証同様WEBアプリ用に8085のポートを追加します。
INルール（既存に追加）

ファイアウォール名	INルール
WebAppSrvFW（WEBアプリ検証サーバー用＆開発検証サーバー用）	TCP22：作業端末のグローバルIPアドレス TCP8080：作業端末のグローバルIPアドレス TCP8085：作業端末のグローバルIPアドレス

環境設定

.gitlab-ci.ymlを編集してCI/CDパイプライン制御を追加

更新対象のブランチがdevelopである場合のみ、GitLabRunnerジョブが起動してCI/CDパイプラインが実行されるように制御するため.gitlab-ci.ymlの内容を編集します。
下記のrulesタグを追加してCI/CDパイプラインの実行を制御をします。詳細はリファレンスを参照してください。(他社サイトへのリンクです)

  rules:
   - if: '$CI_COMMIT_BRANCH == "develop"'

作成したdevelopリポジトリに移動し.gitlab-ci.ymlをクリックして内容を編集します。

ファイルに上記rulesタグを追記します。修正後のファイルは下記となります。

deploy_job:
  stage: deploy
  rules:
   - if: '$CI_COMMIT_BRANCH == "develop"'
  script:
#起動中のDockerコンテナ(nifc-nginx)を停止する。
    - echo `docker stop nifc-nginx`
#起動中のDockerコンテナ(nifc-nginx)を削除する。
    - echo `docker rm nifc-nginx`
# コンテナーレジストリのURLにログインする。
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
#.gitlab-ci.ymlファイルと同一階層(./)に格納されているDockerfileの内容でDockerイメージ(タグ名：$CI_REGISTRY/xxxxxxx/devops_docker)をビルドする。
    - docker build -t $CI_REGISTRY/xxxxxxx/devops_docker:latest .
#docker pushしてコンテナレジストリのDockerイメージ(タグ名：$CI_REGISTRY/xxxxxxx/devops_docker)を更新する。
    - docker push $CI_REGISTRY/xxxxxxx/devops_docker:latest
#docker pullして最新をダウンロードする。
    - docker pull $CI_REGISTRY/xxxxxxx/devops_docker:latest
#最新Dockerイメージ(タグ名：x$CI_REGISTRY/xxxxxxx/devops_docker)からDockerコンテナ(nifc-nginx)を作成して起動する。8085ポートからのアクセスを許可する。
    - docker run -d -p 8085:80 --name nifc-nginx -it $CI_REGISTRY/xxxxxxx/devops_docker:latest

.gitlab-ci.ymlの編集は完了です。

gitリポジトリアクセストークン発行

開発検証サーバーからDevOps with GitLabサーバー上のリポジトリにアクセスするために gitリポジトリアクセストークンを発行します。作成したプロジェクトに移動して「Settings」→「Access Tokens」を選択します。
「Token name」にトークン名を設定して、「read_repository」、「write_repository」を選択して「Create project Access token」ボタンをクリックします。
「Your new project access token」欄にトークンが発行されます。以降はトークンは表示できなくなるので、コピーして別途メモ等に保存しておきます。
gitリポジトリアクセストークン発行は完了です。

gitインストール

開発検証サーバーにDevOps with GitLabサーバーの資産管理用リポジトリをコミット＆プッシュ操作するためにgitツールをインストールします。

$dnf install git -y
-----------省略-----------
Complete!

インストール完了です。バージョンを確認します。

$git version
git version 2.31.1

gitユーザ設定、メールアドレス設定

コミット＆プッシュ時の添付情報として使用されるユーザ名とメールアドレスを設定します。以下のコマンドで任意のユーザ名設定します。

$git config --global user.name "xxxxx"

以下のコマンドで任意のメールアドレスを設定します。

$git config --global user.email "xxxxx@xxxxx"

gitユーザ設定、メールアドレス設定は完了です。

featureブランチ作成

開発検証サーバーから開発資産をアップロードするfeatureブランチ作成します。
developブランチから派生分岐する形で作成します。

開発検証サーバーへsshでログインし、作業用の「dev_work」ディレクトリを作成し移動します。

$mkdir dev_work
$cd  dev_work

dev_workディレクトリに移動してgit cloneコマンドでgitリポジトリの接続URLを設定してcloneします。
接続先のURLは作成したdevelopリポジトリの「Clone」→「Clone with HTTPS」のURLをコピーします。

$git clone コピーしたURL

ユーザ名とパスワードの入力を求められるのでリポジトリアクセストークン発行で設定した「トークン名」と「発行トークン」を設定します。

Username for 'https://xxxxxxx.jp-east-1.gitlab.devops.nifcloud.com': リポジトリアクセストークン発行で設定した「トークン名」
Password for 'https://git@xxxxxx.jp-east-1.gitlab.devops.nifcloud.com': リポジトリアクセストークン発行で発行された「トークン」
remote: Enumerating objects: 36, done.
remote: Total 36 (delta 0), reused 0 (delta 0), pack-reused 36
Receiving objects: 100% (36/36), 6.12 KiB | 6.12 MiB/s, done.
Resolving deltas: 100% (12/12), done.

lsコマンドで確認するとリポジトリ名のディレクトリがダウンロードされていることが確認できます。

$ls -l
total 0
drwxr-xr-x. 4 root root 91 Aug 24 13:48 リポジトリ名

リポジトリのディレクトリに移動してgit fetchコマンドとgit checkoutコマンドでgitリポジトリdevelopブランチをチェックアウトします。

$cd リポジトリ名
$git fetch origin develop
$git checkout develop

git branch コマンドで確認するとdevelopに「＊」がマークされており、チェックアウトされていることが確認できます。

$git branch 
* develop
  main

ディレクトリを確認すると、DevOps with GitLabサーバー上のdevelopブランチの内容がダウンロードされていることが確認できます。

$ls ./リポジトリ名/  -l
total 12
drwxr-xr-x. 2 root root   59 Dec 20 10:15 dev_html
-rw-r--r--. 1 root root  172 Dec 20 13:48 Dockerfile
-rw-r--r--. 1 root root 6317 Dec 20 13:42 README.md

git checkout コマンドにて、開発検証サーバー上でdevelopブランチからfeatureブランチを派生分岐します。
featureブランチ名は"feature/#test"で作成します。

$git checkout -b feature/#test
Switched to a new branch 'feature/#test'

git branch コマンドでfeature/#testに「＊」がマークされてチェックアウトされていることを確認します。

$git branch 
 develop
* feature/#test
 main

この状態では開発検証サーバーでのみfeatureブランチが作成されている状況のため、DevOps with GitLabサーバー上のgitリポジトリへgit pushコマンドブランチを登録します。

$git push -u origin feature/#test
Username for 'https://xxxxxxx.jp-east-1.gitlab.devops.nifcloud.com': リポジトリアクセストークン発行で設定した「トークン名」
Password for 'https://git@xxxxxx.jp-east-1.gitlab.devops.nifcloud.com': リポジトリアクセストークン発行で発行された「トークン」
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
-----------省略-----------
 * [new branch]      feature/#test -> feature/#test
Branch 'feature/#test' set up to track remote branch 'feature/#test' from 'origin'.

DevOps with GitLabサーバーにfeatureブランチが登録されます。

featureブランチの作成は完了です。

マージ承認ルール設定

マージリクエストを発行するとマージリクエスト画面に「Approve(承認)」、「Merge(マージ実行)」ボタンが表示されます。「Merge(マージ実行)」ボタンをクリックするとマージが実行されます。

GitLabでは発行するマージリクエストに承認ルール(他社サイトへのリンクです)を設けていないと誰でも「Merge(マージ実行)」ボタンをクリックできる状態になっています。
検証では承認ルールを満たしていない場合はマージ実行できないように「Merge(マージ実行)」ボタンに制限をかける承認ルールを設定します。

※承認ルールはPremium、もしくはUltimateライセンスで設定可能になります。サブスクリプションの利用申請をお願いいたします。

「Settings」→「General」→「Merge request approvals」を選択します。「Merge request approvals」項目の「Expand」ボタンをクリックして「Merge request approvals」項目を展開します。

「Add approval rule」ボタンをクックします。

設定ダイアログ画面が表示されるので内容を入力して「Add approval rule」ボタンをクックします。

項目名	値	説明
Rule name	マージ承認
Target branch	All Branches	本検証では全ブランチ適用にします。
Approvals required	1	承認に必要な数。主にレビュー担当者、管理者の数。今回は運用管理者1人になります。
Add approvers	admin	承認するレビュー担当者、管理者を選択します。今回は運用管理者adminというユーザを設定します。

マージ承認ルールが作成されます。

マージ承認ルールが作成されることで、承認ルールが決めた承認数を満たしていない場合はマージできないように制限されます。

マージ承認ルール設定前
承認されていなくてもマージ実行が可能です。
マージ承認ルール設定後
承認ルールが決めた承認数を満たすまでマージ実行が不可能です。

マージ承認ルールが作成は完了です。

検証実施

検証1実施

開発検証サーバーでエンハンス開発作業を実施して、gitコマンドでfeatureブランチに資産（htmlファイル）をアップロードします。
その後、GitLabサーバーにログインしてマージリクエストを発行します。

ページhtml(page1.html)を作成して追加

開発検証サーバーの作成したfeatureブランチ環境でdev_htmlディレクトリが存在することを確認します。

$ls -l
total 12
drwxr-xr-x. 2 root root   59 Dec 23 10:15 dev_html
-rw-r--r--. 1 root root   58 Dec 23 10:15 Dockerfile
-rw-r--r--. 1 root root 6317 Dec  6 13:23 README.md

dev_htmlディレクトリに新規ファイルとして「page1.html」を作成します。

$vi dev_html/page1.html

設定内容は以下です。

page1.html

<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8">
    <link rel="stylesheet" type="text/css" href="default.css">
    <title>PAGE</title>
</head>

<body>
    <h1>ニフクラDevOps</h1>
    開発エンハンス作業で追加したpage1.htmlです。
</body>

</html>

dev_htmlディレクトリ内にpage1.htmlが作成されていることを確認します。

$ls -l dev_html/
total 12
-rw-r--r--. 1 root root 358 Dec 23 10:15 default.css
-rw-r--r--. 1 root root 372 Dec 23 10:15 index.html
-rw-r--r--. 1 root root 251 Dec 23 10:59 page1.html

ページhtmlの作成は完了です。

開発資産アップロード

作成したpage1.htmlファイルをgit addコマンドでコミットの対象に追加します。

$git add dev_html/page1.html

作成したpage1.htmlファイルをgit commitコマンドでコミットします。

$git commit -m "add page1.html"
[detached HEAD 681a860] add page1.html
 1 file changed, 16 insertions(+)
 create mode 100644 dev_html/page1.html

作成したpage1.htmlファイルをgit pushコマンドでリポジトリにアップロードします。
ユーザ名とパスワードの入力を求められるのでリポジトリアクセストークン発行で設定した「トークン名」と「発行トークン」を設定します。

$git push origin feature/#test
Username for 'https://xxxxxxxx.jp-east-1.gitlab.devops.nifcloud.com':  リポジトリアクセストークン発行で設定した「トークン名」
Password for 'https://git@xxxxxxx.jp-east-1.gitlab.devops.nifcloud.com': リポジトリアクセストークン発行で発行された「トークン」
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 385 bytes | 385.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for develop, visit:
remote:   https://xxxxxxx.jp-east-1.gitlab.devops.nifcloud.com/xxxxxxxxx/xxxxxxxx/-/merge_requests/new?merge_request%5Bsource_branch%5D=feature%2F%23test
remote:
To https://xxxxxxxxxxxx.jp-east-1.gitlab.devops.nifcloud.com/xxxxxxx/xxxxxxxxxx.git
   520a6da..c71737e  feature/#test -> feature/#test

リポジトリのfeatureブランチを確認すると「page1.html」が作成されています。 CI/CDパイプライン実行制御しているので「CI/CD」→「Jobs」を確認しても featureブランチの資産更新ではCI/CDパイプラインは実行されていません。

マージリクエスト発行

開発担当者から運用管理者に向けて資産更新のレビュー依頼と更新内容のdevelopブランチへのマージ実行を依頼するためにマージリクエストを発行します。

「Merge requests」を選択します。

「New merge request」をクリックします。

「Source branch」にfeatureブランチ、「Target branch」にdevelopブランチを選択します。

「Compare branches and continue」ボタンをクリックします。

マージリクエストのタイトル、マージリクエスト説明文等の内容を入力します。
詳細はGitLabマージリクエスト(他社サイトへのリンクです)を参照してください。
参考としてCRE部技術支援チームでは以下の内容をマージリクエストの説明に入力しています。

関連するissue(他社サイトへのリンクです)
担当者、レビュアー、管理者
編集内容、対応内容

「Create merge request」ボタンをクリックしてマージリクエストを作成します。

マージリクエストが発行されます。

発行されたマージリクエストは一覧に作成したマージリクエストに表示されます。

マージリクエストの発行は完了です。

検証2実施

運用管理者がレビューを実施して問題がなければマージリクエストを承認してマージを実行します。

マージ後、CI/CDパイプラインが実行されてWEBアプリ検証サーバーに自動デプロイされます。

承認前の更新内容レビュー

マージリクエストの承認前に更新資産をレビューするために発行したマージリクエストの「Changes」タグをクリックします。

featureブランチとdevelopブランチの差分内容が表示されます。

運用管理者がレビューを実施します。指摘事項があれば、該当箇所にカーソルを合わせるとコメントを付与できます。

「Start a review」、もしくは「Add comment now」でコメントを付与します。ここでは「Add comment now」で付与します。「Start a review」の詳細についてはリファレンスを参照してください(他社サイトへのリンクです)

発行したマージリクエストにコメントが追加されます。開発担当者はコメント内容を参照して修正作業等を実施します。
レビュー→コメント→修正を開発担当者と運用管理者の間で指摘事項が無くなるまで繰り返します。

指摘する内容が無くなれば更新内容のレビューは完了です。

マージリクエスト承認＆マージ実行

更新内容のレビューが完了したらマージリクエストの「Approve」ボタンをクリックしてマージを承認します。

マージ承認数が制限解除の数になると「Merge」ボタンが押下可能な状態になるので「Merge」ボタンをクリックします。

featureブランチのdevelopブランチへのマージが実行されて、マージ後にCI/CDパイプラインが実行されます。

「CI/CD」→「Jobs」を確認するとCI/CDパイプラインが実行されていることが確認できます。

DevOps with GitLabサーバーのdevelopブランチの内容がマージされて更新されていることが確認できます。

マージリクエスト承認＆マージ実行は完了です。

WEB画面表示

ブラウザでWEBアプリ検証サーバーのエンハンス作業で追加したpage1.htmlのURLにアクセスします。

http ://WEBアプリ検証サーバーのグローバルIP:8085/page1.html

追加した「page1.html」が表示されます。

以上で検証は完了です。

まとめ

３回の記事に分けてニフクラDevOps with GitLabを使ったDevOps開発について紹介しました。

いざ、自社のシステムにDevOps開発の環境を構築しようとすると構築手順の調査等の煩雑な作業が発生してしまいます。構築までの時間が週単位でかかってしまいます。

ニフクラDevOps with GitLabを導入して本ブログの手順を参考にすれば1～3日でDevOps開発の環境構築～基本的な作業の流れが把握できます。

以上のことからニフクラDevOps with GitLab利用のメリットがご理解いただけたかと思います。ぜひ、ニフクラDevOps with GitLabの導入をご検討ください。

最後までお読みくださいましてありがとうございました。

補足情報

gitコマンド以外での開発環境の紹介

検証では開発検証サーバーでgitコマンドをインストールして開発作業を実施しましたが、その他にVisual Studio Code(他社サイトへのリンクです)、GitLabのWEB IDEでGitLabサーバーと連携して開発作業ができます。
詳細については別の機会で紹介したいと思います。

Visual Studio Codeでの編集
GitLab WEB IDEでの編集

承認ルールなしでマージ実行ボタンを制御する方法の紹介

検証ではマージ承認ルールを設定してマージ実行を制御しました。
マージ承認ルールを利用する場合にはPremium、もしくはUltimateライセンスが必要ですが Premium、Ultimateライセンスを利用しない場合でもDraftフラグ(他社サイトへのリンクです)を用いればマージ実行を制御できます。

下記のようにマージリクエストのタイトルにDraftフラグ付与すれば承認ルールに関係なくマージできないように制限されます。「Mark as ready」ボタンをクリックすると解除されます。

注意事項

本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
本記事の他社サイトへのリンクにつきまして、リンク切れの際はご容赦ください。
本記事は、2022年12月時点の情報です。

Fujitsu Cloud Direct ブログ

初心者エンジニア向け技術ブログ