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

概要

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

このチュートリアルでは、新しくリリースされた Accelerator for Cloud-native Apps を取り上げ、リファレンス・ブループリント の 1 つを使用して、REST ベースのサンプル・マイクロサービスだけで構成されたアプリを設計してデプロイするまでのプロセスを迅速に進める方法を説明します。チュートリアルの手順を開始する前に、いくつかの基本を押さえておきましょう。

クラウド・ネイティブ・アーキテクチャーの利点

クラウド・ネイティブ とは、クラウド上で実行することを目的に設計、構築、最適化されたアプリケーションを表すために使用されている業界用語です。クラウド・ネイティブ・アプリケーションは一般に、コンテナー内で実行されて Kubernetes などのオーケストレーション・システムで管理される、疎結合されたマイクロサービスとして実装されます。本質的に、これらのアプリケーションには弾力性があります。つまり、需要に応じて自律的にスケーリングできるアプリケーションなのです。また、異なるクラウド間で移植することもできます。クラウド・ネイティブ・アプリケーションには、継続的インテグレーション (CI)、継続的デリバリー (CD)、DevOps、GitOps などの最新のソフトウェア・デリバリー手法が利用されます。

クラウド・ネイティブ・アーキテクチャーに移行すると、次のような利点があります。

• マイクロサービス間の疎結合
• コード・ベースが小さい軽量のサービス
• 弾力性
• 移植性
• 言語中立
• 継続的インテグレーション/継続的デリバリー (CI/CD) システムとの統合

IBM Cloud Architecture Center でホストしている完全なクラウド・ネイティブ・ソリューションのリファレンス・アーキテクチャーには、クラウド・ネイティブ・アプリケーションを開発するためのいくつかの貴重なリソースが含まれています。

IBM Cloud Pak for Applications v4.2 に含まれる Accelerator for Cloud-native Apps というテクノロジー・プレビューでは、REST ベースのマイクロサービス・アプリケーションを開発する際の完全なワークフローを使用できるようになっています。REST ベースのマイクロサービスが HTTP で互いに通信するには、一般に OpenAPI 仕様のドキュメントで定義された API を使用します。

Accelerator for Cloud-native Apps を利用すると、ソリューション・アーキテクトは Open Liberty、Spring、Quarkus、および Node.js テクノロジーに基づく REST ベースのマイクロサービスからなるマイクロサービス・アプリケーション・アーキテクチャーを設計できます。また、完全なトポロジー内でマイクロサービスが相互作用する方法も指定できます。その上で、継続的デリバリー・パイプラインによってデプロイできる状態の完全なアプリケーションを自動的に生成できるよう、GitOps リポジトリーと併せてマイクロサービスごとのスケルトン Git リポジトリーを生成できます。

Accelerator for Cloud-native Apps には、REST ベースのマイクロサービスのシナリオを実装する StoreFront アプリケーションのリファレンス・ブループリント が用意されています。

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

StoreFront ブループリントは、以下の図に示す IBM Cloud の BlueCompute リファレンス・アーキテクチャーに基づいています。

このブループリントが表しているのは、オンライン・ショッピング用のアプリケーションです。顧客はカタログを参照して、そこに掲載されている年代物のコンピューティング機器を選んで購入できます。

BlueCompute の詳細は、IBM Cloud Architecture Center で調べることができます。「Deploy a retail application on RedHat OpenShift」を参照してください。

前提条件

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

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

所要時間

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

手順

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

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

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

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

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

• メニュー・バーで、「More Options (その他のオプション)」 > 「Save As (名前を付けて保存) 」をクリックし、新しい名前を付けて、ブループリントの独自のコピーを保存します。以下のスクリーン・キャプチャーに、このブループリントが示されています。

  上のスクリーン・キャプチャーにはアプリケーションのトポロジーも示されています。オンライン・ストアでユーザー・インターフェースを使用できるようにするのは、フロントエンドの Web バックエンド (webbff) マイクロサービスです。この REST ベースのマイクロサービスがバインドする他の 4 つの REST ベースのマイクロサービスはそれぞれ、顧客レコードのクエリー、ショッピング・カタログ内の商品のクエリー、注文レコードのクエリー、在庫レコードのクエリーを行います。これらのマイクロサービスには、それぞれ独自のバックエンド・データベースがあります。

