関連コンテンツ

• Continuous Delivery の概説
• クラスターの概説
• ツールチェーンの概説

ツールチェーン名とリージョンの構成

ツールチェーン設定のデフォルト情報を確認します。 ツールチェーンの名前は、そのツールチェーンを IBM Cloud 内で識別するためのものです。 IBM Cloud の同じリージョン、同じリソース・グループのツールチェーンにおいてツールチェーン名が固有になるようにしてください。

ツールチェーンのリージョンは、クラスターおよびレジストリーのリージョンとは違っていてもかまいません。

デプロイメント戦略の選択

ツールチェーンは Satelliteで定義されているクラスター・グループにアプリケーション Docker イメージをデプロイするための継続的デプロイメント・パイプラインを作成します。

1. Satellite 経由で複数のクラスター をクリックし、 Satellite を使用してアプリをデプロイします。

   

2. 「続行」 をクリックします。

アプリケーション・ソース・コード・リポジトリーの構成

「アプリケーション」ステップでは、アプリケーション・ソース・コード・リポジトリーの推奨オプションがデフォルトで表示されます。 基礎となる Git 統合で使用可能なすべてのオプションを表示するには、 拡張オプションをクリックします。 デフォルトでは、ツールチェーンはサンプル・アプリを IBM がホストする Git Repos and Issue Tracking リポジトリーとして複製するデフォルトのサンプルを使用します。

アプリ・リポジトリーの名前を変更できます。 リポジトリーのリージョンは、ツールチェーンのリージョンと同じままになります。

ツールチェーン・テンプレートは、 Hello Containers アプリケーション アプリを提供します。 ツールチェーンの既存のアプリケーション・リポジトリーをリンクする場合は、 独自のアプリの持ち込み を選択し、リポジトリーの URL を指定します。 ツールチェーンは、既存の Git Repos and Issue Tracking リポジトリーへのリンクのみをサポートします。

デフォルトでは、アプリケーション・リポジトリー・テンプレートは Git Repos and Issue Tracking org に複製されます。 org を変更するには、 拡張オプション を有効にして、リポジトリーの所有者を指定します。

インベントリー・リポジトリーを構成します

インベントリー・リポジトリーは、継続的統合ツールチェーンによってビルドされた成果物の詳細を記録します。 インベントリリポジトリのテンプレートをクローンした新しいインベントリリポジトリを作成するか、ツールチェーン間で共有している既存のインベントリリポジトリを使用することができます。

デフォルトでは、インベントリー・リポジトリー・テンプレートは Git Repos and Issue Tracking org に複製されます。 org (組織) を変更するには、 拡張オプション を選択し、リポジトリー所有者を指定します。

シークレットの安全な保管

このツールチェーン内のいくつかのツールは、 IBM Cloud API キーなどのシークレットを必要とします。 すべてのシークレットをシークレット・ボールトに安全に保管し、ツールチェーンの要求に従ってそれらのシークレットを参照する必要があります。

IBM Cloud を使用して、さまざまなシークレット管理およびデータ保護のオファリングから選択できます。これらのオファリングは、機密データの保護とシークレットの一元化に役立ちます。 「シークレット (Secrets)」ステップでは、ツールチェーンに追加またはツールチェーンから削除するシークレット・ボールト統合を指定できます。 前提条件を含むボールト統合の追加と削除、およびヒント使用の詳細については、 IBM Cloud シークレットの管理を参照してください。

テンプレート内でのヒントの使用により、ツールチェーンには事前構成されたシークレットが自動的に取り込まれます。ツールチェーンに付加されたボールト統合からシークレットを手動で選択する必要はありません。

このチュートリアルでは、 IBM Secrets Manager をシークレット・ボールトとして使用します。

IBM Secrets Manager は、ツールチェーンの一部である API キー、イメージ・シグニチャー、または HashiCorp 資格情報などのシークレットを安全に保管して適用します。

IBM Key Protect または HashiCorp, でのシークレット管理については、 シークレットを 参照してください。

パイプラインを探索する

