GitLabによるCI実践入門――Kubernetesで利用するコンテナイメージをビルドする：Cloud Nativeチートシート（6）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、GitLabによるCI（継続的インテグレーション）について解説します。

[栗田裕亮, 岡本隆史，株式会社NTTデータ]

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回は、Kubernetesの利用を前提とした「Kubernetes Native」なCI/CD（継続的インテグレーション／継続的デリバリー）について、歴史と背景を踏まえ、CI/CDに具備すべき機能がどういったものかをツールの比較と動向も交えて解説しました。

　今回は、CIによるKubernetesにデプロイするコンテナイメージの作成方法を紹介します。CIを行う際にポイントとなるマージリクエストによるCIの実行、コンテナの脆弱（ぜいじゃく）性スキャン、テスト結果やカバレッジのCIの結果、開発者環境とCI環境でテスト結果を同じようするコツなどを併せて紹介します。Kubernetesを用いたCI/CDを、これから行うとしている方の参考になればと思います。

　なおCDについては、次回記事で紹介します。

目次

• KubernetesアプリケーションにおけるCIとは
• コラム　masterブランチ終了のお知らせ。mainブランチこんにちは
• コラム　CIはマージリクエスト／プルリクエストで
• GitLabによるCIの特徴
• GitLabでCIを実践してみよう
  • CIの実行
  • 1.リポジトリのフォーク
  • 2.ブランチの作成
  • 3.ソースコードの変更
  • 4.マージリクエストの作成
  • 5.CIの実行結果の確認
• サンプルの概要
  • ファイルの配置
  • GitLabのビルド定義（.gitlab-ci.yml）
  • Dockerfileの解説
• コラム　dockerコンテナとdindコンテナの関係
• コラム　コンテナイメージのビルドの設計指針

KubernetesアプリケーションにおけるCIとは

　前回の記事の再掲となりますが、KubernetesでCI/CDを行う場合、CIはアプリケーションをソースコードから最終的にコンテナイメージを作成し、コンテナレジストリに登録するところまでを担当します。つまり、コンテナレジストリにイメージを登録できればゴールです。

図1　CI/CDの概要とCIの担当

　なお今回は、CIツールとして「GitLab」を、サンプルアプリケーションとして「Go言語」で作成したWebアプリケーションを、コンテナイメージの脆弱性スキャンツールとして「Trivy」を利用します。Trivyは、Kubernetesのセキュリティで定評のあるAqua Securityが開発しています。

　以降、ソースコードからコンテナイメージをビルドし、イメージをレジストリに登録していく手順を紹介します。

手順1.ブランチ作成

　下準備として、機能追加、バグフィクス用にGitブランチを作成しておきます。Gitのブランチに関する詳細は「いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識」などの記事をご覧ください。このブランチ作成は、ソースコードの変更を承認してもらうための、下記手順3.マージリクエストの下準備です。

手順2.ソースコード作成・編集

　ソースコードを作成、編集し、Gitリポジトリにコミット、プッシュします。

手順3. マージリクエスト（プルリクエスト）作成

　手順1.で作成したブランチからマージリクエストを作成します。CIはマージリクエスト作成、更新時に実行します。マージリクエストの更新は、手順1.で作成したブランチに変更をプッシュすると自動的に反映されます。また、マージリクエストをmain（master）ブランチにマージした際にも、手順1.でブランチを作成した後の変更に影響がないかどうかを確認するためにCIを実行します。

図2　マージリクエストとCIの実行

コラム　masterブランチ終了のお知らせ。mainブランチこんにちは

　最近、Master（主人）やSlave（奴隷）といった、差別を想起させる用語を使わないようにしようという動きがIT業界にあります。

　Gitのデフォルトブランチ名で利用される「master」についても同様で、廃止して「main」にしようという動きがあります。

　GitLabにおいても、2021年5月22日にリリースされたGitLab 14でデフォルトブランチ名をmasterからmainに変更しました。GitHubでは、既に2020年10月からデフォルトブランチをmainブランチに変更しています（GitHubのアナウンス）。

　デフォルトブランチは今後、できるだけ「main」を利用した方がよいでしょう。

手順4. コンテナイメージビルド

　コンテナイメージをビルドします。ビルドは、マージ／プルリクエストの作成、修正や、mainブランチへのマージをトリガーとして行います。

手順5. 脆弱性スキャン

　コンテナイメージに脆弱性がないかどうかをスキャンします。

手順6. コンテナレジストリへのプッシュ

　コンテナレジストリにコンテナイメージを登録します。

コラム　CIはマージリクエスト／プルリクエストで

　最近は、ソースコードをGitのリポジトリで管理する現場が増えていると思いますが、CIはマージリクエスト（GitLab）、プルリクエスト（GitHub）上で行うと便利です。マージリクエスト上でCIを行うことにより、次のようなメリットがあります。

1. 機能の実装やバグフィクスごとにCIを実行でき、他の作業の影響を避けることができる
2. mainブランチへのマージ前にCIの結果を確認でき、確実にCIが成功してからmainブランチにコードをマージできる
3. マージリクエスト上でCIの結果が確認でき、CIの失敗履歴や、失敗に対応したソースコードの修正履歴を1つのマージリクエストの画面で追えるようになる
4. マージリクエストを作成しなければ、作業途中のコードをブランチにコミットしてもCIが実行されないので、無駄なCIによるマシンリソースの消費を防げる

GitLabによるCIの特徴

　本稿で紹介するGitLabを利用したCIの特徴を簡単に紹介します。

特徴1.マージリクエスト上でCIを実行できる

　GitLabは、Gitリポジトリの機能、Gitブランチのマージの承認を依頼するマージリクエスト（プルリクエスト）の機能を持っています。また、このマージリクエストが作成されたときとマージリクエストで指定されたブランチが更新されたときに、自動的にCIを実行する機能も持っています。

特徴2.コンテナイメージもGitLabで管理できる

　GitLabには、コンテナイメージのレジストリ機能もあるので、ユーザーはビルドしたコンテナイメージをGitLabで管理できます。GitLabのレジストリにプッシュしたコンテナは、他のユーザーに公開することもできますし、プロジェクトや個人に閉じて非公開にすることもできます。

特徴3.広く使われている

　広く使われているツールなので、CIを実行するスクリプトのサンプルが簡単に見つかります。

特徴4.インストール不要でコンテナイメージのビルドが可能

　無料のSaaSバージョンを利用すれば、インストールせずにイメージのビルドからコンテナレジストリへのアップロードまで可能です。何もインストールしなくても、手軽に始めることができます。

GitLabでCIを実践してみよう

　ここからは、「GitLabでコンテナイメージを作成するにはどうすればよいか」についてサンプルアプリケーションを用いて解説します。本稿では、サンプルアプリケーションとしてGo言語で記述された簡易なREST APIを利用します。