GitLab Runnerで始める継続的インテグレーション
クラウドネイティブNow
はじめに
クラウドネイティブの実現には、企業の継続的な取り組みが不可欠です。
Cloud Native Computing Foundation (CNCF) は、クラウドネイティブの実現のために企業が何を実施すれば良いかの概要を Cloud Native Trail Map として公開しています。Cloud Native Trail Map では10のステップに分けて、クラウドネイティブの実現のための手法が紹介されています。
クラウドネイティブ及び Cloud Native Trail Map についての詳しい説明については以下の記事もご参照ください。
Cloud Native Trail Map は必ずしもステップの順序に従って採用すべきものではなく、企業の状況、体制に合わせて実現可能なものから実施していくことが良いとされています。例えば、ステップ2としてあげられている CI/CD（継続的インテグレーション / 継続的デリバリー）は、クラウドネイティブなアプリケーションの開発や運用において重要な要素として、一番最初に組織に導入しやすい内容とも言えるでしょう。CI/CD（継続的インテグレーション / 継続的デリバリー）を導入することで、継続的な改善を実施する文化の浸透も期待できます。
近年の開発においては分散型バージョン管理システムである Git を用いた開発手法が主流になっています。CI/CD（継続的インテグレーション / 継続的デリバリー）を実施する主流な方法として、Push や Merge などの Git の操作によってリモートリポジトリ上でコードの変更が行われた際に、自動でビルド、テスト、デプロイを行うことがあげられます。
One DevOps プラットフォームである GitLab では Runner を登録することで、CI/CD（継続的インテグレーション / 継続的デリバリー）を実践するための機能を提供できるようになっています。
本記事ではクラウドネイティブを実現するにあたって、CI/CD（継続的インテグレーション / 継続的デリバリー）を GitLab と GitLab Runner を用いて導入する方法を紹介します。
GitLab Runnerの概要と機能
GitLab Runner は、GitLab CI/CD の一部として使用されるオープンソースのプロジェクトであり、ビルド、テスト、デプロイなどのジョブを実行するための機能を持つソフトウェアです。開発のリポジトリに.gitlab-ci.ymlを作成することで、GitLab上でCI/CD（継続的インテグレーション / 継続的デリバリー）の構成を簡単に作成することが可能です。
自動ビルド
TypeScript や Java , C++ などの言語を使用したアプリケーションは通常そのままでは動かすことができないため、コンパイルやトランスパイルといった工程を実施する必要があります。CI(継続的インテグレーション)の自動ビルドでは、この工程を Git の Commit 毎に実行します。
また、自動ビルドの環境が整うようになると、クラウドネイティブな開発のフェーズの1つとして、アプリケーション自体のコンテナ化も候補に入ってくるでしょう。自動ビルドではこのようなアプリケーションのコンテナ化も Git の Commit 毎に実行可能です。GitLab Runner 上でのコンテナのビルドを行うためには、GitLab Runner 特権での実行を有効にするか、kanikoを利用できます。さらに、GitLab ではContainer Registry機能を提供しているので、作成したコンテナをリポジトリ単位で保持しておくことが可能です。
GitLab RunnerはGitLabとは別のソフトウェアとしてインストールしたのち、GitLabとの連携を設定することで利用することができます。
自動テスト
システムの振る舞いに対するテストとして、大きく単体テストと統合テストに分けられます。単体テストは、1単位の振る舞いを検証するためのテストであり、実行時間が短いことや他のテストケースから隔離された状態で実行されることが特徴としてあげられます。一方で統合テストではプロセス外依存とのやりとりを検証するためのテストです。このプロセス外の依存を検証するために、実際にデータベースとの接続をしてテストを行いたいことがあります。GitLabにはServiceという機能があり、テスト毎にGitLab Runner上でデータベースを準備することができます。
Pipelineを実行する度に、GitLab Runner上でデータベースを準備するためには、リポジトリに.gitlab-ci.ymlという名前のファイルを追加し、以下の記述を追加します。
services:
- name: mysql:8.0.32
alias: testdb
variables:
TZ: Asia/Tokyo
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: db_name
GitLabが提供するService機能についての詳しい説明については公式ドキュメントもご参照ください。
また、GitLabでは予めテンプレートが準備されているので、セキュリティに関するテストを簡単に追加することも可能です。同じように、リポジトリに.gitlab-ci.ymlというファイルを追加し、以下の記述をすることでセキュリティに関するテストが可能です。 以下の記述は、Container Registry機能を用いて登録済みのコンテナ名${CI_REGISTRY_IMAGE}に対してセキュリティスキャンをかける場合の例になります。
stages:
- test
container_scanning:
variables:
CS_IMAGE: '${CI_REGISTRY_IMAGE}'
include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Jobs/Container-Scanning.gitlab-ci.yml
GitLabが提供するセキュリティ機能についての詳しい説明については以下の記事もご参照ください。
おわりに
本記事ではGitLab Runnerの利用方法を解説しました。
富士通のGitLabマネージドサービス「DevOps with GitLab」では、2023年5月よりGitLab Runner機能を提供しており、CI/CD（継続的インテグレーション / 継続的デリバリー）を実現するために必要な開発環境をFJcloud-Vのコントロールパネル上だけで簡単に整えることが可能になっています。導入時の課題となるGitLab Runnerの運用やバージョンアップなどの管理を全て富士通に任せ、ビジネスに集中できます
関連情報
当社は「GitLabのマネジドサービス」及び「GitLabのソフトウエアライセンス」を提供しております。詳細は下記ページをご覧ください。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
Webでのお問い合わせ
当社はセキュリティ保護の観点からSSL技術を使用しております。
