Cloud シェルの初期設定

Red Hat OpenShift Container Platform CLIは、アプリケーションを管理するためのコマンドと、システムの各コンポーネントとやり取りするための低レベルのツールを公開している。 oc コマンドを使用すると、この CLI を使用できます。

コマンド・ライン・ツールのインストールを避ける場合は、IBM Cloud Shell を使用することをお勧めします。

IBM Cloud Shell は、ブラウザーで利用できるクラウド・ベースのシェル・ワークスペースです。 完全な IBM Cloud CLI と、アプリ、リソース、インフラストラクチャーの管理に使用できる数多くのプラグインおよびツールが事前構成されています。

この手順では、IBM Cloud シェルを使用して、割り当てられたクラスターを指すように oc を構成します。

1. クラスターの準備ができたら、右上隅のボタン (アカウントの隣) をクリックして Cloud シェルを起動します。 このウィンドウ/タブは閉じないでください。

2. OpenShift CLI のバージョンを確認します。

   oc version
   

   バージョンは最低でも 4.12.x である必要があります。そうでない場合は、 以下の 手順に従って最新バージョンをインストールしてください。

3. すべてのクラスターをリスト表示したときに、使用しているクラスターが表示されていることを確認します。

   ibmcloud oc clusters
   

4. プレースホルダ を置き換えて、 oc コマンド環境を初期化する：

   ibmcloud oc cluster config -c <your-cluster-name> --admin
   

5. oc コマンドが機能していることを確認します。

   oc get projects
   

プロジェクトの作成

プロジェクトとは、DevOps チームによって管理されるリソースのコレクションです。 管理者がプロジェクトを作成し、開発者が、ビルドしてデプロイできるアプリケーションを作成します。

1. 選択したクラスタで OpenShift ウェブコンソールボタンをクリックして、 Red Hat OpenShift ウェブコンソールに移動します。
2. 左側のナビゲーション・ペインの 「管理者」 パースペクティブで、「ホーム」 > 「プロジェクト」 ビューを選択して、すべてのプロジェクトを表示します。
3. 「Create Project」 をクリックして、新しいプロジェクトを作成します。 ポップアップでプロジェクトの 「名前」 に example-health と入力し、「表示名」 と 「説明」 はブランクのままにして、「作成」 をクリックします。
4. 新しいプロジェクトの 「Project Details」 ページが表示されます。 コンテキストは、左側が Administrator > Home > Projects、上側が Projects > Project details > example-health であることを確認してください。

アプリケーションのビルドとデプロイ

1. 「管理者」 から 「開発者」 パースペクティブに切り替えます。 左側に「 Developer 」>「 +Add 」、上部に「 Project: example-health 」と表示された状態であるはずです。

   

2. 「 Import from Git 」を選択して、アプリケーションをビルドしてデプロイしましょう。
3. 「Git Repo URL」フィールドにリポジトリー https://github.com/IBM-Cloud/patient-health-frontend.git を入力します。
   • 緑色のチェック Builder image detected と Node.js 16 (UBI 8) に注意してください。
   • ビルダー・イメージによって言語 Node.js が自動的に検出されたことに注意してください。検出されない場合は、提供されているリストから Node.js を選択します。
   • 「Builder Image Version」 はデフォルトのままです。
   • 「Application Name」 は、文字をすべて削除して空にします (これによって 「Name」 と同じ名前がデフォルトとして設定されます)
   • Name : patient-health-frontend。
   • 「リソース・タイプ」 リンクをクリックして、 DeploymentConfig を選択します。
   • 他の選択項目についてはデフォルトのままにします。
4. ウィンドウ下部の 「Create」 をクリックして、アプリケーションをビルドしてデプロイします。

アプリケーションの表示

1. 先ほどデプロイしたアプリが表示されるはずです。 「Developer」 パースペクティブの example-health プロジェクトの 「Topology」 ビューにいることを確認します。 このプロジェクト内のすべてのアプリケーションが表示されています。

