アプリケーション関連リポジトリー

• インベントリー: このリポジトリーで変更管理を追跡します。 正常に実行された CI パイプライン実行 CD パイプラインごとに、作成された CR 番号という名前の新しいブランチが作成され、デプロイメントの完了後にマスターにマージされます。 例: https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-inventory

• Issue: ここには、ビルドとデプロイメントのプロセスで発生したインシデントについての Issue が保管されます。 例: https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-issues

• エビデンス: ここには、アプリケーションに属するすべての未加工のコンプライアンス・エビデンスが収集されます。 例: https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-evidence

• ツールチェーン: tekton パイプライン定義 (例えば、パイプライン、トリガー、およびリスナー) は、このリポジトリーに保管されます。 例: https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-toolchain

継続的統合ツールチェーンからリポジトリーの名前をキャプチャーした後、 Guided Setup に進み、継続的デプロイメント・ツールチェーンの作成を開始します。 セットアップ・プロセス中に、リポジトリーごとに、CI ツールチェーン用に作成された既存の IBMがホストする Git Repos and Issue Tracking リポジトリーへの URL を指定するか、新規リポジトリーの作成を選択することができます。 現在、ツールチェーンは Git Repos and Issue Tracking リポジトリーの作成のみをサポートしています。 将来のリリースでは、 GitHub、 GitHub Enterprise (GHE)、およびその他の SCM プロバイダーを使用してリポジトリーを作成するためのサポートが提供されます。

インベントリー

ツールチェーンのデフォルトの動作では、 「既存のインベントリーを使用」 を選択して、ツールチェーンの既存のインベントリー・リポジトリーをリンクします。 前述のように、ツールチェーンは現在、既存の Git Repos and Issue Tracking リポジトリーへのリンクのみをサポートしています。

• リポジトリー URL: 「アプリケーション関連リポジトリー」 で取り込まれた、CI ツールチェーンで構成されたインベントリー・リポジトリーの URL。

問題

ツールチェーンのデフォルトの動作では、 「既存の問題リポジトリーを使用」 を選択して、ツールチェーンの既存の問題リポジトリーをリンクします。 前述のように、ツールチェーンは現在、既存の Git Repos and Issue Tracking リポジトリーへのリンクのみをサポートしています。

• リポジトリー URL: 「アプリケーション関連リポジトリー」 で取り込まれた、CI ツールチェーンで構成された問題リポジトリーの URL。

パイプライン構成

リポジトリーには、CD パイプライン (.pipeline-config.yaml) でパイプライン・タスクを実行するためのカスタム・スクリプトが含まれています。 いくつかのデフォルトの構成とスクリプトが含まれている hello-compliance-deployment サンプル・リポジトリーを参照してください。

デフォルトでは、サンプル・リポジトリーからセットアップの 「デプロイメント構成の複製 (Clone deployment configuration)」 が複製されます。 リポジトリーが複製されると、パイプライン実行用の構成およびスクリプトをカスタマイズできます。

• 新規リポジトリー名: デプロイメント構成リポジトリーとしてツールチェーンによって作成される IBMがホストする Git Repos and Issue Tracking リポジトリーの名前。 リポジトリーのリージョンは、ツールチェーンのリージョンと同じです。 新規リポジトリーの固有の名前を選択してください。

既存の継続的デプロイメント・ツールチェーンからのデプロイメント構成リポジトリーがある場合は、 「拡張構成に切り替え (Switch to advanced configuration)」 を選択して、このパイプラインに対して同じ設定を構成します。

秘密

このツールチェーンに含まれているいくつかのツールには、特権リソースにアクセスするためのシークレットが必要です。 IBM Cloud API キーもそのようなシークレットの例の 1 つです。 すべてのシークレットは、シークレット・ボールトに安全に保管し、ツールチェーンの要求に従って参照する必要があります。

IBM Cloud には、機密データを保護してシークレットを一元管理するために役立つシークレット管理オファリングとデータ保護オファリングが豊富に用意されています。 「シークレット」ステップでは、ツールチェーンに追加するシークレット・ボールト統合を指定します。 IBM Cloud シークレットの管理の説明に従って、表示されているトグルを使用して、適宜、ボールト統合を追加または削除してください。 この資料では、前提条件と、規定されたシークレット名 (ヒントとも呼ばれます) のリストの使用方法に関する情報を提供します。テンプレートでヒントを使用すると、事前構成されたシークレットをツールチェーンに自動的に取り込めるので、ツールチェーンに接続したさまざまなボールト統合から手動でシークレットを選択する必要がありません。