• 各コンポーネントを順にクリックして、その構成設定を確認できます。

  • webbff コンポーネントは、Node.js Express アプリケーション・スタックからマイクロサービスを作成するように構成されています。
  • Customer、Catalog、Order、Inventory コンポーネントは、Open Liberty アプリケーション・スタックからマイクロサービスを作成するように構成されています。各マイクロ―サービスはそれぞれ独自のバックエンド・データベースに接続します。
  • すべてのバックエンド・データベースは PostgresSQL 11 をベースに稼働します。

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

• メニュー・バーで「Blueprint properties (ブループリントのプロパティー) 」をクリックし、「Git Properties (Git のプロパティー) 」フィールドに GitHub 組織の URL を追加します (以下の図を参照)。

• GitOps のステージング環境と本番環境を追加するためのチェック・ボックスを両方ともオフにします。

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

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

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

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

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

GitHub 組織を表示して、生成されたリポジトリーを確認します。

StoreFront アプリケーションを構成するマイクロサービスごとに、GitHub コード・リポジトリーが作成されています。

各マイクロサービス・リポジトリーに格納されている app-deploy.yaml ファイルは、Appsody Operator がプロジェクトをデプロイする際に使用する構成ファイルです。このファイル内で、アプリケーション・スタックに関する情報と、そのマイクロサービス用に公開されるエンドポイントを確認できます。webbff リポジトリー内の app-deploy.yaml ファイルに含まれる以下のセクションで、StoreFront アプリケーションの一部として nodejs-express スタック・バージョン 0.4.8 で稼働する webbff マイクロサービスが特定されています。

...
labels:
  app.kubernetes.io/part-of: storefront
  image.opencontainers.org/title: webbff
  stack.appsody.dev/id: nodejs-express
  stack.appsody.dev/version: 0.4.8
name: webbff
...

gitops-dev という単一の GitOps リポジトリーも作成されています。ここには、開発環境とデプロイメント環境に関する情報が格納されています。

gitops-dev リポジトリー内に格納された environments/storefront-dev/env/base/namespace.yaml に、アプリケーションのターゲット名前空間が storefont-dev であることが示されています。

apiVersion: v1
kind: Namespace
metadata:
  name: storefront-dev

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

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

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

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

  oc create namespace storefront-dev
  

  Show more

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

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

    oc edit kabanero kabanero -n kabanero
    

    Show more

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

    targetNamespaces:
    - kabanero
    - storefront-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/storefront-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-storefront/gitops-dev)。
    • <user_name> は、プル・リクエストに適用する GitHub ユーザー名です。
    • <user_email> は、<user_name> で識別された GitHub ユーザーの e-メール・アドレスです。

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

deploy-gitops-pl パイプライン

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

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

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

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

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

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

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

  oc get deployments -n storefront-dev
  

  Show more

  このコマンドの出力に、以下の例のように customer、inventory、order の各マイクロサービスとそれぞれの PostgresSQL データベースが利用可能であることが示されたら、マイクロサービスのデプロイが成功したことを意味します。

  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  customer                 1/1     1            1           14d
  customerdb-postgresql    1/1     1            1           14d
  inventory                1/1     1            1           14d
  inventorydb-postgresql   1/1     1            1           14d
  order                    1/1     1            1           14d
  orderdb-postgresql       1/1     1            1           14d
  

  Show more

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

• OpenShift クラスター上で StoreFront が実行されていることを確認します。

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

お疲れさまでした！Accelerator for Cloud-native Apps を使用して、スケルトン・アプリケーションを生成して OpenShift にデプロイできました。

まとめ

Accelerator for Cloud-native Apps を利用すれば、迅速に REST ベースのアプリケーションを設計して配信できます。リファレンス・ブループリントを出発点に、アプリケーションの部品構成表 を表す独自のソリューション・ブループリントを作成できるからです。Accelerator はそのブループリントを使用して、Git 内にアプリケーションの構造全体を生成します。この構造によって有効になる開発者用の Git ワークフローとコンテナー・プラットフォーム運用チーム用の GitOps ワークフローを使用すれば、手作業で行う場合と比べてほんのわずかな時間でアプリケーションを稼働中にすることができます。

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

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

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