2. ノード の 「patient-health-frontend」 を選択し、DeploymentConfigの詳細ビューを表示します。 「patient-health-frontend」 の横に 「DC」 と表示されていることに注目してください。 「Pods」、「Builds」、「Services」、「Routes」が表示されます。

   

   • Pods: Node.js アプリケーション・コンテナー
   • Builds: Node.js ソース・コードから Docker イメージを作成し、そのイメージを Red Hat OpenShift コンテナー・レジストリーにデプロイし、デプロイメント構成を開始した自動生成のビルド
   • Services: 複数のポッドを 1 つのサービスとしてグループ化し、listen するポートを定義することで、ポッドへのアクセス方法を Red Hat OpenShift に指示する
   • Routes: IBM Cloud ネットワークから提供される LoadBalancer を使用して、サービスを外部に公開する

3. 完了したビルドの横の 「View Logs」 をクリックします。 Red Hat OpenShift が Node.js アプリケーションの依存関係をインストールして Docker イメージをビルド/プッシュするために実行した処理が表示されます。 最後のエントリーは次のような表示であるはずです。

   Successfully pushed image-registry.openshift-image-registry.svc:5000/example-health/patient-health-frontend@sha256:f9385e010144f36353a74d16b6af10a028c12d005ab4fc0b1437137f6bd9e20a
   Push successful
   

4. 前の表示に戻るために 「Topology」 をクリックし、アプリをもう一度選択します。

5. 「Routes」 の URL をクリックして、アプリケーションにアクセスします。 このアプリはデモンストレーション・モードで実行されているので、ユーザー名とパスワードには、test:test などの任意のストリングを入力できます。

Node.js アプリが Red Hat OpenShift Container Platform にデプロイされました。 まとめると、次のようになります。

• Node.js の「Example Health」アプリケーションを GitHub からクラスターに直接デプロイしました。
• このアプリケーションを、Red Hat OpenShift on IBM Cloud コンソールで確認しました。
• ビルド構成 が作成されました。アプリケーションの詳細の「Builds」セクションで 「Start Build」 をクリックすることで、新しいコミットをビルドしてデプロイできます。

アプリケーションの負荷のシミュレート

負荷をシミュレートするスクリプトを作成します。

1. アプリをデプロイしたプロジェクトに接続していることを確認します。

   oc project example-health
   

2. アプリケーションにアクセスするためのパブリック・ルートを取得します。

   oc get routes
   

   次のような出力が表示されます。Host の値をメモしてください。

   NAME         HOST/PORT                                                                                                 PATH      SERVICES     PORT       TERMINATION   WILDCARD
   patient-health-frontend   patient-health-frontend-example-health.roks07-872b77d77f69503584da5a379a38af9c-0000.eu-de.containers.appdomain.cloud             patient-health-frontend   8080-tcp                 None
   

3. ホストを指定して変数を定義します。

   HOST=$(oc get routes -o json | jq -r '.items[0].spec.host')
   

4. アプリケーションへのアクセスを確認します。 患者情報が出力されます。

   curl -s -L http://$HOST/info
   

   次のような出力が表示されます。

   $ curl -s -L http://$HOST/info
   {"personal":{"name":"Ralph DAlmeida","age":38,"gender":"male","street":"34 Main Street","city":"Toronto","zipcode":"M5H 1T1"},"medications":["Metoprolol","ACE inhibitors","Vitamin D"],"appointments":["2018-01-15 1:00 - Dentist","2018-02-14 4:00 - Internal Medicine","2018-09-30 8:00 - Pediatry"]}
   

5. 次のスクリプトを実行します。このスクリプトは、アプリケーションに対して無限に要求を送信し続け、トラフィックを生成します。

   while sleep 0.2; do curl --max-time 2 -s -L http://$HOST/info >/dev/null; echo -n "."
   done
   

   スクリプトを停止するには、キーボードで CTRL + c を押します