この資料では、シークレットのボールトとして IBM Secrets Manager を使用します。

IBM Key Protect

Key Protect を使用して、ツールチェーンの一部である API キー、イメージ・シグニチャー、 HashiCorp Vault 資格情報などの秘密を安全に保管して適用します。 先に進む前に、 Key Protect サービス・インスタンスを作成する必要があります。 Key Protect サービス・インスタンスを既に作成している場合は、このステップで同じものをリンクできます。

• 名前: ツールチェーンで作成される Key Protect インスタンスの名前。 この鍵保護インスタンスには、ツールチェーン・セットアップのさまざまな段階でこの名前でアクセスできます。
• リージョン: Key Protect サービスが配置されているリージョン。
• リソース・グループ: Key Protect サービスが属するリソース・グループ。
• サービス名: Key Protect サービス名。

HashiCorp Vault の使用に関するベスト・プラクティスに準拠するために、このテンプレートには、 HashiCorp Vault Role ID および Secret ID を安全に管理するための Key Protect ツール統合が含まれています。 ユーザーがツールチェーンを作成するための前提条件として、これらの HashiCorp Vault シークレットを Key Protect に保管することで、 HashiCorp Vault へのアクセスを保護します。これは、ほとんどのコンシューマーのデフォルトのシークレット・リポジトリーです。

IBM Cloud Secrets Manager

Secrets Manager を使用して、ツールチェーンの一部である API キー、イメージ・シグニチャー、または HashiCorp Vault 資格情報などの秘密を安全に保管して適用します。 先に進む前に、 Secrets Manager サービス・インスタンスを作成する必要があります。 前提条件として既に Secrets Manager サービス・インスタンスを作成している場合は、このステップで同じサービス・インスタンスをリンクできます。

• 名前: ツールチェーンで作成される Secrets Manager インスタンスの名前。 この Secrets Manager インスタンスには、ツールチェーン・セットアップのさまざまな段階でこの名前でアクセスできます。
• リージョン: Secrets Manager サービスが配置されているリージョン。
• リソース・グループ: Secrets Manager サービスが属するリソース・グループ。
• サービス名: Secrets Manager サービス名。

HashiCorp Vault

HashiCorp Vault を使用して、ツールチェーンに必要なシークレットを安全に保管してください。 シークレットの例としては、API キー、パスワード、または機密情報へのアクセスを可能にするその他のトークンがあります。 ツールチェーンには、シークレット・ローテーションなどの拡張機能を有効にするリテラル・シークレット値ではなく、 HashiCorp Vault シークレットへの参照が保管されます。

