《第1回》 GitLab CI/CD環境構築｜GitLab-CI/CDでレガシー環境でのGitOps事始め

SHIFT Group 技術ブログ

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

最近はKubernetesでのGitOpsが流行っていますよね。でもうちはKubernetesなんて使ってないレガシー環境だし、そんな意識の高い概念は無関係だと思っている方も多いかと思います。

でもGitLabの定義によればGitOpsとは、

（引用）
GitOpsを実践しているインフラチームは、コードとして保存された設定ファイル（Infrastructure as Code）を使用します。
インフラチームはIaCを使用して、マージリクエストで変更を実施するようになります。インフラの変更がコード化され、再現性があり、追跡可能になります。ヒューマンエラーが発生する余地が少なくなり、全員で同じ情報を共有できるようになります。

（参考）GitOpsとは

とのことなので、コンテナもKubernetesも関係なく、バージョン管理システム上にCI/CD用コードを一緒に登録して管理・実行しましょう、という解釈でいいようです。

ただ、CI/CDコードを管理するだけならどんなバージョン管理システムでもできますが、実行まで考えるとどんなツールを使ってどんな構成にすればよいのかなど、考えることはたくさん出てきます。

今回は、そんな意識低い系のチームのために、GitLabによるGitOps環境構築ガイドをご紹介します。

※もしタイトルからKubernetesでのGitOpsの記事を期待された方はごめんなさい、GitLab-CI/CDの紹介記事です

1. 今回紹介する構成と目標

画像1

この構成で、

- 開発者がソースコードをマージすると自動的にビルドされる
- さらにそのまま開発環境にビルド成果物が自動的にデプロイされる
- マニュアルで開発環境に再デプロイすることもできる
- インフラエンジニアがGitLab画面越しに本番デプロイを実行できる

の４つが可能になった状態を目指します。

補足ですが、図中でGitLabアイコンにRUNNERと記載されているアイコンは、Gitリポジトリに登録したCI/CDスクリプトを実行するためのツールであるGitLab-Runnerを表しています。GitLabサーバー上に2つのRunnerがいるのは、1つのGitLab-Runnerに複数のCI/CDスクリプト実行用プロセス（＝Runner）を登録できるからです。

今回はGitLabサーバー上にビルド用Runnerと開発デプロイ用Runner、本番踏み台サーバー上に本番デプロイ用Runnerをそれぞれ登録します。

また今回紹介するサンプルでは、簡略化のため管理対象のアプリは1つで開発／本番サーバー群はそれぞれ1台ずつという前提になっています。複数台に別々のアプリをデプロイする場合は紹介したサンプルコードを適宜拡張してください。

2. GitLabサーバーの準備

2.1. GitLabインストール
GitLabを利用していない場合は、公式ドキュメント（https://www.gitlab.jp/install/）に従って開発環境内にGitLabサーバーを立てましょう。インストール方法については本記事では詳細は省略しますが、「オールインワンパッケージ (推奨のインストール方法)」かつ「Community Edition」（無償版）で十分です。本サンプルでは執筆時の最新版（GitLab Community Edition 13.8.0）をインストールしています。

2.2. リポジトリ作成
GitLabサーバーが稼働したら、ログインしてアプリのソースコードを移行しましょう。トップページ右上のNew projectボタンを押すとリポジトリ(Project)が作成されます。空のリポジトリページのトップには、新規コードの詳細な登録方法がパターン別に表示されているので、それに従えば問題なく登録できるはずです。

また、アプリのソースコード以外に必要なリポジトリとして、デプロイスクリプト用のリポジトリがあります。本記事のサンプルでは、Spring Bootデモアプリの”demo”リポジトリとデプロイスクリプト用の”deploy”リポジトリを用意しています。”deploy”リポジトリは後述するデプロイ用Runnerの登録で必要となるため、空のリポジトリでよいのであらかじめ作成しておいてください。

画像2


2.3. GitLabサーバーのネットワーク設定
またファイアウォール設定で本番踏み台サーバーからのHTTP(S)とSSHアクセスを許可してください。概要図では模式的にGitLabからGitLab-Runnerを起動する向きの矢印が描かれていますが、実際にはGitLab-Runnerの方がGitLabをポーリングしてCI/CDパイプラインが実行されたかをチェックしています。