Red Hat OpenShift on IBM Cloud ロギング

ポッドが 1 つしかないので、アプリケーション・ログの確認は簡単です。

1. 「Developer」 パースペクティブの 「Topology」 ビューにいることを確認します。

2. アプリを選択してポッドに移動します。

3. 「ポッド」 の下で、ポッドの名前の横に表示される 「ログを表示」 をクリックして、実行中のアプリケーションからのストリーミング・ログを表示します。 まだトラフィックを生成している場合は、要求が発行されるたびにログ・メッセージが表示されます。

   

Red Hat OpenShift on IBM Cloud の端末

Kubernetes の優れた点の 1 つとして、SSH 端末で簡単にアプリケーション・ポッドをデバッグできるという点があります。 Red Hat OpenShift、ダッシュボードで直接ターミナルを起動することができるので、さらに簡単です。

1. 「Logs」 タブを 「Terminal」 タブに切り替えます。
2. 以下のシェル・コマンドを実行します。

Red Hat OpenShift on IBM Cloud モニター

新しいアプリをデプロイするとき、構成を変更するとき、または単にクラスターの状態を調査するときに、開発者は、プロジェクトを範囲とするダッシュボードで詳しい洞察を得ることができます。

1. 左側メニューの 「Observe 」をクリックして、 開発者パースペクティブのダッシュボードにアクセスします。
2. 「イベント」 タブをクリックして、もう少し詳しく調べることもできます。 イベント は、イベントのタイムラインを調べて潜在的なエラー・メッセージを見つけるために役立ちます。 新規のロールアウトの状態を追跡したり、既存の資産を管理したりするとき、また、ルートを公開するなどの簡単な操作を実行するときでも、アクティビティーの時系列を調べるために「イベント」ビューが欠かせません。 複数のオペレーターが 1 つのクラスターに対して処理を行う場合には、より一層重要になります。

Red Hat OpenShift のほとんどすべてのアクションが、このビューに表示されるイベントを生成します。 リアルタイムで更新されるので、状態の変更を追跡するのに優れた手段です。

ダッシュボード

Red Hat OpenShift には、プロジェクトをモニターするための事前定義ダッシュボードが付属しています。

1. まずは 「Developer」 パースペクティブを 「Administrator」 パースペクティブに切り替えます。
2. 左側のバーで 「Observe」>「Dashboards」 に移動します。
3. ドロップダウンから 「Kubernetes」/「Compute Resources」/「Namespace (Pods)」 を選択し、名前空間を「 example-health 」に設定します。
4. アプリケーションの CPU とメモリーの使用量に注目します。 これは、実稼働環境でアプリケーションの CPU またはメモリーの平均使用量を調べるときに役に立ちます。特に一日の間に使用量が変動している場合などに役に立ちます。 変動に対応する方法の 1 つが自動スケーリングです。後で少し実際に試してみましょう。

メトリック

Red Hat OpenShift は、照会を実行し、プロットで視覚化されたメトリックを調べるための Web インターフェースを提供します。 この機能を使用すると、クラスター状態の概要を把握し、問題をトラブルシューティングすることができます。

1. 「監視」>「メトリック」 にナビゲートします。

2. 以下の式を入力し、 「照会の実行」 をクリックします。 照会に関連付けられている値とグラフが表示されます。

   sum(container_cpu_usage_seconds_total{container="patient-health-frontend"})
   

   

リソース制限の有効化

自動スケーリングの前に、CPU とメモリーの最大リソース制限を設定する必要があります。

先ほどのダッシュボードでは、負荷が「.002」から「.02」のコアを消費していた。 これは、2 ミリコアから 20 ミリコアに相当します。 安全のために、最大 30 ミリコアと想定しましょう。 さらに、このデータは、アプリケーションが約 25-65 MB の RAM を消費することを示しています。 以下の手順を実行して、deploymentConfig にリソース制限を設定します。

