法人のお客さま
お問い合わせ
ビジネスブログ

GitLab CIでマルチプロジェクトパイプラインを実装する

不破 僚太郎

アプリケーションエンジニア
不破 僚太郎

2024年12月25日掲載

キービジュアル

ソフトバンクアドベントカレンダー25日目の記事を担当する不破です。

私の普段行っている業務は2つあり、どちらも開発業務を担当しております。

  • STAION: AI映像解析プラットフォーム(アプリ開発/CI・CD整備/クラウド運用)
  • TASUKI: RAG向けのデータ作成ツール(アプリ開発)

STAION(映像解析PF)では、gitLab CIを使用してパイプラインを実装しています。

機能の中にはAzure Functionsを使用したバッチ処理が複数あり、各処理のソースコードがGitLabリポジトリに格納されています。また、各アプリケーションのCIでは、アプリケーションのDockerイメージをビルドし、その後Azure Container RegistryにPushする処理が実装されています。

そのため、各アプリケーションのCIパイプラインを個別に編集・実行する必要があり、Azure Functionsを使用したアプリケーションが増えるとCIを実行する手間がかかる問題がありました。具体的には複数のパイプラインを実行する際に画面遷移が多く、操作性が悪いことが挙げられます。

この記事では、複数のアプリケーションのパイプラインを一つのプロジェクトで実行できるようにするマルチプロジェクトパイプラインの実装方法について紹介します。

目次

この記事では
  • GitLab CIでマルチプロジェクトパイプラインの実装例を知ることができます
  • GitLab CIの基礎知識を知ることができます(参考にしたリンクをできるだけ貼ります）

サンプルから構成を紐解く

今回はブログ用にサンプルコードを作成したので、サンプルを例に構成について説明していきます。

プロジェクト構成について

まずは全体の構成について説明します。

  • sample-applications: Azure Functionに載せるアプリケーションPJが複数個配置されています。(本来は20個程度ありますが、サンプルなので5個で定義しています)
  • batch-pipeline: マルチパイプラインを実装するPJ(こちらは後述で言及します)
  • common-pipeline: 共通で使用するパイプラインを定義

アプリケーションの構成について

続いてsample-applications内のアプリケーションの構成について説明します。

本来であれば各PJにアプリケーションの実装コードと.gitlab-ci.ymlが配置してありますが、今回はdockerファイル/.gitlab-ci.ymlのみ配置しています。

azure-function-1
　　└dockerfile
　　└.gitlab-ci.yml

以下は各ファイルの実装コードになります。

dockerfile: 今回は実装コードを割愛するので、image 指定のみ
FROM mcr.microsoft.com/azure-functions/node:4-node18
.gitlab-ci.yml
include:
  - project: 'blog-sample/common-pipeline'
    ref: main
    file: template-ci.yml'

stages:
  - build-image

variables:
  TAG: latest
  REPOSITORY_NAME: azure-function-1
  ACR_URI: samplecontainer.azurecr.io
  USERNAME: sample_service_principal_user
  PASSWORD: sample_service_principal_pass

docker-build-to-acr:
  extends: .common:build-to-acr
  stage: build-image
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI}
    SERVICE_PRINCIPAL_USERNAME: ${USERNAME}
    SERVICE_PRINCIPAL_PASSWORD: ${PASSWORD}
  when: manual

パイプラインのコードが出てきたので、Gitlab CIの基礎知識を含めて説明していきます。

  • include: CI/CD ジョブに外部の YAML ファイルを含めることができるキーワードです。

　参考)他のファイルからCI/CD設定を使用 | GitLab

include:
  - project: 'blog-sample/common-pipeline'
    ref: main
    file: template-ci.yml'

トピック: 上記のコードはcommon-pipeline PJのmainブランチにあるtemplate-ci.ymlの内容を参照するものです。

 

  • stages: CI/CDパイプラインの中で実行される複数のジョブを "ステージ" という単位にまとめ、その実行順序を制御するキーワードです。

　参考) GitとCI/CDに関する知識ゼロのSEによる、GitLabのCI/CDパイプラインのキーワード解説 ～stages 編～ (2023/07/06 更新) - ネットワールド らぼ

stages:
  - build-image
  • variables: カスタムの変数定義ができるキーワードです。

　参考) GitLabCI入門 ~ 環境変数を使う ~ - Qiita

variables:
  TAG: latest
  REPOSITORY_NAME: azure-function-1
  ACR_URI: samplecontainer.azurecr.io
  USERNAME: sample_service_principal_user
  PASSWORD: sample_service_principal_pass

 トピック: グローバルの変数定義になるので、.gitlab-ci.yml内の他のジョブでも変数を参照することができます。

以下のコードはdocker imageをビルドし、ACRにpushするジョブになります。