パイプラインを探索すると、ツールチェーンの流れや、各パイプライン内で実行されるさまざまな処理について理解することができます。 作成したばかりのツールチェーンには、以下の 3 つのパイプラインが含まれています:

• プル・リクエスト・パイプライン: 開発者が開発ブランチからマスター・ブランチ、またはリポジトリー内の他のいずれかのブランチに変更をマージすると実行されます。 プル要求パイプラインは、単体テストおよび静的スキャンをアプリケーション・ソース・コードに対して実行します。
• 継続的統合パイプライン: アプリケーション・ソース・コード・リポジトリーのマスター・ブランチに変更をマージすると実行されます。 継続的統合パイプラインは、アプリケーション・ソース・コード、 CIS チェック、および部品表 (BOM) チェックで単体テスト、コード・カバレッジ、および静的スキャンを実行します。 また、継続的デリバリー・パイプラインは、バイナリー・ビルド成果物を生成し、ツールチェーンで構成されているとおりにそれらを IBM Cloud® Kubernetes Service にアップロードします。 また、継続的統合パイプラインは、ビルド成果物のメタデータを生成し、それをインベントリー・リポジトリーに保管します。
• 継続的デプロイメント・パイプライン: ビルド成果物をデプロイメント環境にデプロイします。 パイプラインは、ヘルス・チェックを実行して、アプリの正常なデプロイメントを検証します。 継続的統合パイプラインが正常に完了した後に、このパイプラインを手動でトリガーする必要があります。 選択したデプロイメント戦略に応じて、継続的デリバリー・パイプラインにさらにトリガーが追加されます。

プル・リクエストと継続的統合パイプラインの実行。

プル・リクエスト・パイプラインを開始するには、アプリ・リポジトリーでマージ・リクエストを作成します:

1. ツールチェーンの「概要」ページの**「リポジトリー」**カードで、compliance-app-<timestamp> アプリ・リポジトリーをクリックします。
2. マスター・リポジトリーから、ブランチを作成します。
3. サンプル・ノード・アプリまたは README ファイルの一部のコードを更新して、これらの変更を保存します。
4. マージ・リクエストを送信します。
5. ツールチェーンの「概要」ページの**「リポジトリー」**カードで、pr-pipeline リポジトリーをクリックしてプル・リクエスト・パイプラインを開始します。 プル・リクエスト・パイプラインのすべてのステージが正常に完了するまで、アプリ・リポジトリー内の対応するマージ要求は保留状態のままになります。
6. プル・リクエスト・パイプラインが正常に実行されたら、それを選択して、完了したステップを探索できます。

継続的統合パイプラインを開始するには、アプリ・リポジトリーに継続的統合マージ・リクエストをマージします:

1. マージ・リクエストに移動します。
2. リクエストをマージして、変更がアプリ・リポジトリーのマスター・ブランチにコピーされるようにします。 継続的統合パイプラインが自動的にトリガーされます。
3. 継続的統合ツールチェーンの「概要」ページの**「リポジトリー」**カードで、ci-pipeline リポジトリーをクリックして継続的統合パイプラインを開始します。
4. 継続的な統合パイプラインが正常に実行されたら、パイプラインの実行をクリックして、完了したステップを探索できます。

継続的デリバリー・パイプラインの詳細はこちら

プル・リクエストと継続的統合パイプラインは、すべてのデプロイメント戦略で共通です。 継続的デリバリー・パイプラインの設計および実装の変更は、このチュートリアルで以前に選択したデプロイメント戦略に基づいています。

継続的デリバリー・パイプラインは、以下のいずれかの方法で開始できます:

• 継続的デリバリー・パイプラインを手動でトリガーします。
• インベントリー・リポジトリー内の各 Merge アクションの後に、継続的デリバリー・パイプラインを自動的にトリガーします。 マージ後に、継続的デリバリー・パイプライン実行を手動でトリガーする必要があります。

Git Repos and Issue Tracking トリガーは、自動継続的デリバリー・パイプラインをトリガーするようにセットアップされていますが、デフォルトでは無効になっています。 初めて変更をプロモートした後で、このトリガーを有効にできます。

{: caption="*継続的デリバリー・パイプラインにおけるローリングデプロイのトリガー