1. トラフィックを生成するスクリプトが実行中であることを確認します。

2. Administrator パースペクティブに切り替えます。

3. 「Workloads」>「DeploymentConfigs」 に移動します。

4. example-health プロジェクトを選択します。

5. patient-health-frontend の「 Actions 」メニュー (縦に並んだ 3 つのドット) から、「 Edit DeploymentConfig 」を選択します。

   

6. 「YAML view」 の下で、「spec」>「template」>「spec」>「containers」 のセクションを見つけ、空のリソースに以下のリソース制限を追加します。 resources {} を置換します。YAML ではインデントが厳密に使用されるので、スペーシングが正しいことを確認してください。

             resources:
               limits:
                 cpu: 30m
                 memory: 100Mi
               requests:
                 cpu: 3m
                 memory: 40Mi
   

   変更後のスニペットを次に示します。

          ports:
            - containerPort: 8080
              protocol: TCP
          resources:
            limits:
              cpu: 30m
              memory: 100Mi
            requests:
              cpu: 3m
              memory: 40Mi
          terminationMessagePath: /dev/termination-log
   

7. 保存 して、変更を適用します。

8. 「イベント」 タブに移動して、レプリケーション・コントローラーが変更されたことを確認します。

   

自動スケーリング機能の有効化

リソース制限が構成されたので、ポッドの自動スケーリング機能を有効にすることができます。

デフォルトでは、自動スケーリング機能は、CPU またはメモリーに基づくスケーリングを実行できます。 指定した最小数から最大数までの間で、ポッド数のバランスが取られます。 ポッドの CPU 平均使用量が、定義された CPU 要求目標を上回らないように、自動スケーリング機能が、自動的にポッドを作成または削除します。 一般的には、ポッドの CPU 使用率が 50% から 90% に近づいたらスケール・アップを開始するようにします。 ここで与えている負荷には、1% を使用します。

1. 「管理者」 パースペクティブで 「Workloads」>「HorizontalPodAutoscalers」 に移動し、「Create HorizontalPodAutoscaler」 をクリックします。

   

   エディターの内容をこの yaml に置き換えます。

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: patient-hpa
     namespace: example-health
   spec:
     scaleTargetRef:
       apiVersion: apps.openshift.io/v1
       kind: DeploymentConfig
       name: patient-health-frontend
     minReplicas: 1
     maxReplicas: 10
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             averageUtilization: 1
             type: Utilization
   

2. 「作成」 をクリックします。

自動スケーリング機能のテスト

負荷をシミュレートするスクリプトを実行していないと、ポッド数は 1 のまま変わらないはずです。

1. デプロイメント構成の 「Overview」 ページを開いて確認します。 「Workloads」 > 「DeploymentConfigs」 をクリックし、patient-health-frontend をクリックしてから、「Details」 パネルが選択されていることを確認します。

2. 負荷のシミュレートを開始します (アプリケーションに対する負荷をシミュレートするには、前のセクションを参照してください)。

   

   自動スケーリング機能による調整が行われるまでに数分かかることがあります。

これで完了です。 これで、可用性が高く、自動的にスケーリングされるフロントエンド Node.js アプリケーションができました。 Red Hat OpenShift は、ポッドの CPU 使用率がリソース制限の 1%（ 30 ミリコア）を大幅に超えたため、アプリケーションポッドを自動的にスケーリングします。

コマンド・ラインからの自動スケーリング

コマンド・ラインでも自動スケーリング機能などのリソースを削除および作成できます。

1. まずは、コンテキストが対象プロジェクトであることを確認します。

   oc project example-health
   

2. 先ほど作成した自動スケーリング機能を取得します。

   oc get hpa
   

3. 先ほど作成した自動スケーリング機能を削除します。

   oc delete hpa/patient-hpa
   

4. 最大ポッド数を 9 にして新しい自動スケーリング機能を作成します。

   oc autoscale deploymentconfig/patient-health-frontend --name patient-hpa --min 1 --max 9 --cpu-percent=1
   

