イベント駆動型のクラウド・ネイティブ・アプリケーションを超高速で設計して配信する

概要

ソフトウェア・デリバリー・プロジェクトを成功させるためには、企業のさまざまな分野 (開発、運用、セキュリティー、コンプライアンスなど) 全体での調整が必要になります。IBM Cloud Pak for Applications には、クラウド・ネイティブ・アプリケーションの開発を迅速化するために設計された Accelerators for Teams 機能が用意されています。この機能を使用すれば、さまざまな分野のチームが意思決定を体系化して一元管理し、ビジネス問題を特定して本番アプリケーションを開発するまでのプロセス全体を改善することができます。Accelerators for Teams の背後にある価値提案の詳細と、この革新的なテクノロジーを利用して開発を円滑に進める方法については、記事「Introduction to accelerators for cloud-native solutions」で説明しています。

このチュートリアルでは、新しくリリースされた Accelerator for Event-driven Solutions を取り上げ、リファレンス・ブループリント の 1 つを使用して、サンプル・コードだけが含まれるイベント駆動型アプリケーションを設計してデプロイするまでのプロセスを迅速に進める方法を説明します。さらに、このイベント駆動型アプリケーションがワークロードの増加に応じて正常にスケーリングする仕組みを理解するために、完全に機能するリファレンス・ブループリントのアプリケーションのクローンを作成してデプロイできます。チュートリアルの手順を開始する前に、イベント駆動型アーキテクチャーに関する基本をいくつか押さえておきましょう。

イベント駆動型アーキテクチャーの利点

イベント駆動型 とは、ソフトウェア・アーキテクチャーの設計に適用できる 1 つの手法を表すために使われている用語です。イベント駆動型アーキテクチャーでは、疎結合されたマイクロサービスが生成したり取り込んだりするイベントを中心に、エコシステムを展開します。イベントは状態の変化を表します。これらのイベントが、ビジネスの不変の流れを形作ります。イベント駆動型が従来の同期メッセージング・システムよりも有利なわけとしては、例えば次の理由が挙げられます。

• レジリエンシー: サービスは障害が発生しても回復し、イベントを再生できます。
• プッシュとプルの違い: クライアントはポーリングではなく、プッシュによって更新を受信できます。
• 分離: あるサービスで変更を加えても、他のサービスには影響が及びません。
• スケーラビリティー: アプリケーションのニーズを満たすために、サービスをスケーリングできます。
• 弾力性: CPU 使用率やリクエストの数などの需要のメトリックに基づいて、サービスが自律的にスケールアップ、スケールダウンすることができます。

Accelerator for Event-driven Solutions には、イベント駆動型アプリケーションを対象としたリファレンス・ブループリントが用意されています。このチュートリアルでは Coffee Shop ブループリントを例に、Accelerator テクノロジーを使用してアプリケーションのすべてのバックエンド・リポジトリーを自動的に生成する方法を説明します。さらに、サンプル・コードを Red Hat OpenShift クラスターにデプロイしてその動作を確認します。このブループリントには、イベント駆動型への移行を強化する数々の Kubernetes Operator が必要になりますが、IBM Cloud Pak for Applications テクノロジー・プレビューでは必要な以下の Operator がデフォルトでインストールされます。

• Appsody Operator: Appsody で開発されたアプリケーションを Kubernetes 上で実行する Operator です。
• Strimzi Operator: Apache Kafka を Kubernetes クラスター上で実行する Operator です。
• Service Binding Operator: この Operator を使用すると、手作業でシークレットと構成プロパティーをセットアップしなくても、簡単にデータベースなどのバックエンド・サービスにアプリケーションをバインドできます。

Coffee Shop リファレンス・ブループリントについて

Coffee Shop ブループリントは、コーヒー・ショップのサンプル・シナリオとして、このコーヒー・ショップ・ドメインでのワークフローをシミュレートします。サンプルのコーヒー・ショップでは、顧客がさまざまな温かい飲み物の中から商品を注文できます。顧客の注文はキューに入れられて、バリスタが注文を履行します。ショップがたくさんの注文を受注して忙しくなってくると、注文に対処するために追加のバリスタを参加させることができます。

