GitLabによるCI実践入門――Kubernetesで利用するコンテナイメージをビルドする:Cloud Nativeチートシート(6)
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、GitLabによるCI(継続的インテグレーション)について解説します。
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回は、Kubernetesの利用を前提とした「Kubernetes Native」なCI/CD(継続的インテグレーション/継続的デリバリー)について、歴史と背景を踏まえ、CI/CDに具備すべき機能がどういったものかをツールの比較と動向も交えて解説しました。
今回は、CIによるKubernetesにデプロイするコンテナイメージの作成方法を紹介します。CIを行う際にポイントとなるマージリクエストによるCIの実行、コンテナの脆弱(ぜいじゃく)性スキャン、テスト結果やカバレッジのCIの結果、開発者環境とCI環境でテスト結果を同じようするコツなどを併せて紹介します。Kubernetesを用いたCI/CDを、これから行うとしている方の参考になればと思います。
なおCDについては、次回記事で紹介します。
目次
KubernetesアプリケーションにおけるCIとは
前回の記事の再掲となりますが、Kubernetesで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を実行します。
コラム 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を行うことにより、次のようなメリットがあります。
- 機能の実装やバグフィクスごとにCIを実行でき、他の作業の影響を避けることができる
- mainブランチへのマージ前にCIの結果を確認でき、確実にCIが成功してからmainブランチにコードをマージできる
- マージリクエスト上でCIの結果が確認でき、CIの失敗履歴や、失敗に対応したソースコードの修正履歴を1つのマージリクエストの画面で追えるようになる
- マージリクエストを作成しなければ、作業途中のコードをブランチにコミットしても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を利用します。
関連記事
- GitLabが日本市場に本格参入、「単一製品でDevOpsの全ライフサイクルをカバー」
DevOpsプラットフォーム製品を提供するGitLabは2020年4月28日、日本市場への本格参入を発表した。同社のCEOであるシッツェ・シブランディ氏は、国内メディア向けのオンライン説明会で、同社の戦略について語った。 - CI/CDは何がまずいのか、コード作成から本番デプロイまでの時間短縮に注力
オブザーバビリティツールを手掛けるhoneycomb.ioの共同創業者でCTOを務めるチャリティ・メージャーズ氏が、CI/CDの問題点を指摘した。CIにばかり注力せず、CDにも気を配るべきであり、特にコード作成から本番環境へのデプロイまでの「時間の短縮」にフォーカスすべきだという。 - CI/CDの世界を標準化? 新たに発足した組織「Continuous Delivery Foundation」とは
The Linux Foundationが2019年3月12日(米国時間)に発表した、CI/CD関連の新ファウンデーション、「Continuous Delivery Foundation」。具体的にはどのような活動をすることになるのか。このファウンデーションの設立に関わった、Jenkinsの生みの親でCloudBeesのCTOである川口耕介氏に聞いた。
Copyright © ITmedia, Inc. All Rights Reserved.