5. デプロイメントの 「Workloads」>「DeploymentConfigs」patient-health-frontendの詳細ページに再び移動します。

IBM Cloud Operator の有効化

オペレーターの機能について正確に理解しましょう。 最初の演習では、ビルダーを使用して、 DeploymentConfig Red Hat OpenShiftに付属しているデフォルトのリソース・タイプを使用して単純アプリケーションをデプロイしました。 カスタムリソース定義では、 IBM Cloud サービスのような、 Red Hat OpenShift on IBM Cloud にプリインストールされていないリソースタイプを作成できます。 オペレーターは、リソースのライフサイクルを管理し、カスタム・リソース記述子 (CRD) を作成して、ネイティブの「Kubernetes」のようにカスタム・リソースを管理することを可能にします。

1. 「Administrator」 パースペクティブで、「Operators」>「OperatorHub」 をクリックします。
2. 「IBM Cloud Operator」 を見つけて、「Install」 をクリックします。
3. デフォルトのオプションのまま、「Install」 をクリックします。
4. 数秒後に、 installed operator - ready for use が表示されます。

CRD を使用した Cloudant のサービスとバインドの作成

クリックして開きます。 「Prerequisites」 セクションまでスクロールダウンします。

このセクションでは、IBM Cloudant データベースを作成するために適切な権限を持つ API キーが必要です。 API キーは、Kubernetes のシークレット・リソースに保管されます。 このリソースはシェルを使用して作成する必要があります。 インストールされたオペレーターの 「Prerequisites」 セクションに手順が表示されています。 ステップ:

1. クラスターに関連付けられているのと同じリソース・グループとリージョンを使用してください。

   ibmcloud target -g <resource_group> -r <region>
   

   アカウント内のリソース・グループを表示するには、ibmcloud resource groups コマンドを実行します。

2. リソース・グループとリージョンがクラスターと一致していることを確認します。 以下のコマンドを実行すると、クラスターが返されます。

   ibmcloud oc cluster ls
   

次のような出力になります。

$ ibmcloud oc cluster ls
OK
Name      ID                     State    Created        Workers   Location   Version                  Resource Group Name   Provider
osmicro   ck68svdd0vvcfs6ad9ag   normal   18 hours ago   2         Dallas     4.12.26_1562_openshift   default               vpc-gen2

3. IBM 提供のヘルパー・スクリプトを使用して、以下のリソースを作成します。

   • IBM Cloud を使用するユーザーとその権限を表す、IBM Cloud の API 鍵。
   • secret-ibm-cloud-operator 名前空間の default という名前の Kubernetes シークレット。 このシークレットには、api-key と region というキーが入っています。 オペレーターは、このデータを使用して Cloudant サービス・インスタンスを作成します。
   • リージョンとリソース・グループを保持するための、config-ibm-cloud-operator 名前空間にある default という名前の Kubernetes ConfigMap リソース。

   次の curl コマンドを使用します。

   curl -sL https://raw.githubusercontent.com/IBM/cloud-operators/master/hack/configure-operator.sh | bash
   

4. Red Hat OpenShift Web コンソールに戻り、「IBM Cloud Operator」 ページの 「Installed Operators」 上にある 「Service」 タブの下の 「Create Service」 をクリックし、「YAML view」 を選択して、YAML エディターを表示します。

5. serviceClass は cloudantnosqldb に、plan は lite または standard のいずれかに置き換えます (Lite プランは 1 アカウントにつき 1 つのみ利用できます)。 <your-initials> を置き換えます。

   apiVersion: ibmcloud.ibm.com/v1
   kind: Service
   metadata:
     annotations:
      ibmcloud.ibm.com/self-healing: enabled
     name: <your-initials>-cloudant-service
     namespace: example-health
   spec:
     serviceClass: cloudantnosqldb
     plan: standard
   