そのためにGitLabのHTTPポート（デフォルトでは80/tcp）をGitLab-Runnerがインストールされているサーバーに開放してやる必要があります。さらに今回の構成ではGitLabサーバーをビルド成果物のアーカイブ先としても使用しており、本番踏み台サーバー上にビルド成果物をコピーするためにSSHポートも開放する必要があります。


3. GitLab-Runnerの準備

3.1. GitLab-Runnerインストール
GitLabサーバーの準備ができたら、今度はGitLab-Runnerです。こちらも詳細はここでは触れませんが、公式ドキュメント（https://docs.gitlab.com/runner/install/）に従ってGitLabサーバーと本番踏み台サーバーにGitLab-Runnerをインストールしてください。本サンプルでは執筆時の最新版 （Version:13.8.0）をインストールしました。

3.2. Runnerの登録
構成図に従ってRunnerを登録します。登録するRunnerは次の表のように、GitLabサーバーはビルド用と開発デプロイ用の2つ、本番踏み台サーバーは本番デプロイ用のRunnerが1つ必要になります。

画像3

以降、上の表の設定値の詳細とRunner登録方法について説明します。

3.2.1. Shared runnerとSpecific runner
登録するRunnerの種類にShared runnerとSpecific runnerを記載していますが、違いはRunnerの紐付け先の違いです。GitLab全体を表すトークンと紐付けたものがShared runner、特定のリポジトリを表すトークンと紐付けたものがSpecific runnerです。Shared runnerはどのリポジトリにも適用できる一方、Specific runnerは対象のリポジトリのCI/CDジョブしか実行できません。使い分けとしては、厳密な実行制御を必要とするジョブはSpecific runnerを個別に登録して実行させ、それ以外はShared runnerで実行する形にするのがよいです。

今回紹介する構成では、本番デプロイは不用意に実行されるのを避けるためSpecific runnerとし、ビルドはShared runnerにしています。開発デプロイは本番と構成を合わせるためSpecific runnerを適用しています。各RunnerはPause（停止）しておけるので、本番デプロイ用Runnerは普段はPauseしておき、デプロイ作業時だけ有効化する、という運用が可能になります。

Runner登録例：Admin Area > Overview > Runners

画像4


Shared runner/Specific runnerの紐付け先トークンですが、それぞれGitLab画面上の以下のページで確認できます。

- Shared runner用トークン：Admin Area > Overview > Runners
- Specific runner用トークン：(リポジトリページ) > Settings > CI / CD > Runners

今回のサンプルでは、Shared runner用トークンは” Djsezx3UVs7pCALAV2hU”、デプロイ用Runnerに適用するdeployリポジトリ向けSpecific runner用トークンは” VtZP5zEAqKE5dvSQoRF6”です。これをRunner登録時に使用するのでメモしておきます。

Shared runner用トークン：Admin Area > Overview > Runners

画像5


Specific runner用トークン：(リポジトリページ) > Settings > CI / CD > Runners

画像6

3.2.2. Executor
次にExecutorですが、今回のサンプルではDocker executorを使わず、全てShell executor（GitLab非推奨）を使用します。Docker executor では環境固有の設定やツールがインストールされたコンテナイメージが必要ですが、構造が単純なサンプル環境の場合はShell executor でRunnerの実行環境を各GitLab-Runnerサーバー上に直接用意する方が早いのでそうしています。またレガシー環境には馴染みやすいので導入としては最適です。

Shell executorを採用する場合は、GitLab-Runnerがインストールされているサーバー上に実行環境が直接セットアップされている必要があります。なので、GitLabサーバーと本番踏み台サーバーに以下の設定を適用し、必要なツールをインストールします。

画像7

3.2.3. タグ
後述するCI/CDパイプラインは、ジョブごとにタグをつけることができます。ジョブにつけられたタグを持つRunnerだけがそのジョブを実行できる、という制御が可能になっています。これは、Runnerごとに実行環境が違うときに、対象のジョブの実行環境が整っていないRunnerがそのジョブを起動しないように制御するためです。

そこで今回は”build”と”deploy”、”dev”と”prod”の4つのタグを用意しました。後述するように、開発・本番共通のデプロイジョブをオーバーライドする開発デプロイジョブ（タグ：deploy, dev）と本番デプロイジョブ（タグ：deploy, prod）を用意し、タグの違いによってデプロイジョブの実行先を切り替える、ということをしています。