• 名前: このツール統合の名前。 この名前はツールチェーンに表示されます。
• サーバー URL: HashiCorp Vault インスタンスのサーバー URL。 (例: https://192.168.0.100:8200)
• 統合 URL: HashiCorp Vault 統合タイルをクリックした時のナビゲート先の URL。
• シークレット・パス: HashiCorp Vault インスタンスでシークレットが保管されるマウント・パス。
• 認証方式: HashiCorp Vault インスタンスの認証方式。
• 役割 ID: チームの AppRole 役割 ID。
• シークレット ID: チームの シークレット ID。

AppRole 認証方式を使用して、秘密値を読み取ることができます。

エビデンス・ストレージ

このリポジトリーには、アプリケーションに属するすべての未加工のコンプライアンス・エビデンスが収集されます。 このリポジトリー・オプションは、評価目的でのみ使用してください。

ツールチェーンのデフォルトの動作は、 「既存のエビデンス・ロッカーを使用」 です。 「リポジトリー URL」 フィールドには、CI ツールチェーン用に作成/使用されたエビデンス・リポジトリー URL を設定できます。 ツールチェーン用にエビデンス・ロッカーを作成する場合は、 「新規エビデンス・ロッカー・リポジトリーの作成」 を選択します。これにより、 IBMがホストする Git Repos and Issue Tracking リポジトリーとして新規リポジトリーが作成されます。

ただし、 Cloud Object Storage バケット の説明に従って構成できる Cloud Object Storage バケットにすべての証拠を収集して保管する必要があります。

エビデンス

• リポジトリー URL: アプリケーション関連リポジトリー で取り込まれた、CI ツールチェーンで構成されたエビデンス・ロッカー・リポジトリーの URL。

Cloud Object Storage バケット

Cloud Object Storage は、コンプライアンス・パイプラインによって生成された証拠と成果物を保管するために使用されます。 この機能を使用するには、Cloud Object Storage インスタンスとバケットが必要です。 詳しくは、ここにある手順を参照してください。

どのタイプの Cloud Object Storage バケットでもロッカーとして設定できます。保存ポリシーなしの設定も可能です。 現時点では、パイプラインによって設定が検査されたり強制されたりすることはありません。

ヘルプ情報については、Cloud Object Storage の資料を参照してください。

パイプラインからバケットに到達できるように、以下の情報を指定する必要があります。

• Cloud Object Storage エンドポイント
• バケット名
• サービス API キー

必要な cos-bucket-name と cos-endpoint を指定することにより、後で Cloud Object Storage ロッカーをセットアップできます。

Cloud Object Storage エンドポイントを取得するには、 Cloud Object Storage インスタンスのページに移動し、メニューの 「エンドポイント」 セクションを選択します。 バケットの リージョン および resiliency に一致するパブリック・エンドポイント、プライム・エンドポイント、またはダイレクト・エンドポイントをコピーします。

Cloud Object Storage をエビデンス・ロッカーとして使用しないことにした場合でも、CI パイプラインで環境変数 cos-bucket-name と cos-endpoint を設定することで、ツールチェーンの作成後にも必要な値を設定することが可能です。

• リポジトリー URL: 「アプリケーション関連リポジトリー」 で取り込まれた、CI ツールチェーンに構成されている Tekton パイプライン定義リポジトリーの URL。

パイプライン・リポジトリーは、CI ツールチェーンと CD ツールチェーンの両方の構成が格納されるので、この 2 つのツールチェーンで同じものが使用されるようにすることができます。 CD Toolchain Tekton 定義に別個のパイプライン定義を使用する場合は、 「拡張構成への切り替え (Switch to advanced configuration)」 トグルを使用してリポジトリーを複製します。

デプロイ

アプリケーションをデプロイするターゲットの Kubernetes クラスターを構成します。 実稼働環境またはステージ環境として使用するターゲット Kubernetes クラスターを選択してください。 ツールチェーンによってビルド・アプリケーション・イメージがクラスターにデプロイされ、受け入れテストや他のコンプライアンス検査が実行されます。

IBM Cloud API キー

API キーは、いくつかのタスクで ibmcloud CLI ツールと対話するために使用されます。 クラスターを作成し、クラスターにアクセスするための API を作成し、セキュア・ボールト ( Key Protect、 Secrets Manager、または HashiCorp Vault のいずれか) に鍵を保管した場合は、前提条件としてこのステップで同じものを使用できます。

- Option-1: An existing key can be imported from an existing Secret Provider intance created as prerequisites (Key Protect Instance, Secret Manager Instance or HashiCorp Vault) by clicking the key icon (Recommended)
- Option-2: An existing key can be copy & pasted (Not Recommended)
- Option-3: A new key can be created from here by clicking **New +**. Generate a new api-key if you don’t have one or copy an existing key to the field.The newly generated API key can be immediately saved to an existing Key Protect instance

シークレット・プロバイダーの既存の鍵を使用するには、 「鍵」 アイコンをクリックします。

• プロバイダー: 先ほどツールチェーンにリンクした、クラスターにアクセスするための API キーを保管するシークレット・プロバイダー。 Key Protect インスタンス、Secret Manager インスタンス、または Hashicorp Vault インスタンスにすることができます。
• リソース・グループ: Secrets Manager プロバイダーが属するリソース・グループ。
• シークレット名: シークレットの名前または別名、つまり API キー。

「API キー」フィールドに入力すると、レジストリーおよびクラスター関連のフィールドが自動的に入力されます。

インベントリーのターゲット・ブランチとソース・ブランチ

• インベントリー・ソース環境 (Inventory Source Environment): アプリケーションのプロモート元の環境。 デフォルト：master

• インベントリー・ターゲット環境 (Inventory Target Environment): アプリケーションをデプロイする先の環境。 デフォルト：prod

• ターゲット・リージョン: アプリケーションのデプロイ先のターゲット・リージョン (オプション)。

• 変更要求の PR と問題のための緊急ラベル (Emergency Label for change request PRs and issues): 緊急デプロイメントのために使用する変更要求のラベル。

変更要求管理

IBM Cloud がホストする Git Repos and Issue Tracking リポジトリーを選択して、変更要求を管理できます。

Git Repos and Issue Tracking

• 新規リポジトリー名: 変更要求管理に使用される Git Repos and Issue Tracking リポジトリーの名前。

ツールチェーンのデフォルトの動作は、 IBMがホストする Git Repos and Issue Tracking リポジトリーとして新しい変更要求管理リポジトリーを作成する デフォルトの Git Repos and Issue Tracking 変更要求管理リポジトリーの使用 です。 新規リポジトリーの固有の名前を選択してください。

既存の CD ツールチェーンから既存の変更要求リポジトリーがある場合は、 「拡張構成への切り替え (Switch to advanced configuration)」 トグルを使用して、このパイプラインに対して同じリポジトリーを構成します。

既存の DevOps Insights ツールチェーンへのリンク

CI ツールチェーンの作成時に、DevOps Insights のインスタンスを既に作成しました。 CD ツールチェーンでも同じことを参照する必要があります。 各準拠性検査の証拠が公開されると、ツールチェーンはデプロイメント・レコードを DevOps 洞察に公開します。 統合 ID を指定して CI ツールチェーンの DevOps Insights 統合をリンクすることで、すべてのデプロイメント・データを 1 つの DevOps Insight インスタンスに統合できます。

ツールチェーン ID はツールチェーンの URL からコピーできます。 ツールチェーンの URL は、 https://cloud.ibm.com/devops/toolchains/<toolchain-ID-comes-here>?env_id=ibm:yp:us-south というパターンに従います。

例えば、URL が https://cloud.ibm.com/devops/toolchains/aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee?env_id=ibm:yp:us-south の場合、ツールチェーンの ID は aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee です。

ここには、URL 全体ではなく ID だけを指定してください。

DOI 対話のターゲット環境を設定することもできます。 このパラメーターはオプションです。 このパラメーターを指定すると、インベントリーのターゲット環境の代わりに使用されます。

オプションのツール

Slack

CD パイプラインのイベントに関する通知を受け取りたい場合は、セットアップ時にツールチェーン・テンプレートから Slack ツールを構成することができます。またはセットアップの後に Slack ツールを追加することができます。

Slack チャネルでツールからの通知を受け取るためには、Slack の Web フック URL が必要です。 Web フック URL を取得するには、Slack API Web サイトの着信 Web フックのセクションを参照してください。

ツールチェーンを作成した後、CD パイプラインで slack-notifications 環境プロパティーを使用して通知の送信を切り替えることができます (0 = オフ、1 = オン)。

共通の DevOps Insights を使用するツールチェーン

オプションで、作成されたツールチェーンに DevOps Insights を組み込み、コンプライアンス検査のたびにその完了後にエビデンスが DevOps Insightsにパブリッシュされるようにすることができます。 ツールチェーンは、既存の DevOps Insights インスタンスを使用して、デプロイメント・レコードを洞察に公開できます。 統合 ID を指定して CI ツールチェーンの DevOps Insights 統合をリンクすることで、すべてのデプロイメント・データを 1 つの DevOps Insight インスタンスに統合できます。

ツールチェーン ID はツールチェーンの URL からコピーできます。 ツールチェーンの URL は、 https://cloud.ibm.com/devops/toolchains/<toolchain-ID>?env_id=ibm:yp:us-south というパターンに従います。

例えば、URL が https://cloud.ibm.com/devops/toolchains/aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee?env_id=ibm:yp:us-south であれば、ツールチェーンの ID は aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee です。

完全な URL ではなく、ID のみを含めるようにしてください。

また、DOI 対話用にオプションのターゲット環境を設定することもできます。 このパラメーターを指定すると、インベントリーのターゲット環境の代わりに使用されます。

セキュリティーおよびコンプライアンス

ツールチェーンを Security and Compliance Service と統合するには、Security and Compliance データ・コレクターの名前とエビデンス・ロッカー・リポジトリー名を指定する必要があります。

Security and Compliance Center および ツール統合 の構成プロセスについて詳しく説明します。

プライベート・ワーカー

Delivery Pipeline プライベート・ワーカー・ツール統合は、 Delivery Pipeline ワークロードを単独で実行できる 1 つ以上のプライベート・ワーカーに接続します。 詳しくは、プライベート・ワーカーの操作を参照してください。

プロモーション・パイプラインの実行

• プロモーション・パイプラインを実行する前に CI パイプラインが正常に実行したことを確認してください。
• プロモーション・パイプラインは、インベントリー・ターゲット環境のブランチ (例: staging や prod) をターゲットとして、インベントリー・ソース環境のブランチ (例: master) のインベントリーの内容についてのプル要求を作成します。 その PR 用に中間ブランチが作成されます。PR がマージされたら、これは廃棄することができます。

Promotion Pipeline が正常に終了すると、 promote タスクはインベントリー・リポジトリー内の Pull Request へのリンクを提供します。 プル要求名の形式は promote <Inventory Source Environment> to <Inventory Target Environment> です。

1. ログに記録されているリンクを使用して、ブラウザーでPull Requestを開きます。 以下のセクションで詳細を入力します。
   • 優先度 (Priority): (必須) 重大 (Critical)、高 (High)、中 (Moderate)、低 (Low)、計画 (Planning) のいずれか
   • 変更要求の受託者 (Change Request assignee): (必須) 受託者の E メール ID
   • 追加の説明 (Additional Description): アプリケーションの変更内容に関する説明
   • 目的 (Purpose): アプリケーションに対して行われた変更の目的
   • 影響の説明 (Explanation of Impact): アプリケーションの動作や環境への変更の影響
   • バックアウト計画: デプロイメントが失敗した場合にバックアウトするステップ
2. Pull Requestの各フィールドに値を入力して、saveします。
3. CI でコンプライアンス検査に失格した場合にデプロイメントを続行するには、PR にEMERGENCYラベルを付けます。
4. Git Repos and Issue Trackingから Pull Request をマージします。

このPull Requestの詳細が、CD パイプラインの実行中に、CD パイプラインで変更要求管理リポジトリーに変更要求を作成するときに使用されます。

プロモーション・パイプラインの実行

1. Promotion Pipeline を実行する前に、CI パイプラインが正常に実行されたことを確認します。
2. Promotion Pipeline は、在庫ソース環境 (例: master) ブランチ上の在庫の内容を使用して、在庫ターゲット環境ブランチ (例: staging または prod) をターゲットとする Pull Request を作成します。 その PR 用に中間ブランチが作成されます。PR がマージされたら、これは廃棄することができます。

1. Promotion Pipeline が正常に終了すると、 promote タスクによって、インベントリー・リポジトリー内の前述の Pull Request へのリンクが提供されます。 プル要求名の形式は以下のとおりです。

promote <Inventory Source Environment> to <Inventory Target Environment>

1. ログに記録されているリンクを使用して、ブラウザーでPull Requestを開きます。 以下のようにセクションを完成させます。

   • 優先度 (Priority): (必須) 重大 (Critical)、高 (High)、中 (Moderate)、低 (Low)、計画 (Planning) のいずれか
   • 変更要求の受託者 (Change Request assignee): (必須) 受託者の E メール ID
   • 追加の説明 (Additional Description): アプリケーションの変更内容に関する説明
   • 目的 (Purpose): アプリケーションに対して行われた変更の目的
   • 影響の説明 (Explanation of Impact): アプリケーションの動作や環境への変更の影響
   • バックアウト計画: デプロイメントが失敗した場合にバックアウトするステップ

2. Pull Requestの各フィールドに値を入力して、保存します。

3. Git Repos and Issue Trackingから Pull Request をマージします。

このPull Requestの詳細が、CD パイプラインの実行中に、CD パイプラインで変更要求管理リポジトリーに変更要求を作成するときに使用されます。

CD パイプラインの実行

以下のどちらの方法でも CD パイプラインを開始することができます。

• CD パイプラインを手動でトリガーする。
• インベントリー・リポジトリーでMerge操作を実行するたびに自動的に開始する。 このマージの後は、CD パイプラインの実行を手動でトリガーする必要があります。 Git Repos and Issue Tracking トリガーは、自動 CD パイプラインをトリガーするようにセットアップされていますが、デフォルトでは無効になっており、最初のプロモーション後に有効にすることができます。

また、いつでも CD Pipelineを手動でトリガーできますが、最後にデプロイメントが正常に実行された後に変更が行われていなければ、CD pipelineで新たにデプロイされるものは何もありません。

CD パイプラインの正常実行は次のようになります。

CD パイプラインのタスクのフロー:

CD パイプラインが正常に実行されると、prod 名前空間で実行されているサンプル・アプリを見つけることができます。 アプリの URL が、CD パイプライン実行の run stage ステップの prod deployment サブステップに表示されます。 その URL を使用して、アプリが稼働中であることを確認できます。