6. 「作成」 をクリックして IBM Cloudant データベース・インスタンスを作成します。 「Administrator」 パースペクティブの 「Operators」 > 「Installed Operators」 > 「IBM Cloud Operator」 で、「Service」 パネルに「Project: example-health」が表示されているはずです。

7. 作成したばかりの -cloudant-serviceをクリックすると、時間の経過とともに状態フィールドがプロビジョニングから オンラインに変わります。

8. 先ほど作成した Cloudant サービス・リソースに対するバインディング・リソースとシークレット・リソースを作成します。 「Operators」 > 「Installed Operators」 > 「IBM Cloud Operator」 > 「Binding」 タブに戻ります。 「Binding」 タブを開き、「Create Binding」 をクリックし、「YAML View」 を選択します。 serviceName <your-initials>-cloudant-service (先ほど作成した サービス に指定した名前) に関連付けられる cloudant-binding を作成します。

   apiVersion: ibmcloud.ibm.com/v1
   kind: Binding
   metadata:
     name: cloudant-binding
     namespace: example-health
   spec:
     serviceName: <your-initials>-cloudant-service
   

9. オプションとして、Red Hat OpenShift のリソース( サービス 、サービスの バインディング 、バインディングの シークレット ) と IBM Cloud のリソース ( サービス 、サービスのインスタンス、インスタンスのサービス資格情報) の関係について、もう少し詳しく確認します。 Cloud シェルで以下のようにします。

   ibmcloud resource service-instances --service-name cloudantnosqldb
   

   YOURINITIALS=<your-initials>
   

   ibmcloud resource service-instance $YOURINITIALS-cloudant-service
   

   ibmcloud resource service-keys --instance-name $YOURINITIALS-cloudant-service --output json
   

   次のような出力になります。

   youyou@cloudshell:~$ ibmcloud resource service-instances --service-name cloudantnosqldb
   Retrieving instances with type service_instance in all resource groups in all locations under ..
   OK
   Name                           Location   State    Type
   <your-initials>-cloudant-service               us-south   active   service_instance
   youyou@cloudshell:~$ ibmcloud resource service-instance <your-initials>-cloudant-service
   Retrieving service instance <your-initials>-cloudant-service in all resource groups under ...
   OK
   
   Name:                  <your-initials>-cloudant-service
   ID:                    crn:v1:bluemix:public:cloudantnosqldb:us-south:a/0123456789507a53135fe6793c37cc74:SECRET
   GUID:                  SECRET
   Location:              us-south
   Service Name:          cloudantnosqldb
   Service Plan Name:     standard
   Resource Group Name:   Default
   State:                 active
   Type:                  service_instance
   Sub Type:
   Created at:            2020-05-06T22:39:25Z
   Created by:            youyou@us.ibm.com
   Updated at:            2020-05-06T22:40:03Z
   Last Operation:
                       Status       create succeeded
                       Message      Provisioning is complete
                       Updated At   2020-05-06 22:40:03.04469305 +0000 UTC
   
   youyou@cloudshell:~$ ibmcloud resource service-keys --instance-name $YOURINITIALS-cloudant-service --output json
   [
       {
           "guid": "01234560-902d-4078-9a7f-20446a639aeb",
           "id": "crn:v1:bluemix:public:cloudantnosqldb:us-south:a/0123456789507a53135fe6793c37cc74:SECRET",
           "url": "/v2/resource_keys/01234560-902d-4078-9a7f-20446a639aeb",
           "created_at": "2020-05-06T23:03:43.484872077Z",
           "updated_at": "2020-05-06T23:03:43.484872077Z",
           "deleted_at": null,
           "name": "cloudant-binding",
           "account_id": "0123456789507a53135fe6793c37cc74",
           "resource_group_id": "01234567836d49029966ab5be7fe50b5",
           "source_crn": "crn:v1:bluemix:public:cloudantnosqldb:us-south:a/0123456789507a53135fe6793c37cc74:SECRET",
           "state": "active",
           "credentials": {
               "apikey": "SECRET",
               "host": "SECRET",
               "iam_apikey_description": "Auto-generated for key SECRET",
               "iam_apikey_name": "cloudant-binding",
               "iam_role_crn": "SECRET",
               "iam_serviceid_crn": "SECRET",
               "password": "SECRET",
               "port": 443,
               "url": "https://01234SECRET",
               "username": "01234567-SECRET"
           },
           "iam_compatible": true,
           "resource_instance_url": "/v2/resource_instances/SECRET",
           "crn": "crn:v1:bluemix:public:cloudantnosqldb:us-south:a/0123456789507a53135fe6793c37cc74:SECRET"
       }
   ]
   

