目次
テンプレート リファレンス、コードの冗長性を削減し、CI/CD ビルドのスケーラビリティを強化
コンポーネント。CI/CD パイプラインの信頼できる単一ソースを作成し、CI/CD パイプラインの構築を簡素化します。
コンプライアンス組立ライン。組立ラインの安全かつコンプライアンスに準拠した使用を支援します。
JiHu GitLab CI は JiHu GitLab 統合プラットフォームに組み込まれており、すぐに使える CI/CD 機能を提供し、多くのユーザーに愛されている CI ツールの 1 つです。Jihu GitLab CI の独自の設計メカニズムとエンタープライズ レベルの機能機能は、企業が十分なセキュリティ コンプライアンスを維持しながら、 CI/CD プラクティスを大規模に実装する際に CI/CD 構築効率を向上させ、パイプライン メンテナンス コストを削減するのに役立ちます。
この記事では、CI/CD パイプラインの構築から始まり、次の 3 つの主要な側面で Jihu GitLab CI の使用方法について説明します。
-
を使用して
template、componentパイプラインの作成時間を短縮し、保守性を向上させます。 -
Runner の「派手な」ゲームプレイを使用して、使用コストを削減しながら、さまざまなシナリオでの CI/CD パイプライン運用のニーズに対応します。
-
コンプライアンス フレームワークを使用して、CI/CD パイプラインのコンプライアンスに準拠した使用を保証します。
テンプレート リファレンス、コードの冗長性を削減し、CI/CD ビルドのスケーラビリティを強化
企業内では、さまざまなチームまたはさまざまな製品ラインが独自のプロジェクトを持ち、各プロジェクトに対応する CI/CD パイプラインがあるという非常に一般的なシナリオが考えられます。プロジェクトの数が増加するにつれて、パイプラインの数も増え続けます。 、企業内には何百、あるいは何千もの組立ラインが存在する場合があります。
CI/CD パイプラインはソフトウェア配信 (コーディングからオンラインまで) の自動形式であるため、ほとんどのパイプラインは比較的高い類似性を持ち、クラウド ネイティブ配信シナリオなど、一部のステージやジョブはまったく同じです。アプリケーションはミラーにパッケージ化する必要があります。Jihu GitLab CI を使用してビルドするコードは次のとおりです。
build:
image: docker:latest
stage: build
services:
- docker:20.10.7-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:1.0.0 .
- docker push $CI_REGISTRY_IMAGE:1.0.0
さらに、それらがすべて Java または golang プロジェクトである場合、コンパイルまたはテストのコマンドは類似している可能性があります。パイプラインが増加するにつれてこの「繰り返し」が増加し、次のような問題も発生します。
問題 1: 冗長なコードと非効率的な手法
各パイプラインに約 10 行のコードを含む同様のステージまたはジョブがある場合、数百または数千のパイプラインで重複するコードの数は数万になります。この種のコードの冗長性自体は、ソフトウェア開発の分野では非効率的な手法であり、時間内にリファクタリングされないと、プロジェクトが進行するにつれて技術的負債となります。
問題 2: 保守が難しく、作業負荷が大きい
CI/CD パイプラインを最適化するプロセスでは、イメージを安全にビルドするために dind バージョンのアップグレードやビルド方法を dind から kaniko に変更するなど、パイプラインの一部を変更する必要があります。その後、対応するコードを変更する必要があります。変更される:
services:
- docker:24.0.3-dind
そして：
build:
stage: build
image:
name: registry.jihulab.com/jh-xiaomage-devops/go-demo/kaniko:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
- >-
/kaniko/executor
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:1.0.0"
このとき、すべてのパイプラインを変換する必要があります。数百、場合によっては数千のパイプラインの変換は膨大な作業負荷となり、大量のコードの「コピー アンド ペースト」プロセスをエラーなく回避することは困難です。
ソフトウェアの研究開発の分野では、冗長なコードを解決する重要な方法は、抽象化 + 再利用です。つまり、同じ (または類似した) コンテンツをテンプレートに抽象化し、そのテンプレートを特定の場所に「保存」し、単に参照することです。テンプレートは他の場所にあります。
CI/CD パイプラインにも同じことが当てはまります。GiFox GitLab テンプレートは、GiFox GitLab CI の組み込みテンプレート エンジン機能であり、抽象化されたテンプレートをプロジェクト ウェアハウスに保存でき、他のプロジェクトは include 構文を通じてテンプレートを参照できます。
Jihu GitLab テンプレートの使用方法は比較的柔軟で、まずテンプレートを「作成」する必要があります。つまり、「重複」コードを抽出して YAML ファイルに保存します。たとえば、上記のイメージ ビルド コンテンツは docker-image-build.gitlab-ci.yml ファイルに書き込むことができます。次に include 引用を使用します。テンプレートが保存されている場所に応じて、include テンプレートを参照するには 4 つの方法があります。
➤ ローカル
テンプレートは現在のプロジェクト内にあり、 local キーワードを使用して参照されます。使用構文は次のとおりです。
include:
- local: '/templates/docker-image-build.gitlab-ci.yml'
➤ ファイル
テンプレートとプロジェクトは同じインスタンスにありますが、異なるリポジトリにあり、 file キーワードを使用して参照されます。使用構文は次のとおりです。
include
- project: xiaomage/templates
- ref: main
file: /templates/docker-image-build.gitlab-ci.yml
➤ リモート
リモート ウェアハウス内のパイプラインへの参照 (通常は異なるインスタンス間)。使用構文は次のとおりです。
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
➤ テンプレート
JiHu GitLab の組み込みテンプレートへの参照。GitLab は長年の経験に基づいて、テンプレート構文を使用して直接再利用できるテンプレートを多数蓄積しています。最も典型的なものは、Jihu GitLab DevSecOps テンプレートのリファレンスです。GitLab DevSecOps には、キー スキャン、依存関係スキャン、SAST、DAST、コンテナ イメージ スキャン、ファズ テスト、ライセンス コンプライアンス検出機能があり、すべての機能を 2 行のコードで有効にすることができます。
したがって、テンプレートを使用すると次の利点が得られます。
利点 1: 1 つの変更が多くの場所で有効になります
dind のバージョンアップなど、パイプラインの内容を最適化する必要がある場合は、テンプレートを変更するだけで、他の参照箇所が反映されるため、まさに「1箇所で変更、複数箇所で反映」が実現します。 これにより、「一度変更すればどこでも変更」によって生じる作業の重複も完全に回避され、パイプラインの冗長性も削減されます。
メリット2：施工が効率的、簡単・便利
テンプレートは複数レベルの入れ子を実現できます。つまり、テンプレートはテンプレート内で参照されます。この利点は、テンプレートの内容をきめ細かく設定できることです。これはステージまたはジョブにすることができます。たとえば、コンテナー イメージの構築はテンプレートであり、コンテナー イメージのセキュリティ スキャンは別のテンプレートです。新しいプロジェクトのパイプラインを構築する場合は、複数のテンプレートを直接使用して「ビルディング ブロックを構築」し、パイプラインの構築を迅速に完了し、実際の構築プロセスに従ってパラメータまたはプロセスにいくつかの変更を加えることができます。プロジェクト。
もちろん、テンプレートを効率的に使用するためには、テンプレート内の変数の上書きにも注意する必要があります。
テンプレートを柔軟に使用するには、同じテンプレートのセットを使用して複数の異なるインスタンスを構築します。重要なのは、テンプレートでの変数の使用にあります。たとえば、コンテナ イメージをビルドする場合、タグはバージョンごとに異なる場合がありますが、この場合、タグを変数として設定できます。
variables:
IMAGE_TAG: 1.0.0
build:
image: docker:latest
stage: build
services:
- docker:20.10.7-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
参照ポイントで変数を直接上書きするだけです。
variables:
IMAGE_TAG: "2.0.0"
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
上書き後、イメージ タグの値はデフォルトから 1.0.0 変更されます 2.0.0 。これはさまざまなシナリオの要件を満たすことができ、効率的かつ柔軟です。
コンポーネント。CI/CD パイプラインの信頼できる単一ソースを作成し、CI/CD パイプラインの構築を簡素化します。
テンプレートを使用すると、ユーザーが CI/CD パイプラインを構築する難しさが大幅に軽減されます。リファレンス + パラメーター カバレッジ モードを通じて、シナリオに対応するパイプラインを迅速に構築できます。ただし、現時点では、ユーザーが簡単に見つけられる信頼できるテンプレートのソースはありません。 Pipeline を使用している間、貢献する意欲のあるユーザーは、繁栄した Pipeline エコシステムを共同で構築するために利用可能なテンプレートを貢献することはできません。
この目的を達成するために、 Jihu GitLab は CI/CD コンポーネント機能を開始しました。その目的は、さまざまなパイプライン (または個別のジョブ) をさまざまなコンポーネントに変換し、コンポーネント ウェアハウスに公開することで、CI/CD パイプラインの信頼できる単一のソースを作成することです。他のユーザーは、このウェアハウス内で必要なコンポーネントを検索できます。パイプラインを構築するときに直接参照できます。複数のコンポーネントの参照により、完全なパイプライン全体を迅速に構築できます。これは大きな変更です。CI を使用するユーザー エクスペリエンスの向上/CD。
さらに重要なのは、ユーザーがコンポーネントの形で実践されていると思われる優れたパイプライン (または個々のジョブ) をコンポーネント ウェアハウスに公開し、さまざまなユーザーの継続的な貢献と反復を通じて、豊かな CI/CD パイプライン エコシステムを共同で作成できることです。これにより、 CI /CD パイプライン構築の効率が向上するだけでなく、セキュリティも大幅に向上します。
注: CI/CD コンポーネントは現在実験段階です。
CI/CD コンポーネント図
したがって、コンポーネントの核心は、コンポーネント ウェアハウスの構築、コンポーネントのリリース、およびコンポーネントの参照です。
部品倉庫の建設
GitLab リポジトリを作成し、それをコンポーネント リポジトリとしてマークすることで、初期コンポーネント リポジトリを構築します。リポジトリには少なくとも 2 つのファイル README.md と以下が 必要ですtemplate.yml。
-
README.mdウェアハウスに含まれるコンポーネントは、ユーザーが学習して使用しやすいように説明できます。 -
template.ymlコンポーネントの具体的な内容です。
さまざまなコンポーネントは、次のようなさまざまなディレクトリ構造 (ブランチ、タグなど) によって区別できます。
├── template.yml
├── README.md
├── .gitlab-ci.yml
├── forntend/
│ └── template.yml
└── backend/
└── template.yml
上記のディレクトリは、このコンポーネント ウェアハウスで利用可能なコンポーネントが 3 つあることを示しています。
-
ルート ディレクトリに
template.ymlあるコンポーネント。 -
フロントエンド ディレクトリで
template.yml表されるコンポーネント。 -
バックエンド ディレクトリで
template.yml表されるコンポーネント。
「プロジェクト」→「設定」→「一般」→「可視性」、「プロジェクト機能」、「一般」→「CI/CD ディレクトリ リソースを有効にする」により、ウェアハウスをコンポーネント ウェアハウスとしてマークできます。
コンポーネントのリリース
コンポーネントを公開する必要がある場合は、対応するコンテンツをファイルに書き込み template.yml 、そのファイルをコンポーネント ウェアハウスにプッシュする必要があります。上記のイメージ構成を例として、次の内容をファイルに書き込みます template.yml 。
spec:
inputs:
stage:
default: test
image:
default: docker:latest
tags:
default: tags
image_tag:
default: 1.0.0
component-job-build-image:
image: $[[ inputs.image ]]
stage: $[[ inputs.stage ]]
tags:
- $[[ inputs.tags ]]
script:
- docker login -u "$REGISTRY_USER" -p "$REGISTRY_PWD" REGISTRY_URL
- docker build -t dllhb/cicd-component:$[[ inputs.image_tag ]] .
- docker push dllhb/cicd-component:$[[ inputs.image_tag ]]
次に、それを jh.instance.url/username/component-project ディレクトリにプッシュします。パラメータの説明:
-
jh.instance.url: Jihu GitLab プライベート デプロイメント インスタンス アドレス。 -
username：Jihu GitLab ユーザー名; -
component-project:コンポーネントウェアハウス名。
上記のコンポーネントはウェアハウスのルート ディレクトリにあり、 component-job-build-image ジョブがあります。
コンポーネントへの参照
上記で公開されたコンポーネントを他のパイプラインで参照する場合は、 .gitlab-ci.yml 次の構文を使用して参照します。
include:
- component: jh.instance.url/username/component-project@main
inputs:
stage: build
image: docker:latest
tags: cicd
image_tag: 2.0.0
stages: [build]
注意すべき点は次のとおりです。
-
includeコンポーネントのパス (つまり、tempate.yml既存のパス)を 完全に記述し、@ を使用してコンポーネントのどのバージョンが参照されているかを明確にします (ブランチ、コミット ハッシュ、タグなどで表すことができます)。 -
inputs特定のパラメータを に記述します。
component-job-build-image jobCI/CD パイプラインをトリガーすると、実行が成功したことがわかります 。
dind 同様に、ビルド方法 を変更したい場合も kaniko、上記のコンポーネントの内容を置き換える必要はなく、kaniko をテーマにしたコンポーネントを再度公開するだけで済みます。
template.yml これを実現するには、コンポーネント ウェアハウスの別のディレクトリ (ルート ディレクトリにコンポーネントがすでに dind 存在することを示すタグに配置するなど、さまざまな方法があります。 ; たとえば、上記のコンポーネントの場合、メイン ブランチは dind コンポーネントを表し、その後、 kaniko kaniko に対応するコンポーネントを格納する新しいブランチを作成し、最後に .gitlab-ci.yml 参照するときにブランチを指定できます。
include:
- component: jh-jhma.gitlab.cn/cicd-component/cicd-component-demo@kaniko
inputs:
stage: build
image: gcr.io/kaniko-project/executor:debug
tags: cicd
image_tag: 2.0.0
stages: [build]
もちろん、画像も元の画像から
dind変更する 必要がありますが、 パラメータkinakoを変更するだけです 。inputs
CI/CD パイプラインを実行しても同じ結果が得られます。
コンポーネントの導入により、GitLab CI/CD の新しいパラダイムが始まりました。ユーザーの貢献を通じて CI/CD パイプラインの信頼できる単一ソースを作成するこのアプローチは、ユーザーが完全なパイプラインを構築する際に非常に役立ち、CI/CD パイプラインの構築をスピードアップするだけでなく、ユーザーのコストも大幅に削減します。複雑な YAML 構文を学習します。
上記で示したコードはすべて Jihu GitLab 民営化デプロイメント インスタンスに保存されており、アドレスは https://jh-jhma.gitlab.cn/cicd-componentです。
効率的な CI/CD 構築ツール「Runner」
Runner は GitLab CI の重要なコンポーネントであり、CI/CD パイプラインで定義されたジョブの実行に役立ちます。開発者がコード変更を送信すると、Jihu GitLab は、 .gitlab-ci.yml 定義されたパイプライン ステップに従って、変更されたコードの構築、テスト、デプロイメントなどを完了するようにランナーに「通知」します。このプロセス中、ランナーは選択されたエグゼキュータ (たとえば、 PowerShell のシェル)、コンテナーの docker など) を使用して、さまざまな環境でジョブを実行します。実行者の選択については、 Jihu GitLab Executor Networkを参照してください。
Runner は、「サーバー」側 (Jihu GitLab インスタンス) からのリクエストを受け取る「エージェント」のようなものであるため、さまざまなシナリオのニーズを満たすために、Runner はさまざまな OS およびさまざまな CPU 上でさまざまなインストール方法で実行できる必要があります。建築。
独占 + 共有、より柔軟な選択肢
ランナーは、独自のものと共有のものの 2 つのカテゴリに分類されます。
-
独自: ランナーが指定されたプロジェクトにのみ使用され、通常はプロジェクトの一部の情報 (ランナー登録トークン) を使用してランナーを対応するプロジェクトに登録することを意味します。
-
共有: ランナーが GitLab インスタンス全体のものであることを意味します。つまり、インスタンス全体の下にあるすべてのプロジェクトがこれらのランナーを使用できます。その使用方法、誰が最初に使用し、誰が後で使用するかについては、 GitLab の内部スケジューリング メカニズム。
独自のランナーの最大の利点は次のとおりです。
-
時間の節約: 専用ランナーは対応するプロジェクトの CI/CD パイプラインのみを実行するため、共有ランナーが CI/CD パイプラインを実行するまでキューに並んで待つ必要はありません。プロジェクトとパイプラインの数が増えると、キューに並ぶ必要がなくなります。かなり時間がかかります。
-
自律的かつ制御可能: 独自のランナーは、ユーザーが制御可能なサーバー上にユーザーによってインストールされます。使用中に、パイプライン プロセスをデバッグしたり、ランナー構成を変更したり、実行中のプロセス中にデータを取得したりする場合にも使用できます。 、対応するランナーに直接ログインして操作を実行できます。
独自ランナーの構成情報
ランナーを共有する利点も明白です。ユーザーはランナーについて多くの情報を知る必要がなく、またランナーを自分でインストールして操作する必要もありません。比較的トラブルの少ない方法です。
したがって、ユーザーは自分のニーズに応じてさまざまなランナー メソッドを選択し、対応する CI/CD パイプライン操作を完了できます。
容量を動的に拡大および縮小してリソースの使用率を向上させる
Runner は、クラウド リソースの動的スケーリング機能に密接にバインドされて、Runner の動的スケーリングを実現できます: CI/CD パイプラインを実行する必要がある場合、Runner は一部のリソース (CPU、メモリなど) を使用してすべてのジョブを実行します。 CI/CD パイプライン 操作の終了後 (成功または失敗)、対応するリソースが解放され、環境が復元されます。
たとえば、コンテナを使用して Runner を実行できます。最も一般的な方法は、Kubernetes を使用して Jihu GitLab Runner を実行することです。
CI/CD を実行すると、Kubernetes は動的にポッドを作成し、そのポッドは .gitlab-ci.yml ファイルに記述されているステージと対応するイメージに基づいて対応するコンテナを生成します (すべてのコンテナは 1 つのポッド内にあり、ポッドの内部リソースを共有します)。パイプラインのコンテナ内では、パイプラインが終了するとポッドが削除され、操作中に必要なデータとリソースが解放されます。
さらに、クラウド ベンダーが提供するサーバーレス製品を使用して、ランナーの容量を動的に拡張し、リソースの使用率を向上させることもできます。
コンプライアンス組立ライン。組立ラインの安全かつコンプライアンスに準拠した使用を支援します。
パイプラインの使用中に遭遇するシナリオもあります: 特定のプロセスでは、すべてのプロジェクト パイプラインの実行が必要です。たとえば、イメージ セキュリティ スキャンはイメージ ビルドの最後に実行する必要があります。セキュリティの脆弱性がある場合、パイプラインを終了する必要があります。この場合の解決策は、多くの include 場合、すべてのプロジェクトのパイプラインにコンテナー イメージのスキャン リンクを追加することですが、プロジェクトの数が増えると (数百、さらには数千)、これは膨大な量の作業の重複を意味し、操作を行うことができなくなります。精度が保証されます。
そして、適切な解決策はコンプライアンス パイプラインです。
コンプライアンス パイプラインは、GitLab CI/CD パイプラインに組み込まれたセキュリティ機能であり、主にグループ内のすべてのプロジェクトが指定されたコンプライアンス ジョブを実行できることを保証します。グループ レベルでコンプライアンス フレームワークを構成し、各プロジェクトで実行する必要があるコンプライアンス パイプライン ジョブを選択すると、このグループの下にあるすべてのプロジェクト (このグループの下に新しく作成されたプロジェクトも含む) でこのコンプライアンス ジョブが実行されます。プロジェクトもデフォルトでこのコンプライアンス ジョブを実行します。
コンプライアンス パイプラインを使用するには、まずグループ レベルでコンプライアンス フレームワークを構成する必要があります。[グループ] → [設定] → [一般] → [コンプライアンス フレームワーク]で、 [新しいコンプライアンス フレームワーク] を選択し、コンプライアンス フレームワークの名前、説明、コンプライアンス パイプラインの構成 (つまり、コンプライアンス パイプラインの保存場所) を入力し、最後に背景色を選択します。
このコンプライアンス フレームワークがグループのデフォルトのコンプライアンス フレームワークとして設定されている場合、このグループ内のすべての新しいプロジェクトはデフォルトでこのコンプライアンス フレームワークを使用し、デフォルトでこのコンプライアンス パイプラインを実行し、プロジェクト ページにコンプライアンス フレームワークのラベルが表示されます。 。
次に、このグループの下のプロジェクト (Compliance-Pipeline など) にコンプライアンス パイプラインを書き込む必要があります。コンテナー イメージの構築とスキャン パイプラインを例として、 .gitlab-ci.yml 次の内容をファイルに書き込みます。
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
- template: Security/Container-Scanning.gitlab-ci.yml
後続のすべての新しいプロジェクトは、プロジェクト独自のパイプラインではなく、コンテナー イメージの構築とコンテナー イメージのスキャンを実行します。
プロジェクト独自のパイプラインを実行したい場合は、コンプライアンス パイプラインのコンテンツをプロジェクト独自のパイプラインのコンテンツとマージするだけです。たとえば、組み込みパイプラインは、パッケージ化されたコンテナー イメージの改ざんを防ぐために、cosgin を使用して署名および検証する必要があります。
stages:
- singature
- verfication
image-singature:
stage: singature
tags:
- cosign
image:
name: dllhb/cosign:1.0.0
entrypoint: [""]
before_script:
- mkdir ~/.docker
- cat "$DOCKER_CRED_FILE" > ~/.docker/config.json
- cat "$COSIGN_KEY" > /tmp/cosign.key
- export COSIGN_PASSWORD="$COSIGN_PASSWORD"
script:
- cosign sign --key /tmp/cosign.key $CI_REGISTRY_IMAGE:1.0.0
image-verfication:
stage: verfication
tags:
- cosign
image:
name: dllhb/cosign:1.0.0
entrypoint: [""]
before_script:
- cat "$COSIGN_PUB" > /tmp/cosign.pub
- export COSIGN_PASSWORD="$COSIGN_PASSWORD"
script:
- cosign verify --key /tmp/cosign.pub $CI_REGISTRY_IMAGE:1.0.0
上記のパイプラインをコンプライアンス パイプラインに導入する必要があります。
include:
- project: 'Compliance-Pipeline-Group/regular-pipeline'
file: '.gitlab-ci.yml'
最終的には、このグループの他のプロジェクトのパイプラインが、コンテナー イメージのパッケージ化、スキャン、署名、検証の 4 つのステップを実行することになります。
したがって、コンプライアンス フレームワークの選択では、特定のコンプライアンス要件を満たす必要があるプロジェクト、または追加の監督が必要なプロジェクトをマークし、コンプライアンス パイプラインを実行してコンプライアンス作業を完了します。