TECHSTEP

ITインフラ関連の記事を公開してます。

GitLab CI/CD Catalogの紹介

今回はGitLab 16.7でベータ版をリリースしたCI/CD Catalogを紹介します。

docs.gitlab.com

背景

GitLab CI/CD Catalogの前に、CI/CD componentsについて理解する必要があります。

CI/CD componentsはGitLab内部で再利用可能なパイプラインのユニットです。CI/CD componentを使うことで、小さな部品を組み合わせるようにパイプラインを設定でき、より大きなパイプラインを設定することも可能となります。

CI/CD componentは 以前取り上げた include と似たような機能であり、CI/CD componentを利用するときは include:component という形で定義します。ただし、CI/CD componentにはいくつかの利点があります。

  • CI/CD Catalogの中でリスト化され、必要なものを見つけやすくなります。
  • componentは特定のバージョンをリリース・使用できます。
  • 同じProject内で複数のcomponentを定義し、バージョン管理できます (最大10個まで) 。

CI/CD Catalogは、上記の通りCI/CD componentsをリスト化したものですが、Project内部で用意したものだけでなく、外部に公開されたものも利用できます。

なお、CI/CD CatalogについてはGitLabのブログでも紹介されています。

about.gitlab.com

検証

ここから実際にCI/CD Catalogを使ってみます。

CI/CD componentsを組織内部で利用

まずはCI/CD Catalogの前にCI/CD Componentsを組織内で利用する例を試します。ここでは cicd-catalog-test-component というProjectにテスト用のテンプレートを配置し、 cicd-catalog-test Projectからそれを呼び出します。

CI/CD componentsのテンプレートを用意する場合、いくつかの条件 (と推奨事項) があります。

  • ディレクトリ構成
    • README.mdリポジトリ中のcomponentsの詳細が記載されていること
    • templates ディレクトリがルートに配置され、全てのcomponentsの定義がそこに含まれること
    • componentファイルは .yml という拡張子であること
    • templates ディレクトリ内はサブディレクトリも含められるが、各サブディレクトリにはエントリポイントとして template.yml というファイルが含まれていること
  • 推奨事項
    • .gitlab-ci.yml を使ってcomponentsのテストとリリースを行うこと
    • LICENSE.md ファイルを配置し、ライセンス情報を加えること

1つのcomponentファイルを含むリポジトリの場合は以下のような構成が推奨されています。

├── templates/
│   └── my-component.yml
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

cicd-catalog-test-component には、以下のようなファイルを用意します。今回は必要最小限のファイルのみ配置します。

├── templates/
│   └── my-component.yml
└── README.md

templates/my-component.yml

spec:
  inputs:
    stage:
      default: test
---
component-job:
  script: echo "This is from cicd-catalog-test-component project."
  stage: $[[ inputs.stage ]]

上記ファイルに含まれる spec とは、GitLab CI/CDで利用するHeader keywordの1つであり、 Pipelineに include が含まれたときの動作設定を定義できます。ここでは spec:inputs で実行時の入力パラメータとして stage を追加しています。また spec:inputs:default でデフォルトの入力値を設定します。

docs.gitlab.com

次に、上記componentを呼び出す側として cicd-catalog-test というProjectを作成し、 .gitlab-ci.yml ファイルからこれを呼び出します。

CI/CD componentsを呼び出す場合、 include:component を使用します。componentを指定するときは <FQDN>/<Projectパス>/<component名>@<バージョン> というフォーマットを使います。

  • FQDN: GitLabホストとマッチするFQDNを指定
  • Projectパス: componentを含むProjectのフルパスを指定
  • component名: 単一ファイルの場合はファイル名、複数の場合は template.yml を含むディレクトリ名を指定
  • バージョン: Commit SHA、タグ、ブランチ名、 latest などを指定

今回は .gitlab-ci.yml で以下のように定義しました。

stages:
  - build
  - test

build:
  stage: build
  script:
    - echo "This is from cicd-catalog-test project at build stage."

test:
  stage: test
  script:
    - echo "This is from cicd-catalog-test project at test stage."

include:
  - component: gitlab.com/fy0323/cicd-catalog-test-component/my-component@main
    inputs:
      stage: build

.gitlab-ci.ymlを配置すると、以下のようにパイプラインが実行され、定義通り build Stageで component-job Jobが実行されます。

ここで component-job を見ると、 cicd-catalog-test-component で定義した通りの文字列が表示されるのを確認できます。

CI/CD Catalogの利用

次にCI/CD Catalogを利用します。

まずCI/CD Catalogのリストを確認します。GitLab UIの 検索または移動先 を選択し、 検索 を選択します。画面左メニューに CI/CDカタログ と表示されるのでそこを選択すると、CI/CD Catalogが表示されます。なお操作時は全部で101のCatalogが登録されていました。

ここではその中から components/sast というCatalogを利用します。このCatalogは名前の通りSASTを実行するものであり、GitLabの提供するSASTと同一の機能を提供します。

各Catalogには README.md に記載された内容が表示され、基本的な使用方法などが紹介されています。

ここでは components/sast の内容に従い、以下のように .gitlab-ci.yml を修正します。またSASTのテスト用に適当なファイルを配置します。

※なお本検証はGitLab 16.8時点に行いましたが、GitLab 16.10からはSemantic versioningによる指定が強制されます

include:
  - component: gitlab.com/gitlab-components/sast/sast@1.0

パイプラインを起動すると、ここでは semgrep-sast というJobが実行されている様子を確認できます。

semgrep-sast を選択するとSASTが実行されていることが確認できます。またArtifactも配置されており、スキャン結果も確認できました。