Node.js Patient バックエンド・データベース・アプリのデプロイ

次は、Cloudant DB に患者データを取り込む Node.js アプリを作成します。 これは、先ほどデプロイしたフロントエンド・アプリケーションにもデータを提供します。

1. プロジェクト example-health を選択した状態にします。

   oc project example-health
   

2. 次の new-app コマンドを実行すると、ビルド構成とデプロイメント構成が作成されます。 追加アプリケーションの CLI 呼び出しを以下に示します (フロントエンドでは GUI コンソールを使用したことを思い出してください)。

   oc new-app --name=patient-health-backend --as-deployment-config registry.access.redhat.com/ubi9/nodejs-20-minimal:latest~https://github.com/IBM-Cloud/patient-health-backend
   

3. コンソールに戻り、「開発者」 パースペクティブの トポロジー ・ビューで、「patient-health-backend」 アプリを開き、ビルドが完了するのを待ちます。 ポッド の起動に失敗していることが分かります。 ポッド のログをクリックすると、次のように表示されます。

   > node app.js
   
   /opt/app-root/src/app.js:23
            throw("Cannot find Cloudant credentials, set CLOUDANT_URL.")
            ^
   Cannot find Cloudant credentials, set CLOUDANT_URL.
   

4. この問題を解決しましょう。環境変数 DeploymentConfig に、オペレーターのバインディング・セクションで先ほど作成した cloudant-binding シークレットを設定します。 アプリをクリックし、DC の隣の名前を選択して、patient-health-backend アプリのデプロイメント構成に移動します。

   

5. 「Environment」 タブに移動し、「Add from ConfigMap or Secret」 をクリックし、CLOUDANT_URL という名前の新しい環境変数を作成します。 cloudant-binding シークレットを選択したら、キーに url を選択します。 保存 をクリックします。

   

6. 「Topology」 タブに戻り、patient-health-backend をクリックします。 すぐに 「Pods」 セクションに 「Running」 と表示されるはすです。 実行中のポッドの横にある 「View logs」 をクリックし、作成されたデータベースに注目します。

Patient Health Backend アプリを使用するための Patient Health Frontend アプリの構成

patient-health-frontend アプリケーションには、バックエンド・マイクロサービスの URL を表す環境変数があります。

1. フロントエンドの DeploymentConfig で、その API_URL 環境変数を default に設定します。 patient-health-frontend「Topology」 ビューでフロントエンド・アプリをクリックし、 DC の隣の名前を選択して、 アプリのデプロイメント構成に移動します。

2. 「Environment」 タブに移動し、「Single values (env)」 セクションで、API_URL という名前と値 default を追加します。 「Save」 、「Reload」 の順にクリックします。 これにより、http://patient-health-backend:8080/ への接続が確立されます。これは、ポッド・ログで確認できます。 次のコマンドの Pod Template / Containers / Port という出力を探して、これが正しいポートであることを確認できます。

   oc describe dc/patient-health-backend
   

これで、アプリケーションは、Cloudant DB に保管された疑似患者のデータに基づいて動作するようになりました。 Cloudant DB に保管された任意のユーザー ID/パスワード (例: opall:opall ) を使用してログインできるようになりました。