3.2.4. Runner登録コマンド
以上を踏まえたうえでのRunner登録コマンドは以下のようになります。gitlab-runner registerコマンドの各パラメータに上述した値をセットして実行します。

GitLabサーバー
# gitlab-runner register \
   --non-interactive \                              <= これを指定しないと対話モードになる
   --url "http://gitlab.example.com" \
   --registration-token "Djsezx3UVs7pCALAV2hU" \    <= Shared runner用トークン
   --executor "shell" \                             <= Shell executor
   --builds-dir "~/builds" \                        <= Runnerの作業ディレクトリのパス
   --description "builder" \                        <= Runner名
   --run-untagged=false \                           <= タグのないジョブは無視する
   --locked \
   --tag-list "build"                               <= buildタグを持つジョブが実行対象
# gitlab-runner register \
   --non-interactive \
   --url "http://gitlab.example.com" \
   --registration-token "VtZP5zEAqKE5dvSQoRF6" \    <= deployリポジトリ用トークン(Specific runner)
   --executor "shell" \
   --builds-dir "~/builds" \
   --description "dev-deployer" \
   --run-untagged=false \
   --locked \
   --tag-list "deploy,dev"                          <= deployとdev両タグを持つジョブが実行対象
本番踏み台サーバー
# gitlab-runner register \
   --non-interactive \
   --url "http://gitlab.example.com" \
   --registration-token "VtZP5zEAqKE5dvSQoRF6" \    <= deployリポジトリ用トークン(Specific runner)
   --executor "shell" \
   --builds-dir "~/builds" \
   --description "prod-deployer" \
   --run-untagged=false \
   --locked \
   --tag-list "deploy,prod"                         <= deployとprod両タグを持つジョブが実行対象

3.2.5. Runner確認
各サーバーにログインしてRunnerを登録したら、/etc/gitlab-runner/config.tomlを確認しましょう。以下のようにRunner情報が書き込まれていればOKです。また、「3.2.1. Shared runnerとSpecific runner」の「Runner登録例：Admin Area > Overview > Runners」のように画面上でも登録を確認することができます。

/etc/gitlab-runner/config.toml @GitLabサーバー
concurrent = 1
check_interval = 0
[session_server]
 session_timeout = 1800
[[runners]]
 name = "builder"
 url = "http://gitlab.example.com"
 token = "3JuRBVzDxc9RyryNvGeF"
 executor = "shell"
 builds_dir = "~/builds"
 [runners.custom_build_dir]
 [runners.cache]
   [runners.cache.s3]
   [runners.cache.gcs]
   [runners.cache.azure]
[[runners]]
 name = "dev-deployer"
 url = "http://gitlab.example.com"
 token = "GM2PvsLTTRe7WVt32sPL"
 executor = "shell"
 builds_dir = "~/builds"
 [runners.custom_build_dir]
 [runners.cache]
   [runners.cache.s3]
   [runners.cache.gcs]
   [runners.cache.azure]
/etc/gitlab-runner/config.toml @本番踏み台サーバー
concurrent = 1
check_interval = 0
[session_server]
 session_timeout = 1800
[[runners]]
 name = "prod-deployer"
 url = "http://gitlab.example.com"
 token = "NyWGJfgRdSPVmgR3aG8r"
 executor = "shell"
 builds_dir = "~/builds"
 [runners.custom_build_dir]
 [runners.cache]
   [runners.cache.s3]
   [runners.cache.gcs]
   [runners.cache.azure]


誤って登録してしまった場合は、この画面上で×ボタンを押して削除するか、以下のコマンドをサーバー上で実行してRunnerを削除してください。注意点としては、どちらの操作でもconfig.toml上の[[runners]]設定はそのまま残ってしまい、紛らわしいので手動で削除しておきましょう。  ​ 

Runner削除コマンド
# gitlab-ci-multi-runner unregister --url http://gitlab_.example.com --token <config.toml上のtoken>

Runnerの登録が完了したらGitLab-CI/CDを利用するための準備は完了です。

第1回 GitLab CI/CD環境構築は以上になります。
次回はSpring Bootデモアプリ用のCI/CDコードを作成・登録します。

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

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

公式noteお問合せ画像

お問合せはお気軽に
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/

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

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