顧客がコーヒーを注文する際には Coffee Shop ユーザー・インターフェース (UI) または REST エンドポイントを使用します。注文イベントはバリスタの実装に応じて、2 つの方法のいずれかで処理されます。

• HTTP バリスタ: このマイクロサービスは、シンプルな REST エンドポイントです。顧客が HTTP POST リクエストを送信してコーヒー・ショップに発注し、注文 UI が、飲み物の準備ができたというレスポンスを待機するという仕組みになっています。つまり、同期されたリクエスト/レスポンスのメッセージング・スタイルに従っています。
• Kafka バリスタ: このマイクロサービスは非同期メッセージングを使用します。UI からの注文は Kafka イベント・バスで送信されて、Kafka バリスタがサブスクライブする orders トピック で公開されます。注文が履行されると、Kafka バリスタがコーヒーの準備ができたことを示すイベントを queue トピック に公開します。注文 UI は、この queue トピックにサブスクライブします。

以下の図は、このシナリオの概要を示しています。

このシナリオで使用されるマイクロサービスには、coffeeshop-ui microservice (Open Liberty)、HTTP-barista microservice (Open Liberty)、Kafka-barista microservice (Quarkus) があります。これらのマイクロサービスは、アプリケーション・スタック を基に開発されてコンテナー化され、Kubernetes クラスターにデプロイできる状態になります。

前提条件

このチュートリアルの手順に従うには、次の前提条件を満たす必要があります。

• IBM Cloud Pak for Applications v4.2 をインストールします。
• Accelerator テクノロジー・プレビューをインストールします。
• GitHub アカウントを作成します。

所要時間

このチュートリアルの所要時間は約 60 分です。

手順

Accelerator for Event-driven Solutions を利用するとアプリケーションの開発とデプロイを迅速化できる仕組みを明らかにするために、このチュートリアルの手順では Coffee Shop リファレンス・ブループリントを使用したワークフローを最初から最後まで説明します。

ステップ 1: Coffee Shop アーティファクト用の GitHub 組織を作成する

• GitHub で、GitHub プロファイル写真をクリックしてから「Settings (設定) 」をクリックします。
• 「Personal settings (個人用設定) 」セクション内の「Organizations (組織) 」をクリックします。
• 「New Organization (新しい組織) 」をクリックします。
• 「Organization name (組織名) 」フィールドに「my-coffeeshop」と入力します。
• 「Create organization (組織を作成) 」、「Finish (完了) 」の順にクリックします。

ステップ 2: Coffee Shop アプリケーションの Accelerator リファレンス・ブループリントをロードする

• IBM Cloud Pak for Applications のランディング・ページで、「Build Solution (ソリューションの作成) 」を選択して Solution Builder ツールを起動します。
• Coffee リファレンス・ブループリントをキャンバスにロードします。それには、「New Blueprint (新しいブループリント) 」をクリックし、使用可能なブループリントのリストから「 (Ref) Coffee Shop 」を選択します。

• 以下のスクリーン・キャプチャーに示されているように、このアプリケーション・トポロジーは coffeshop-ui、barista-kafka、barista-http という 3 つのマイクロサービスで構成されています。

• このリファレンス・ブループリントを使用するには、その前に、このプロジェクトを新しい名前で保存する必要があります。「Save As (名前を付けて保存) 」選択項目をクリックし、プロジェクトの新しい名前を入力してから「Save (保存) 」をクリックします。

このチュートリアルに従うために変更しなければならない値はありませんが、独自のイベント駆動型アプリケーションを使用する場合は値の変更が必要になることがあります。例えば、マイクロサービスに別のアプリケーション・スタックを使用するなどです。

ステップ 3: GitHub の構成詳細を追加する

• 「Blueprint properties (ブループリントのプロパティー) 」をクリックし、「Git Properties (Git のプロパティー) 」フィールドに GitHub 組織名を追加します。

