関連コンテンツ

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

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

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

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

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

ツールチェーンは、 IBM Cloud® Kubernetes Service にアプリケーション Docker イメージをデプロイするための継続的デプロイメント・パイプラインを作成します。 使用したいデプロイメント戦略を選択します。 どのデプロイメント戦略 (ローリング、Blue-Green 、またはカナリア) を選択するかに基づいて、詳細を指定する必要があります。

1. ツールチェーンに使用するデプロイメント・ストラテジーをクリックします。

   

   * 展開戦略

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

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

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

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

ツールチェーンテンプレートは、Mavenビルドを使用するサンプル Java™ Spring Appを提供する。 ツールチェーンの既存のアプリケーション・リポジトリーをリンクする場合は、 独自のアプリの持ち込み を選択し、リポジトリーの 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, でのシークレット管理については、 シークレットを 参照してください。

VPC の詳細の構成

VPC および仮想サーバー・インスタンス (VSI) に関する情報を指定して、ツールチェーンを構成します。

使用するデプロイメント戦略を選択したときに、 IBM Cloud® Schematics と Terraform を使用して VPC と VSI をプロビジョンしました。

• 仮想プライベート・クラウド・リージョン: VPC をプロビジョンしたリージョンを選択します。
• 仮想プライベート・クラウド名: Terraform テンプレートを使用してプロビジョンした VPC を選択します。 オプションには、選択したリージョンで使用可能なすべての VPC が含まれます。
• VPC インスタンスのユーザー名: VPC インスタンスをプロビジョンしたときに構成したユーザー名を指定します。 VPC 内のすべての VSI には、ログインおよびそのインスタンスをデプロイするためのユーザー名と SSH 鍵が必要です。
• Base64 VPC インスタンスのエンコードされた SSH 鍵: VPC インスタンスをプロビジョンしたときに構成した SSH 公開鍵の SSH 秘密鍵を base64-encoded 形式で指定します。

要塞ホストの詳細の構成

Terraform テンプレートは、要塞ホストとして使用する VSI も作成します。 要塞ホストはデプロイメントと保守のタスクを実行するため、 VPC 内の VSI に安全に接続する方法を提供します。 要塞ホストは、VPC の詳細で構成した資格情報 (ユーザー名と SSH 鍵) を使用して、SSH 経由で VSI に接続します。

ツールチェーンでは、VPC 内の VSI にログインしてアプリ・バイナリーをデプロイし、アプリを開始および停止し、サード・パーティー依存関係をダウンロードしてアプリを実行する必要があります。 これらのタスクはすべて、要塞ホストで SSH トンネリングを使用して実行されます。 ツールチェーンは、VSI に接続するために要塞ホストが使用するのと同じ資格情報を使用して要塞ホストにログインします。

• 要塞ホスト: Terraform テンプレートによって要塞ホストとしてプロビジョンされた VSI を選択します。

ロード・バランサーの詳細の構成

VPC 内の VSI にデプロイされたサンプル・アプリは、ポート 8080 に単純な Web ページを表示します。 DNS 名を使用してインターネット上でアプリを使用可能にし、アプリを実行する複数の VSI 間でのトラフィックのロード・バランシングを行うために、Terraform テンプレートは アプリケーション・ロード・バランサーをプロビジョンします。 アプリを実行するすべての VSI は、ロード・バランサーのサーバーのバックエンド・プールを形成します。

ツールチェーンは、ロード・バランサーと 2 つのバックエンド・プールの詳細を使用して、Blue-Green デプロイメント・プロセス中にライブのアプリのトラフィックを構成し、リダイレクトします。 blue のバックエンド・プールと green のバックエンド・プールには、同数の VSI が含まれています。 どの時点においても、一方のプールのみがライブのトラフィックをアクティブに処理し、他方のプールは古いバージョンのアプリを実行することでアイドル状態のままになります。 ロード・バランサーは、各デプロイメントでライブ・トラフィックを処理するバックエンド・プールをスワップまたは切り替えます。 blue のバックエンド・プールが現在アクティブである間、次のデプロイメントでは、green のバックエンド・プール内の VSI にアプリがデプロイされ、blue のバックエンド・プールがパッシブの間、そちらがアクティブになります。

