Red Hat Trusted Application Pipeline のカスタマイズ
デフォルトのソフトウェアテンプレートとビルドパイプライン設定をカスタマイズする方法を説明します。
概要
はじめに
RHTAP は、すぐに使用できるソフトウェアテンプレートとビルドパイプライン設定によってチームを支援します。これらのツールは、開発プロセスにセキュリティープラクティスをシームレスに統合するように設計されています。これらのツールは、セキュリティーに関する考慮事項に関連する開発者の負担を軽減するだけでなく、開発者がイノベーションに集中できるようにします。
クラスター管理者は、オンプレミス環境の独自の要件に合わせてこれらのリソースを調整する上で重要な役割を果たします。調整の例は以下のとおりです。
- 特定の組織のニーズに合わせたソフトウェアテンプレートのカスタマイズ
- プロジェクトの目標に合わせたビルドパイプライン設定の変更
- 自動化されたパイプライントリガー用の GitLab Webhook の設定
このようなカスタマイズにより開発ワークフローが合理化され、パイプライン、脆弱性、ポリシーコンプライアンスに関する一般的な懸念に対処できるため、開発者はコーディングを優先できます。
第1章 サンプルソフトウェアテンプレートのカスタマイズ
すぐに使用できるソフトウェアテンプレートをオンプレミス環境向けにカスタマイズする方法を説明します。クラスター管理者は、メタデータや仕様の変更を含め、このプロセスを完全に制御できます。
前提条件
- RHTAP インストールプロセス中に、tssc-sample-templates からフォークされたリポジトリー URL を使用した。
手順
- フォークされたリポジトリーを複製し、Visual Studio Code などの任意のテキストエディターで開きます。
プロジェクトディレクトリー内で プロパティー ファイルを見つけます。このファイルにはカスタマイズ可能なデフォルト値が保存されています。ファイルを編集するために開き、環境に応じて次のキーと値のペアを更新します。
キー 説明 export GITHUB_DEFAULT_HOST
このキーは、オンプレミスの GitHub ホストの完全修飾ドメイン名に設定します。つまり、
HTTP
プロトコルと.git
拡張子を除外した URL です。たとえば、ithub-github.apps.cluster-ljg9z.sandbox219.opentlc.com です。デフォルトはgithub.com
です。export GITLAB_DEFAULT_HOST
このキーは、オンプレミスの GitLab ホストの完全修飾ドメイン名に設定します。つまり、
HTTP
プロトコルと.git
拡張子を除外した URL です。たとえば、gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com です。デフォルトはgitlab.com
です。export QUAY_DEFAULT_HOST
デフォルトの Quay URL は、
HTTP
プロトコルを除外した、特定のオンプレミスのイメージレジストリー URL に対応します。たとえば、quay-tv2pb.apps.cluster-tv2pb.sandbox1194.opentlc.com などです。デフォルトの quay ホストはquay.io
です。export DEFAULT_DEPLOYMENT_NAMESPACE_PREFIX
RHTAP 内のデプロイメントの名前空間接頭辞です。デフォルトは
rhtap-app
です。注記RHTAP インストールプロセス中にデフォルトの
trusted-application-pipeline: namespace
を変更した場合は、これを更新してください。図1.1 プロパティーファイル
ターミナルで generate.sh スクリプトを実行します。このアクションにより、ソフトウェアテンプレートが調整され、デフォルトのホスト値が指定した入力値に置き換わります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./generate.sh
./generate.sh
図1.2 generate.sh スクリプト
変更をコミットしてリポジトリーにプッシュします。これにより、RHDH のテンプレートが自動的に更新されます。あるいは、カスタマイズしたテンプレートの 1 つまたはすべてを RHDH に直接インポートして更新することもできます。
- Git プロバイダーのフォークされたサンプルテンプレートリポジトリーに移動します。
-
単一のテンプレートの場合は、
templates
ディレクトリーからtemplate.yaml
を選択します。ブラウザーのアドレスバーから URL をコピーします。たとえば、https://github.com/<username>/tssc-sample-templates/blob/main/templates/devfile-sample-code-with-quarkus-dance/template.yaml です。すべてのテンプレートの場合は、all.yaml
を選択し、ブラウザーのアドレスバーからその URL をコピーします。たとえば、https://github.com/<username>/tssc-sample-templates/blob/main/all.yaml です。 - RHDH プラットフォームに戻ります。
- Create > Register Existing Component を選択します。
- Select URL フィールドに、手順 4b でコピーした適切な URL を貼り付けます。
- Analyze を選択し、Import を選択して RHDH のテンプレートを更新します。
検証
- テンプレートのカスタマイズによる影響を調べるアプリケーションの作成を検討してください。
関連情報
- パイプラインをカスタマイズするには、サンプルパイプラインテンプレートのカスタマイズ を参照してください。
第2章 サンプルパイプラインのカスタマイズ
サンプルテンプレートリポジトリー内の Pipeline as Code (pac
) URL を更新し、サンプルパイプラインリポジトリーをワークフローに合わせてカスタマイズする方法を説明します。pac
URL をカスタマイズすることで、組織はニーズに合わせて特定のパイプラインを活用できます。
前提条件
次のテンプレートがすでにローカルでフォークおよび複製されている。
サンプルテンプレートリポジトリーをカスタマイズして pac
URL を更新する*
手順
フォークされたサンプルパイプラインリポジトリーの URL にアクセスします。
- フォークされたサンプルパイプラインリポジトリーを開きます。
- アドレスバーから完全な URL をコピーします。たとえば、https://github.com/<username>/tssc-sample-pipelines です。
サンプルテンプレートリポジトリーの
pac
URL を更新します。- ターミナルを使用して、ローカルに複製されたサンプルテンプレートリポジトリーに移動します。
- 次のコマンドを実行します。{fork_url} は手順 1 でコピーした URL に置き換え、{branch_name} は目的のブランチ名 (main など) に置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ./scripts/update-tekton-definition {fork_url} {branch_name} # For example, .scripts/update-tekton-definition https://github.com/<username>/tssc-sample-pipelines main
./scripts/update-tekton-definition {fork_url} {branch_name} # For example, .scripts/update-tekton-definition https://github.com/<username>/tssc-sample-pipelines main
変更を確認し、コミットしてプッシュします。
- サンプルテンプレートリポジトリー内の更新したファイルを確認します。
- 適切なメッセージとともに変更をコミットします。
- コミットした変更を、フォークされたリポジトリーにプッシュします。
サンプルパイプラインリポジトリーをワークフローに合わせてカスタマイズする
サンプルパイプラインリポジトリーは、組織固有の CI/CD ワークフローをビルドするための基盤を提供します。サンプルパイプラインリポジトリーでは、pac
ディレクトリーにいくつかの主要なパイプラインテンプレートが含まれています。
-
gitops-repo
: このディレクトリーには、GitOps リポジトリー内のプルリクエストを検証するためのパイプライン定義が保存されます。これは、pipelines
ディレクトリーにあるgitops-pull-request
パイプラインをトリガーし、イメージの更新が組織の標準に準拠していることを検証します。開発からステージング、ステージングから実稼働環境など、アプリケーションのデプロイメント状態を環境間で順に進めるプロモーションワークフローにおいて、このセットアップは重要です。gitops-repo
のパイプライン定義の詳細は、Gitops Pipelines を参照してください。 -
pipelines
: このディレクトリーには、gitops-repo
とsource-repo
の両方のイベントハンドラーが参照するビルドおよび検証パイプラインの実装が格納されます。このディレクトリーの内容を調べることで、パイプラインが実行する特定のアクションや、パイプラインがアプリケーションのセキュアなプロモーションおよびデプロイメントに貢献する方法を理解できます。 -
source-repo
: このディレクトリーは、Dockerfile ベースのセキュアなサプライチェーンソフトウェアのビルドに特化しています。このディレクトリーには、ソースを複製し、アーティファクトを生成および署名し (イメージ署名の.sig
、アテステーションの.att
、Software Bill of Materials の.sbom
など)、これらをユーザーのイメージレジストリーにプッシュするためのパイプライン定義が含まれます。source-repo
のパイプライン定義の詳細は、Shared Git resolver model for shared pipeline and tasks を参照してください。 -
tasks
: このディレクトリーには、組織のニーズに合わせて追加または変更できるタスクのコレクションが格納されます。たとえば、Advanced Cluster Security (ACS) タスクを代替のチェックに置き換えたり、まったく新しいタスクをパイプラインに統合して機能とコンプライアンスを強化したりできます。
検証
- テンプレートおよびパイプラインのカスタマイズによる影響を調べるアプリケーションの作成を検討してください。
関連情報
- テンプレートをカスタマイズするには、サンプルソフトウェアテンプレートのカスタマイズ を参照してください。
- Pipeline as code の詳細は、Pipelines as Code について を参照してください。
第3章 自動化されたパイプライントリガー用の GitLab Webhook の設定
GitLab で Webhook とシークレットを設定して、コードの更新時に RHDH でパイプラインの実行を自動的にトリガーする方法を説明します。
前提条件
- 既存の GitLab プロジェクトがある。
- OpenShift Web コンソールの 管理者権限 がある。
手順
Webhook URL とシークレットトークンを取得します。
- 管理者権限で OpenShift Web コンソール にログインします。
-
rhtap
プロジェクトに移動し、Pipelines を展開して、PipelineRuns を選択します。 -
rhtap-pe-info-<>
パイプラインの実行を見つけて、Logs タブを選択します。
注記これらのログには、GitLab 設定に必要な Webhook URL とシークレットトークンが含まれます。
GitLab で Webhook を設定します。
- GitLab リポジトリー内で、Settings > Webhooks に移動します。
- URL フィールドに、手順 1 でコピーした Webhook URL を入力します。
- Secret Token フィールドに、手順 1 でコピーしたシークレットトークンを入力します。
Trigger セクションでは、次の操作を行います。
- Push events を選択します。
- Merge request events を選択します。
- Add Webhook をクリックします。
検証
- コードの変更を GitLab リポジトリーにプッシュします。
- RHDH の CI タブに移動します。
- コードプッシュに対してパイプラインの実行がトリガーされていることを確認します。
改訂日時: 2024-07-16