docker-build-to-acr:
  extends: .common:build-to-acr
  stage: build-image
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI_DEV}
    SERVICE_PRINCIPAL_USERNAME: ${USERNAME}
    SERVICE_PRINCIPAL_PASSWORD: ${PASSWORD}
  when: manual
  • extends: includeで参照しているジョブを定義するキーワードです。

　参考) GitLab CI/CD設定ファイルの最適化

  • when manual: 手動でジョブを実行できるようにするキーワードです。

　参考) ジョブを実行するタイミングの選択 | GitLab

共通パイプラインの構成について

共通で使用するパイプラインを定義しているcommon-pipelineについて説明していきます。

common-pipeline PJ内の構成は以下になります。

common-pipeline
　　└template-ci.yml
　　└docker.gitlab-ci.yml
temlate-ci.yml
default:
  tags:
    - docker
  image: sample-image

include:
  - local: docker.gitlab-ci.yml
  • default: パイプラインのすべてのジョブのデフォルト値を設定できるキーワードです。

　参考) `.gitlab-ci.yml` キーワードリファレンス

default:
  tags:
    - docker
  image: sample-image

再度includeキーワードが出てきました。今回は内部ファイルを参照する場合の書き方になります。

include:
  - local: docker.gitlab-ci.yml

トピック: アプリケーションの.gitlab-ci.ymlから見ると、includeによって以下の経路でジョブが参照されます。

.gitlab-ci.yml ← template-ci.yml ← docker.gitlab-ci.yml(common:build-to-acr)

以下は.gitlab-ci.ymlでextendsされたジョブの処理です。

.docker.gitlab-ci.yml
.common:build-to-acr:
 before_script:
    - echo "---------- Assert variables ----------"
    - echo ${CONTAINER_REGISTRY:?undefined variable.} > /dev/null
    - echo ${REPOSITORY_NAME:?undefined variable.} > /dev/null
    - echo ${SERVICE_PRINCIPAL_USERNAME:?undefined variable.} > /dev/null
    - echo ${SERVICE_PRINCIPAL_PASSWORD:?undefined variable.} > /dev/null
    - echo ${TAG_NAME:?undefined variable.} > /dev/null
    - echo "--------------------------------------" 
 script:
    - |
      echo "------------ Login to ACR ------------"
      echo "${SERVICE_PRINCIPAL_PASSWORD}" | docker login --username ${SERVICE_PRINCIPAL_USERNAME} --password-stdin ${CONTAINER_REGISTRY}
      echo "------------ Make Docker Image ------------"
      docker build ./ --tag="${CONTAINER_REGISTRY}/${REPOSITORY_NAME}:${TAG_NAME}"
      echo "------------ Push Docker Image ------------"
      docker push ${CONTAINER_REGISTRY}/${REPOSITORY_NAME}:${TAG_NAME}

詳細は割愛しますが、処理の内容は以下になります。

  1. ジョブに入力する変数のバリデーションチェック(before_script定義)
  2. ACRにログイン→docker imageのビルド→ACRへのpush(script定義)

 

マルチプロジェクトパイプラインの実装

この記事の冒頭で、各アプリケーションのCIパイプラインを個別に編集・実行する必要があり、Azure Functionsを使用したアプリケーションが増えるとCIを実行する手間がかかる問題について言及しました。

そこでマルチプロジェクトパイプラインを実装し、この問題を解決します。

トピック: マルチプロジェクトパイプラインとは、最初のパイプラインとは異なるプロジェクトでトリガーされるダウンストリームパイプラインです。

　参考)マルチプロジェクトパイプラインの定義

トピック: ダウンストリームパイプラインとは、他のパイプラインによってトリガーされるGitLab CI/CDパイプラインのことです。また、トリガーになったパイプラインとは独立して実行されます。

　参考)ダウンストリームパイプライン

実施したこと

  • アプリケーションのパイプラインを一括で実行するPJを作成
  • 各アプリケーションにある.gitlab-ci.ymlの実行契機を変更

1. アプリケーションのパイプラインを一括で実行するPJを作成

サンプルの構成で言及したbatch-pipeline(マルチパイプラインを実装するPJ)を作成し、.gitlab-ci.ymlファイルを配置しています。

batch-pipeline
　　└.gitlab-ci.yml

gitlab-ci.ymlの実装コード

stages:
  - functions

variables:
  TAG: latest
  BRANCH_NAME: develop
  ACR_URI: samplecontainer.azurecr.io

  AZURE_FUNCTION_1: azure-function-1
  AZURE_FUNCTION_2: azure-function-2
  AZURE_FUNCTION_3: azure-function-3
  AZURE_FUNCTION_4: azure-function-4
  AZURE_FUNCTION_5: azure-function-5

build-to-acr-azure-function-1:
  stage: functions
  trigger:
    project: 'blog-sample/sample-applications/${AZURE_FUNCTION_1}'
    branch: ${BRANCH_NAME}
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI}
    REPOSITORY_NAME: ${AZURE_FUNCTION_1}
  when: manual