• 開発環境、ステージング環境、本番環境にそれぞれ別個の GitOps リポジトリーをセットアップすることもできます。このチュートリアルの例では、ステージング環境と本番環境のチェック・ボックスをオフにします。

• 「Kafka Config (Kafka 構成) 」セクションで、Kafka レプリカの数 (クラスター内に必要なブローカーの数) や Zookeeper レプリカの数などの構成プロパティーを設定できます。このチュートリアルでは、両方のレプリカの数を値 1 のままにします。

• 「Blueprint Properties (ブループリントのプロパティー) 」ペインで行った変更を保存します。
• メニュー・バーで「Save Blueprint (ブループリントの保存) 」アイコンをクリックしてソリューション・ブループリントを保存します。

ステップ 4: GitHub 上にリポジトリーを生成する

• GitHub 上で、組織内のすべてのリポジトリーを完全に制御するための GitHub の個人用アクセス・トークンを生成し、クリップボードにコピーします。ヘルプが必要な場合は、 コマンド・ラインで個人用アクセス・トークンを作成する方法 を参照してください。
• Solution Builder で、「Generate (生成) 」をクリックします。
• GitHub 資格情報を入力するよう求められたら、GitHub ユーザー ID を入力し、クリップボードにコピーしたトークンを「Git Token (Git トークン) 」フィールドに貼り付けます。
• 再度「Generate (生成) 」をクリックします。

Solution Builder がバックエンドの GitHub リポジトリーを生成している間、その進捗状況が「Execution window (実行ウィンドウ) 」に示されます。実行中のプロセスは明るい緑色で示され、完了すると濃い緑色に変わります。まだ開始されていないプロセスは灰色で示されます。

ステップ 5: すべての GitHub リポジトリーが正常に生成されたことを確認する

GitHub 組織を表示して、生成されたリポジトリーを確認します。baristahttp、baristakafka、coffeeshopui、gitops-dev の 4 つのリポジトリーが表示されるはずです。

このリポジトリーに、アプリケーションのスキャフォールドが格納されています。マイクロサービスのリポジトリー内にはサンプル・コードがあります。GitOps のリポジトリー内には、すべてのマイクロサービスをデプロイして Kafka イベント・バスとの適切な接続を確立するための構成が格納されています。この段階ではまだ、Coffee Shop アプリケーションを駆動するビジネス・ロジックが欠けていますが、ワークフロー全体を確認するために、現状のまま、アプリケーションをデプロイする手順に進みます。

ステップ 6: デプロイメント環境を準備する

このアプリケーションは、OpenShift クラスター上の専用の名前空間で実行する必要があります。それには、以下の手順に従います。

• アプリケーションをデプロイする名前空間を作成します。OpenShift クラスター上に coffeeshop-dev 名前空間を作成するには、以下のコマンドを実行します。

  oc create namespace coffeeshop-dev
  

  Show more

• 作成された名前空間を Kabanero Custom Resource Definition (CRD) に追加します。

  • CRD を編集するために、以下のコマンドを実行します。

    oc edit kabanero kabanero -n kabanero
    

    Show more

  • 以下の例に示すように、名前空間を targetNamespaces: 配列に追加します。

    targetNamespaces:
    - kabanero
    - coffeeshop-dev
    

    Show more

  • ファイルを保存します。

ステップ 7: Webhook を構成する

Webhook はプル・リクエストを連結して、GitHub リポジトリーで発生したイベントをパイプラインにマージします。このチュートリアルでは、Tekton ダッシュボードを使用して Webhook を構成します。

• GitHub の個人用アクセス・トークンを生成します。GitHub の個人用アクセス・トークンを作成して、パイプラインが Git リポジトリーにアクセスできるようにする必要があります。

  • https://github.com/settings/tokens にアクセスして、「Generate new token (新規トークンを生成) 」をクリックします。
  • 「Note (メモ) 」フィールドに簡潔な説明を入力します。例えば、「webhook_token」と入力します。
  • 「Select scopes (スコープを選択) 」セクションで、「repo 」と「admin:repo_hook 」のチェック・ボックスをオンにしてから、「Generate token (トークンを生成) 」をクリックします。
  • 生成されたトークンをクリップボードにコピーします。