1. 実際のアプリケーションでは、このようなパスワードをプレーン・テキストで保管 してはいけません 。 Cloudant DB の患者（および代替ログイン）を確認するには、 IBM Cloud Resource List の services に移動します。 -cloudant-serviceをクリックします。
2. 「Launch Dashboard」 ボタンをクリックして Cloudant ダッシュボードを起動し、patients db をクリックします。
3. クリックすると、さまざまな患者としてログインできます。

事前定義されたモニタリング・ビューとダッシュボードの表示

ビューとダッシュボードを使用して、インフラストラクチャー、アプリケーション、およびサービスをモニターできます。 事前定義されたダッシュボードを使用できます。 また、Web UI を使用するか、またはプログラムで、カスタム・ダッシュボードを作成することもできます。 ダッシュボードをバックアップおよび復元するには、Python スクリプトを使用します。

以下の表は、さまざまなタイプの事前定義ダッシュボードを示しています。

Monitoring ダッシュボードの表示

1. Red Hat OpenShift on IBM Cloud クラスターに移動し、Red Hat OpenShift クラスターに注目します
2. ご使用のクラスターをクリックし、左側の 「概要」 タブが選択されていることを確認します
3. 「モニター」 の横の 「統合」 セクションで、 「起動」 ボタンをクリックします。

新しく作成した 「モニタリング」 インスタンスに、使用可能な初期データがない場合があります。

• 数分経過すると、生データが表示されます
• 約 1 時間後、索引が作成されて、このチュートリアルを進めるのに必要な詳しい情報が提供されます

1. Dashboards］ セクションで、 ［ Kubernetes ］>［Pod Status & Performance］を選択して、クラスタ上で実行されているすべてのワークロードの生のメトリクスを表示します。
2. namespace フィルターを example-health に設定して、アプリケーションのポッドにフォーカスします。
3. 左側ペインの 「Dashboards」 で、「Dashboard Templates」 の 「Applications」 を展開します。 次に、「HTTP」 を選択してクラスターの HTTP 負荷の概要を取得します。

クラスターとノードの容量の調査

1. 「Dashboards」 を選択し、以下の 2 つのダッシュボード・テンプレートを確認します。

   • 「Containers」>「Container Resource Usage」
   • 「Host Infrastructure」>「Host Resource Usage」

2. Kubernetes > 「ポッド・ライトサイジング (Pod Rightsizing)」&「ワークロード・キャパシティーの最適化 (Workload Capacity Optimization)」 テンプレートを選択します。 このダッシュボードは、ポッドのサイズが正しく設定されていることを確認することで、インフラストラクチャーを最適化し、クラスターの支出をより適切に制御するのに役立ちます。 メモリーまたは CPU (あるいはその両方) の要求を減らすことによって、リソースを解放できるかどうかを理解します。

アプリケーションの詳細はこちら

1. 「ダッシュボード」 およびテンプレート Kubernetes >「ワークロード状況」&「パフォーマンス」 を選択します。

   クラスター内のすべてのポッドを示す詳細ダッシュボード。

2. カスタマイズされたダッシュボードを作成し、対象範囲として特定の名前空間を設定します。

   • 右上にある 「マイ・ダッシュボードにコピー」 をクリックして、 Workload Status & Performanceapp example-health という名前を付けます。
   • 「作成して開く」 をクリックして、独自のダッシュボードを作成します。
   • ダッシュボードの範囲を編集します。
   • kube_namespace_name、 is、 example-health のフィルターを設定します。
   • 保存 をクリックします。

   ダッシュボードに、example-health 名前空間に焦点を当てた情報が表示されるようになりました。

   HTTP、レイテンシ、エラー TimeChartsまでスクロールダウンして、アプリケーションのパフォーマンスを理解してください。

   

IBM Cloud Monitoring については、IBM Cloud 資料に詳しく記載されています。