ロード・バランサーに関する情報を指定して、ツールチェーンを構成します:

• ロード・バランサー名: Terraform テンプレートによってプロビジョンされるアプリケーション・ロード・バランサーを選択します。
• Blue バックエンド・プール名: Terraform テンプレートがロード・バランサーにプロビジョンする Blue バックエンド・プールを選択します。
• Green バックエンド・プール名: Terraform テンプレートがロード・バランサーにプロビジョンする Green バックエンド・プールを選択します。

deployment target ステップの詳細が取り込まれたら、次のステップに進みます。

成果物ストレージの構成

ソースに変更を加えると、必ず継続的統合パイプラインがトリガーされます。 継続的な統合が正常に実行されると、ビルド成果物またはバイナリー成果物が作成されて一時ストレージに保存され、ターゲット VSI にデプロイされます。

IBM Cloud Object Storage を使用して、一時ビルド成果物をツールチェーン内に保管できます。 継続的統合パイプラインは、Spring Java アプリのサンプル用の実行可能 .jar ファイルをビルドします。

あるいは、独自の Artifactory インスタンスがある場合は、 Artifactory を使用できます。

パイプラインを探索する

パイプラインを探索すると、ツールチェーンの流れや、各パイプライン内で実行されるさまざまな処理について理解することができます。 作成したばかりのツールチェーンには、以下の 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. 継続的な統合パイプラインが正常に実行されたら、パイプラインの実行をクリックして、完了したステップを探索できます。

パイプラインの実行に失敗があるかどうかの評価では、パイプライン・エバリュエーターがあるパイプラインの最終ステップを確認します。

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

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

このチュートリアルでは、サンプル・アプリを使用して Blue-Green デプロイメント戦略がどのように機能するかを説明します。

Blue-Green デプロイメントを探索します

このチュートリアルで使用する Blue-Green デプロイメント戦略は、 Continuous Delivery サービスでデプロイメント戦略を使用して、VPC 上で実稼働ワークロードを実行する方法を示しています。 継続的デリバリー・パイプラインは、Blue-Green デプロイメントに 3 つのトリガーを提供します。 継続的デリバリー・パイプラインは、以下のいずれかの方法で開始できます:

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

ブルーグリーンデプロイのための継続的デリバリーパイプラインのトリガー

このチュートリアルでは、サンプル・アプリを使用して Blue-Green デプロイメント戦略がどのように機能するかを示します。

1. 継続的デリバリー・パイプラインから手動トリガーを実行して、アプリの最初のバージョンをデプロイします。

   

2. 継続的デリバリー・パイプラインの release ステップ内でアプリ URL を見つけ、その URL をクリックして、アプリが実行されていることを確認します。

   

3. アプリ・コードを更新し、変更をコミットします。 サンプル・アプリ向けに、ウェルカム・メッセージを更新します:

   a. ツールチェーンの「概要」ページの**「リポジトリー」**カードで、サンプル・アプリ・リポジトリーをクリックします。

   b. utils.js ファイル内のウェルカム・メッセージを更新します。

   c. 継続的統合パイプラインの実行が正常に完了するまで待ちます。

4. 継続的デリバリー・パイプラインから手動トリガーを実行し、継続的デリバリー・パイプラインの実行が正常に完了するまで待機します。

5. アプリ URL を再度確認して、更新されたアプリがデプロイされていることを確認します。 両方のアプリ・バージョンが同時に実行されています。 すべてのネットワーク・トラフィックが、更新されたアプリに流れています。

6. 継続的デリバリー・パイプラインから switch-blue-green トリガーを実行して、ロールバックをテストします。 トリガー・パイプラインの切り替えの実行が正常に完了するまで待ちます。

   

   継続的デリバリー・パイプライン・スイッチのトリガーに成功

7. アプリ URL を再度確認して、アプリの前のバージョンが表示されていることを確認します。

トリガーの切り替えを複数回実行して、アプリの前のバージョンと最新バージョンを切り替えることができます。