• Tekton ダッシュボード内でシークレットを作成します。以下の手順に従って、GitHub の個人用アクセス・トークンを Kubernetes シークレットに含めて保管します。

  • Tekton ダッシュボードのサイドバー・メニューから「Secrets (シークレット) 」を選択します。
  • 「Secret type (シークレットのタイプ) 」として「Password (パスワード) 」を選択し、「Create (作成) 」をクリックします。
  • 「Name (名前) 」フィールドに「gitops-token」と入力します。
  • 「Namespace (名前空間) 」として、ドロップダウン・リストから「kabanero 」を選択します。
  • 「Access To: (アクセス先:) 」として、ドロップダウン・リストから「Git Server (Git サーバー) 」を選択します。必要に応じてデフォルト値 (https://github.com) を更新します。
  • 「Username (ユーザー名) 」フィールドに、GitHub ユーザー名を入力します。
  • 「Password (パスワード) 」フィールドに、前の手順で生成した個人用アクセス・トークンを追加します。
  • 「Create (作成) 」をクリックします。
  • サービス・アカウントのリストから、パッチの適用対象として「kabanero-pipeline 」を選択し、「Patch (パッチを適用) 」をクリックします。

• マイクロサービス・リポジトリーごとに Webhook を作成します。各マイクロサービス・リポジトリーについて、以下の手順を行います。

  • Tekton ダッシュボードのサイドバー・メニューから「Webhooks (Webhook) 」を選択し、「Add Webhook (Webhook の追加) 」をクリックします。「Create Webhook (Webhook の作成) 」ペインが開きます。

  • 「Webhook Settings (Webhook の設定) 」セクションで、以下の情報を入力します。

    • 「Name (名前) 」: Webhook の一意の名前を選択します。例えば、マイクロサービス・リポジトリーの名前を含めて、どのマイクロサービス・リポジトリーに対応する Webhook であるかを区別できるようにします。
    • 「Repository URL (リポジトリー URL) 」: GitHub リポジトリーの URL を入力します。
    • 「Access token (アクセス・トークン) 」: 「add (追加) (+) 」ボタンをクリックし、表示されたフィールドにこのシークレットの名前と、前に生成した GitHub アクセス・トークンを入力します。

  • 「Target Pipeline Settings (ターゲット・パイプラインの設定) 」セクションで、以下の情報を入力します。

    • 「Namespace (名前空間) 」: 「kabanero 」を選択します。
    • 「Pipeline (パイプライン) 」: 「build-push-promote-pl 」パイプラインを選択します。
    • 「Service Account (サービス・アカウント) 」: 「kabanero-pipeline 」サービス・アカウントを選択します。
    • 「Docker Registry (Docker レジストリー) 」: 「image-registry.openshift-image-registry.svc:5000/coffeeshop-dev」を追加します。または、独自の Docker Hub レジストリー (http://index.docker.io/<dockerhub-username>) を追加することもできます。

  • 「Create (作成) 」をクリックします。このダッシュボードは追加された値を記憶するので、以降の Webhook は簡単に追加できます。

• 組織内の GitOps リポジトリーごとに Webhook を作成します。組織内の各 GitOps リポジトリーについて、以下の手順を行います。

  • Tekton ダッシュボードのサイドバー・メニューから「Webhooks (Webhook) 」を選択し、「Add Webhook (Webhook の追加) 」をクリックします。「Create Webhook (Webhook の作成) 」ペインが開きます。

  • 「Webhook Settings (Webhook の設定) 」セクションで、以下の情報を入力します。

    • 「Name (名前) 」: Webhook の一意の名前を選択します。例えば、マイクロサービス・リポジトリーの名前を含めて、どのマイクロサービス・リポジトリーに対応する Webhook であるかを区別できるようにします。
    • 「Repository URL (リポジトリー URL) 」: GitHub リポジトリーの URL を入力します。
    • 「Access token (アクセス・トークン) 」: 「add (追加) (+) 」ボタンをクリックし、このシークレットの名前と、前に生成した GitHub アクセス・トークンを該当するフィールドに入力します。

  • 「Target Pipeline Settings (ターゲット・パイプラインの設定) 」セクションで、以下の情報を入力します。

    • 「Namespace (名前空間) 」: 「kabanero 」を選択します。
    • 「Pipeline (パイプライン) 」: 「deploy-gitops-pl 」パイプラインを選択します。
    • 「Service Account (サービス・アカウント) 」: 「kabanero-pipeline 」サービス・アカウントを選択します。
    • 「Docker Registry (Docker レジストリー) 」: このフィールドは使用されないので、何を入力するのでもかまいません。

  • 「Create (作成) 」をクリックします。

• GitHub リポジトリーごとの Webhook を確認します。GitHub 内に Webhook が正しくセットアップされていることを確認するには、以下のチェックを行います。

  • GitHub の各リポジトリーの「Settings (設定) 」タブで「Hooks (フック) 」を選択して、作成した Webhook を見つけます。
  • Webhook に対して緑色のチェックマークが示されていれば、正常に機能しています。

ステップ 8: GitOps パイプラインを接続する

GitOps パイプラインは、コード・リポジトリー、GitOps リポジトリー、ターゲット・デプロイメント環境の間でワークフローを駆動する数々のタスクを実行します。

build-push-promote-pl パイプライン

プル・リクエストが GitHub コード・リポジトリーでマージされると、build-push-promote-pl パイプラインが以下のワークフローを処理するタスクを実行します。

• ガバナンス・ポリシーを適用する。
• コンテナー・イメージをビルドする。
• イメージに署名を付ける (省略可)。
• イメージをイメージ・レジストリーにプッシュする。
• イメージを走査する。
• 構成の変更を構成済み GitOps リポジトリーにプロモートする。

このパイプラインをセットアップするには、以下の手順に従います。

• Kabanero 名前空間内に ConfigMap を構成します。

  • gitops-map.yaml という名前のファイルを作成し、以下の内容を含めます。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: gitops-map
      namespace: kabanero
    data:
      gitops-repository-url: <gitops-repo-url>
      gitops-repository-type: ghe
      gitops-commit-user-name: <user_name>
      gitops-commit-user-email: <user_email>
    

    Show more

    ここで:

    • <gitops-repo-url> は GitOps リポジトリーの URL です (例: https://github.ibm.com/my-coffeeshop/gitops-dev)。
    • <user_name> は、プル・リクエストに適用する GitHub ユーザー名です。
    • <user_email> は、<user_name> で識別された GitHub ユーザーの e-メール・アドレスです。

  • コマンド oc apply -f gitops-map.yaml を使用して、このファイルを適用します。

deploy-gitops-pl パイプライン

プル・リクエストが GitOps リポジトリーでマージされると、deploy-gitops-pl パイプラインがターゲット環境へのデプロイをトリガーします。これにより、クラスター上のアプリケーションが更新されます。

ステップ 9: Coffee Shop アプリケーションをデプロイする

Coffee Shop アプリケーションを初めてデプロイする際は、各マイクロサービスを個別に作成する必要があります。それには、リポジトリーごとに以下の手順を行います。

• プル・リクエストを作成するために、各リポジトリーで以下のタスクを行います。

  • 新しい Git ブランチで、README.md を編集して変更を反映します。
  • ファイルを保存します。
  • ブランチをマスターにマージするためのプル・リクエストを作成します。
  • build-push-promote-pl パイプラインが完了するのを待ってから、次のステップを開始します。

• プル・リクエストをマージします。パイプライン・ダッシュボードで、build-push-promote-pl パイプラインの実行状況を観察します。パイプラインは GitOps リポジトリーでプル・リクエストを作成して実行を完了します。

• 作成されたプル・リクエストを GitOps リポジトリーでマージします。パイプライン・ダッシュボードで、deploy-gitops-pl パイプラインの実行状況を観察します。パイプラインの実行が完了したら、以下のコマンドを実行して、マイクロサービスが OpenShift にデプロイされたことを確認します。

  oc get deployments -n coffeeshop-dev
  

  Show more

  このコマンドの出力に、以下の例のように barista-kafka、barista-http、coffeeshop-ui の各マイクロサービスが利用可能であることが示されたら、マイクロサービスのデプロイが成功したことを意味します。

  NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
  kafka-entity-operator   1/1     1            1           28m
  kafka-kafka-exporter    1/1     1            1           28m
  barista-kafka           1/1     1            1           32m
  barista-http            1/1     1            1           34m
  coffeeshop-ui           1/1     1            1           36m
  

  Show more

  これで、ワークフロー全体が完全に有効になりました。開発者によるコード変更がマージされると、そのコード・リポジトリーの Webhook が build-push-promote-pl パイプラインをトリガーします。このパイプラインが一連のタスクを実行することによって、プル・リクエストに格納された構成の変更が GitOps リポジトリーにプロモートされます。このプル・リクエストがマージされると、GitOps リポジトリー上の Webhook が deploy-gitops-pl パイプラインをトリガーし、このパイプラインによって更新がターゲット・デプロイメント環境にデプロイされます。

• OpenShift クラスター上で CoffeeShop が実行されていることを確認します。OpenShift UI で、「Developer (開発者)」 > 「Topology (トポロジー)」 を表示し、Coffee Shop プロジェクトを選択します。デプロイ・プロセスが完了すると、以下のスクリーン・キャプチャーに示すように、一連のマイクロサービスがダッシュボード上に表示されます。

お疲れさまでした！Accelerator for Event-driven Solutions を使用して、スケルトン・アプリケーションを生成して OpenShift にデプロイできました。各マイクロサービスは適切な接続構成が設定された状態で、クラスター上で実行されます。ヘルス・チェック、活性チェック、メトリックもすでに組み込まれているため、OpenShift でアプリケーションを管理してモニタリングできます。GitHub 内でマイクロサービスまたはアプリケーション全体の構成に対して更新が行われるたびに、継続的インテグレーション/継続的デリバリー (CI/CD) ワークフローが駆動されてデプロイメント環境内のアプリケーションが更新されます。

完全な Coffee Shop アプリケーションをデプロイする手順

実際に機能する Coffee Shop アプリケーションを使用してコーヒーを注文し、このイベント駆動型ソリューションの動作を観察するために、icpa-coffeeshop 組織内にあるこのソリューション・ブループリントのデモ・コードのクローンを作成してデプロイすることができます。

ステップ 1: Coffee Shop アプリケーションのクローンを作成する

• アプリケーションに固有の GitHub 組織を作成します (例: my-coffeeshop)。
• この組織内に、すべてのリポジトリーのクローンを作成します。

ステップ 2: アプリケーションで使用する名前空間を作成する

• ターミナル・ウィンドウを開き、トークンを使用して OpenShift クラスターにログインします。

• OpenShift クラスター上のアプリケーションに使用する coffeeshop-dev という名前空間を作成するために、以下のコマンドを実行します。

  oc create namespace coffeeshop-dev
  

  Show more

ステップ 3: Kafka クラスターを作成する

以下のコマンドを実行して Kafka クラスターを作成します。

oc apply -f environments/coffeeshop-dev/apps/coffeeshop/base/kafka/kafka.yaml

ステップ 4: Coffee Shop アプリケーションをデプロイする

• coffeeshop-ui、barista-kafka、barista-http の 3 つのマイクロサービスをデプロイします。

  oc apply -k environments
  

  Show more

• OpenShift UI で、「Developer (開発者)」 > 「Topology (トポロジー)」 を表示し、「coffeeshop」プロジェクトを選択します。プロビジョニング・プロセスが完了すると、実行中のデプロイメントが表示されます。

ステップ 5: コーヒーを注文する

デプロイが完了したので、次は、温かい飲み物を注文するための操作を開始します。

• 「coffeeshop-ui 」マイクロサービスをクリックし、右側のパネルにある「Routes (ルート) 」で「Location (ロケーション) 」URL をクリックします。UI が表示されて、コーヒーの注文を開始できます。

• UI 内で顧客名を入力し、注文方法を選択します。

• 飲料品を選択して、「Place Order (注文する) 」をクリックします。

注文がキューに送信されて、「queue (キュー) 」セクションに示されます (以下の図を参照)。最初は、注文の状態が IN_PROGRESS として示されます。

バリスタが注文を履行すると、そのバリスタの名前が「Prepared by (担当者) 」列に示され、「State (状態) 」が更新されて注文のステータスが示されます。

ステップ 6: コーヒーの注文数を増やす

コーヒー・ショップが忙しくなってくると、キューに入れられた注文をバリスタが完了するまでの時間が長くなります。ただし、サービスをスケールアウトして稼働するバリスタを増やし、より多くの注文をより短時間で履行できるようにするには、追加の Kafka バリスタ・サービスを起動できます。これにより、過剰な負荷を複数の Kafka バリスタ・サービス間で分散できるようになります。

スケールアウトによる負荷分散を可能にするには、orders トピック内のパーティションの数をバリスタの数よりも多くしててください。

ステップ 7: デプロイメントを削除する

デプロイメントを削除するには、coffeshop 名前空間を削除します。これにより、デプロイメント・コンポーネントが除去されます。OpenShift ダッシュボードで直接名前空間を削除することも、以下のコマンド・ラインを使用して削除することもできます。

oc delete project coffeeshop

まとめ

Reactive マイクロサービス・ベースのクラウド・ネイティブ・アプリケーションを設計して実装するには、Accelerator for Event-driven Solutions が役立ちます。リファレンス・ブループリントを出発点に、アプリケーションの部品構成表 を表す独自のソリューション・ブループリントを作成できるからです。Accelerator はそのブループリントを使用して、Git 内にアプリケーションの構造全体を生成します。この構造によって有効になる開発者用の Git ワークフローとコンテナー・プラットフォーム運用チーム用の GitOps ワークフローを使用すれば、手作業で行う場合と比べてほんのわずかな時間でアプリケーションを稼働中にすることができます。

アプリケーションのビジネス・ロジックをコーディングしなければならないことに変わりはありませんが、コンテナー化されたマイクロサービスを短時間で作成してデプロイできます。それぞれのマイクロサービスは、必要なランタイム依存関係がすべて揃ったコンテナー内で実行されます。また、各マイクロサービスはクラスター上の正しいマイクロサービスおよびイベント・チャネルと接続するように事前に構成済みです。ヘルス・チェック、活性チェック、メトリックもすでに組み込まれているため、OpenShift でアプリケーションを管理してモニタリングできます。

デプロイされた時点からは、GitHub 内でマイクロサービスまたはアプリケーション全体の構成に対して更新が行われるたびに、CI/CD ワークフローが駆動されてデプロイメント環境内のアプリケーションが更新されます。

チュートリアルの後半でデモ Coffee Shop アプリケーションのクローンを作成してデプロイした場合 (そして、コーヒーを注文した場合)、イベント駆動型アプリケーション・アーキテクチャーに伴う利点のいくつかを理解していただけたと思います。REST ベースのバリスタと比べ、Kafka バリスタはより疎結合されていて、メッセージを非同期で取り込んだり生成したりできます。このソリューションはスケーラブルで、弾力性とレジリエンシーを兼ね備えています。

Cloud Pak for Applications 内に用意されている Accelerator とリファレンス・ブループリントの使用方法についての詳細は、IBM Knowledge Center テクノロジー・プレビューのドキュメントを参照してください。

Reactive アーキテクチャーについての詳細は、IBM Garage Event-Driven Reference Architecture のリポジトリーにアクセスしてください。