build-to-acr-azure-function-2:
  stage: functions
  trigger:
    project: 'blog-sample/sample-applications/${AZURE_FUNCTION_2}'
    branch: ${BRANCH_NAME}
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI}
    REPOSITORY_NAME: ${AZURE_FUNCTION_2}
  when: manual
〜　〜　〜
同じジョブ構成なので、azure-function-3/4は割愛
〜　〜　〜
build-to-acr-azure-function-5:
  stage: functions
  trigger:
    project: 'blog-sample/sample-applications/${AZURE_FUNCTION_5}'
    branch: ${BRANCH_NAME}
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI}
    REPOSITORY_NAME: ${AZURE_FUNCTION_5}
  when: manual

このパイプラインでは、 azure-function-1~azure-fuction-5の.gitlab-ci.ymlにアクセスをしてジョブの実行を管理しています。

build-to-acr-azure-function-1を抜粋し、マルチプロジェクトパイプラインに必要なキーワードを説明します。

build-to-acr-azure-function-1:
  stage: functions
  trigger:
    project: 'blog-sample/sample-applications/${AZURE_FUNCTION_1}'
    branch: ${BRANCH_NAME}
  variables:
    TAG_NAME: ${TAG}
    CONTAINER_REGISTRY: ${ACR_URI}
    REPOSITORY_NAME: ${AZURE_FUNCTION_1}
  when: manual
  • trigger: ジョブがダウンストリームパイプラインを開始する “トリガージョブ “であることを宣言するキーワードです。

　参考)`.gitlab-ci.yml` キーワードリファレンス

トピック: triggerによってazure-fuction-1の.gitlab-ci.ymlのジョブを参照することができます。また、includeとの違いとしては、ダウンストリームによる実行になるため、アプリケーションのジョブが並列で実行されます。

2.各アプリケーションにある.gitlab-ci.ymlの実行契機を変更

各アプリケーションPJから1.で作成したパイプラインに実行契機を渡すために以下の要素を追加しました。

  • rules: ジョブの実行タイミングを操作するキーワード

　参考)ジョブを実行するタイミングの選択 | GitLab

  • $CI_PIPELINE_SOURCE == "pipeline”

　triggerキーワードで呼び出されたことを検知してパイプラインが実行されます。

　参考)ダウンストリームパイプライン

以下は実装例

docker-build-to-acr:
  extends: .common:build-to-acr
  stage: build-image
  variables:
    SERVICE_PRINCIPAL_USERNAME: ${USERNAME}
    SERVICE_PRINCIPAL_PASSWORD: ${PASSWORD}
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"

パイプライン実行画面

一つのプロジェクトで複数のアプリケーションのパイプラインを実行できるようになりました！！

まとめ

この記事では、複数のアプリケーションを一括で実行できるようにするマルチプロジェクトパイプラインの実装方法について記載しました。

また、Gitlab CIについての基礎知識やトピックも合わせて紹介できたと思います。

ソフトバンクでは、カメラで取得した映像データをAIで分析・解析し、情報へと変換するAI映像解析プラットフォームであるSTAIONサービスを提供しています。

具体的には、カメラ映像をAIで解析・処理するエッジデバイス、通信ネットワークの他、AIによる解析結果を基に欠品や空席、危険な行動、不良品の検知や、人数カウント、年齢・性別の推定などが可能な各種サービスを「STAION」と連携させて、さまざまな業界・業種で利用できる映像解析ソリューションとしてワンストップで提供しています。

もしご興味がある方は、ぜひソフトバンクにご相談ください。

関連サービス

AI映像解析プラットフォーム STAION（スタイオン）

さまざまな業種で活用できるAI映像解析プラットフォーム。AIがカメラ映像を分析し、業務プロセスの効率化、セキュリティ向上、顧客エクスペリエンスの向上など、幅広い価値を生み出します。

 

TASUKI Annotation RAGデータ作成ツール

TASUKI Annotation RAGデータ作成ツールは、RAGを高度に活用する際に課題となるポイントをテクノロジーで支援するツールです。
RAGに関する知見がなくても、社内データを活用した精度の高いRAG回答生成を簡単に得ることが可能です。

 ＼ 業務課題をデジタルで支援 ／

デジタルツールの選定から導入の手引きまで、中小規模のお客さまへわかりやすくお伝えします。

中小規模のお客さま向けサイトをみる

メールマガジン登録（無料）
ビジネスに役立つ記事やウェビナー情報をお届けします。

おすすめの記事

条件に該当するページがございません

法人のお客さま向け イベント

イベント・セミナー

ビジネスに役立つ 資料ダウンロード

資料ダウンロード

「今」と「未来」を発信 ソフトバンクのビジネスブログ

ビジネスブログ

クラウドテクノロジーブログ

クラウドテクノロジーブログ