機械翻訳について

スケーリング

このドキュメントでは、Kubernetes環境でWebLogicクラスタをスケーリングする方法を説明します。

目次

概要

WebLogic Serverでは、構成済および動的の2つのタイプのクラスタリング構成がサポートされます。 構成済クラスタは、個々の管理対象サーバー・インスタンスを定義することで作成されます。 動的クラスタでは、管理対象サーバー構成は単一の共有テンプレートから生成されます。 動的クラスタでは、追加のサーバー容量が必要な場合に、新しいサーバー・インスタンスを個別に構成しなくてもクラスタに追加できます。 また、構成済クラスタとは異なり、動的クラスタのスケール・アップは、クラスタに定義されているサーバーのセットに制限されませんが、実行時の要求に基づいて増やすことができます。 WebLogic Serverで動的クラスタを作成、構成および使用する方法の詳細は、「動的クラスタ」を参照してください。

WebLogic Kubernetes Operator 4.0では、新しいカスタム・リソースClusterが導入されています。 「クラスタ・リソース」は、個々のWebLogicクラスタとその構成を参照します。 また、実行されているメンバー・サーバーの数と、そのWebLogicクラスタに固有の追加のKubernetesリソースも制御します。 クラスタ・リソースによってKubernetes 「サブリソースをスケーリング」が有効になるため、kubectl scaleコマンドおよび「Kubernetes水平ポッド自動スケーリング(HPA)」は、個々のWebLogicクラスタのスケーリングで完全にサポートされます。

オペレータは、次のようなWebLogicクラスタのスケーリングを開始する方法をいくつか提供します:

kubectl CLIコマンド

次のコマンドを使用して、WebLogicクラスタを手動でスケーリングするには、Kubernetesコマンドライン・ツールkubectlを使用します:

  • scale - リソースの新しいサイズを設定します。
  • patch - 戦略マージ・パッチを使用して、リソースの1つ以上のフィールドを更新します。

kubectl scaleコマンド

kubectl scaleコマンドを使用して、個々のWebLogicクラスタを直接スケーリングできます。 たとえば、次のコマンドは、クラスタ・リソースcluster-1.spec.replicas5に設定します:

$ kubectl scale --replicas=5 clusters/cluster-1
  clusters "cluster-1" scaled

$ kubectl get clusters cluster-1 -o jsonpath='{.spec.replicas}'
  5

kubectl patchコマンド

また、パッチ・オブジェクトをインラインでkubectl patchコマンドを使用して、個々のWebLogicクラスタを直接スケーリングできます。 たとえば、次のコマンドは、クラスタ・リソースcluster-1.spec.replicas3に設定します:

$ kubectl patch cluster cluster-1 --type=merge -p '{"spec":{"replicas":3}}'
  cluster.weblogic.oracle/cluster-1 patched

$ kubectl get clusters cluster-1 -o jsonpath='{.spec.replicas}'
  3

オンデマンドで、クラスタまたはドメインを直接更新

クラスタまたはドメイン・リソースの.spec.replicasフィールドを直接更新することで、オンデマンド・スケーリング(クラスタを手動でスケーリング)を使用できます。

クラスタの直接更新

個々のWebLogicクラスタを直接スケーリングするには、関連付けられたクラスタ・リソースのreplicasフィールドを編集するだけです。この操作は、kubectlを使用して実行できます。 具体的には、kubectl editコマンドを使用してクラスタを直接変更できます。 例えば:

$ kubectl edit cluster cluster-1 -n [namespace]

このコマンドでは、cluster-1という名前のクラスタを編集します。 kubectl editコマンドは、エディタでクラスタ定義を開き、replicas値を直接変更できます。 コミットされると、オペレータは変更を通知され、実行中のポッド/管理対象サーバー・インスタンスの数とreplicas値の指定を調整して、対応するクラスタのスケーリングをすぐに試行します。

spec:
  ...
  clusterName: cluster-1
  replicas: 1
  ...

ドメインを直接更新

対応するクラスタ・リソースがない、またはcluster.spec.replicasフィールドを指定しないクラスタ・リソースがあるドメイン内のすべてのWebLogicクラスタをスケーリングするには、kubectl editコマンドを使用してdomain.spec.replicasフィールドを変更します:

$ kubectl edit domain domain1 -n [namespace]

このコマンドでは、domain1という名前のドメインを編集します。 kubectl editコマンドは、エディタでドメイン定義を開き、replicas値を直接変更できます。 コミットされると、オペレータは変更の通知を受け、実行中のポッド/管理対象サーバー・インスタンスの数をreplicas値指定と調整して、対応するクラスタまたはクラスタのスケーリングをただちに試行します。

spec:
  ...
  replicas: 1
  ...

ドメインのライフサイクル・サンプル・スクリプトの使用

バージョン3.1.0以降、オペレータはサンプルのライフサイクル・スクリプトを提供します。 WebLogicクラスタのスケーリングに使用できるヘルパー・スクリプトについては、「ドメイン・ライフサイクルのサンプル・スクリプト」の項を参照してください。

オペレータのRESTスケールAPIのコール

WebLogicクラスタのスケール・アップまたはスケール・ダウンにより、カスタマ・アプリケーションの信頼性が向上し、リソース使用率が最適化されます。 Kubernetes環境では、WebLogicクラスタのスケーリングには、管理対象サーバー・インスタンスが実行されている対応するポッドの数のスケーリングが含まれます。 オペレータはWebLogicドメインのライフ・サイクルを管理するため、認可されたアクターがWebLogicクラスタのスケーリングをリクエストできるREST APIを公開します。

次のURL形式は、WebLogicクラスタをスケール・アップ(またはスケール・ダウン)するためのリソースの記述に使用されます:

http(s)://${OPERATOR_ENDPOINT}/operator/<version>/domains/<domainUID>/clusters/<clusterName>/scale

例えば:

http(s)://${OPERATOR_ENDPOINT}/operator/v1/domains/domain1/clusters/cluster-1/scale

このURL形式では、次のようになります:

  • OPERATOR_ENDPOINTは、オペレータのRESTエンドポイント(内部または外部)のホストおよびポートです。
  • <version>は、RESTリソースのバージョンを示します。
  • <domainUID>は、WebLogicドメインの一意の識別子です。
  • <clusterName>は、スケーリングするWebLogicクラスタの名前です。

/scale RESTエンドポイントはHTTP POSTリクエストを受け入れ、リクエスト本文はJSON "application/json"メディア・タイプをサポートします。 リクエスト本文は、Kubernetes自動スケーリングのScaleSpecアイテムと同じです。次に例を示します:

{
    "spec":
    {
       "replicas": 3
    }
}

replicas値は、スケーリングする管理対象サーバー・インスタンスの数を指定します。 スケーリング・リクエストが成功すると、RESTインタフェースは204 (“No Content”)のHTTPレスポンス・コードを返します。

/scale RESTエンドポイントにPOSTする場合、次のヘッダーを送信する必要があります:

  • X-Requested-Byリクエスト値。 値は、MyClientなどの任意の名前です。
  • Authorization: Bearerリクエスト値。 Bearerトークンの値は、WebLogicドメイン・サービス・アカウント・トークンです。

たとえば、curlを使用する場合は、次のようにします:

$ curl -v -k -H X-Requested-By:MyClient -H Content-Type:application/json -H Accept:application/json -H "Authorization:Bearer ..." -d '{ "spec": {"replicas": 3 } }' https://.../scaling

ヘッダーを省略すると、400 (bad request)レスポンスが返されます。 Bearer認証ヘッダーを省略すると、401 (Unauthorized)レスポンスが返されます。 Bearerトークンに関連付けられているサービス・アカウントまたはユーザーにWebLogicドメイン・リソースをpatchする権限がない場合は、403 (Forbidden)レスポンスが返されます。

403 (Forbidden)レスポンスを解決するには、オペレータのRESTスケーリングAPIをコールするときに、WebLogic domainsリソースに関連付けられたクラスタ・ロールにpatchリクエスト動詞を追加する必要がある場合があります。 次の例のClusterRole定義は、get, list, patchおよびupdateにWebLogic domainsリソースへのアクセス権を付与

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: weblogic-domain-cluster-role
rules:
- apiGroups: [""]
  resources: ["services/status"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["weblogic.oracle"]
  resources: ["domains"]
  verbs: ["get", "list", "patch", "update"]
---

オペレータのRESTエンドポイント

WebLogic Kubernetes Operatorは、内部および外部のREST HTTPSエンドポイントの両方を公開できます。 内部RESTエンドポイントは、Kubernetesクラスタ内からのみアクセスできます。 外部RESTエンドポイントは、Kubernetesクラスタの外部からアクセスできます。 内部RESTエンドポイントはデフォルトで有効になっているため、常に使用可能ですが、外部RESTエンドポイントはデフォルトで無効になっており、明示的に構成されている場合にのみ公開されます。 外部RESTエンドポイントの構成手順の詳細は、「こちら」を参照してください。

どのエンドポイントが呼び出されているかにかかわらず、スケーリングのURL形式は同じです。

スケーリング・リクエストに応じてオペレータは何を行いますか。

オペレータは、スケーリング・リクエストを受信すると、次のことを行います:

  • 認証および認可チェックを実行して、指定されたユーザーが指定されたリソースに対して指定された操作を実行できることを確認します。
  • domainUIDで識別される指定されたドメインが存在することを検証します。
  • clusterNameで識別されるWebLogicクラスタが存在することを検証します。
  • 指定したWebLogicクラスタに、スケーリング・リクエストを満たすのに十分な数の構成済サーバーまたは十分な動的クラスタ・サイズがあることを確認してください。
  • 指定したクラスタに対応するクラスタ・リソースが定義されていることを確認するか、必要に応じてクラスタ・リソースを作成します。
  • 対応するクラスタ・リソース内でreplicasフィールドを設定して、スケーリングを開始します。

Clusterリソースのreplicasフィールドの変更に応じて、オペレータは、必要なレプリカ数と一致するように管理対象サーバー・インスタンス・ポッドの数を増減します。

サポートされている自動スケーリング・コントローラ

WebLogic診断フレームワーク(WLDF)およびPrometheusを使用したWebLogicクラスタの自動スケーリングは引き続きサポートされますが、オペレータ4.0は「Kubernetes水平ポッド自動スケーリング(HPA)」をサポートするようになりました。

Kubernetes水平ポッド自動スケーリング(HPA)

クラスタ・カスタム・リソースでKubernetes 「/scaleサブリソース」が有効になっているため、Kubernetes Horizontal Pod Autoscalerによる個々のWebLogicクラスタの自動スケーリングがサポートされるようになりました。 リソース・メトリクスに基づく自動スケーリングには、「Kubernetesメトリクス・サーバー」またはリソース・メトリクスAPIの別の実装のインストールが必要です。 WebLogic ServerメトリクスのモニタリングにPrometheusを使用する場合は、「Kubernetesメトリクス・サーバー」のかわりに「Prometheusアダプタ」を使用できます。

次のステップごとの例は、cpu utilizationリソース・メトリックに基づいてWebLogicクラスタcluster-1をスケーリングするHPAを構成および実行する方法を示しています。

  1. CPU使用率に基づいたWebLogicクラスタのスケーリングを示すには、Kubernetesメトリクス・サーバーをKubernetesクラスタにデプロイします。
$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
  1. kube-systemネームスペースのポッドをリストして、Kubernetesメトリック・サーバーが実行中であることを確認します。
$ kubectl get po -n kube-system

Kubernetesメトリック・サーバーがReadiness probe failed: HTTP probe failed with statuscode: 500のためにREADY状態(たとえば、READY 0/1)に達していない場合は、有効なクラスタ証明書をインストールする必要がある場合があります。 テストのために、components.yamlファイルをダウンロードし、引数--kubelet-insecure-tlsをメトリクス・サーバー・コンテナに追加することで、この問題を解決できます。

  1. デフォルト・ネームスペースで実行されているWebLogicドメインの場合、次のコマンドを使用して、WebLogic Serverインスタンスを2クラスタ・メンバーから5クラスタ・メンバーまで自動スケーリングするクラスタ・リソース(sample-domain1-cluster-1)をターゲットとするHPAリソースを作成し、平均CPUが一貫して50%を超えるとスケール・アップまたはスケール・ダウンが行われます。
$ kubectl autoscale cluster sample-domain1-cluster-1 --cpu-percent=50 --min=2 --max=5
  horizontalpodautoscaler.autoscaling/sample-domain1-cluster-1 autoscaled

オペレータ4.0から、allowReplicasBelowMinDynClusterSizeフィールドがドメイン・リソース・スキーマから削除されました。 スケール・ダウン時には、選択した自動スケーリング・コントローラで許容される最小レプリカ数を構成する必要があります。

  1. HPAリソースを検査して、自動スケーラのステータスとその動作を確認します。
$ kubectl get hpa
  NAME                       REFERENCE                          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
  sample-domain1-cluster-1   Cluster/sample-domain1-cluster-1   8%/50%    2         5         2          3m27s
  1. HPAがWebLogicクラスタsample-domain1-cluster-1をスケール・アップしていることを確認するには、クラスタ・メンバー・ポッドの1つで実行中のコンテナにシェルを取得して、ロードされたCPUを生成し、次のコマンドを実行します。
$ kubectl exec --stdin --tty sample-domain1-managed-server1 -- /bin/bash
  [oracle@sample-domain1-managed-server1 oracle]$ dd if=/dev/zero of=/dev/null
  1. 管理対象サーバーのポッドをリストすると、クラスタ・リソースのレプリカが自動スケーラによって増加し、オペレータが追加のクラスタ・メンバー・サーバーを起動して応答することがわかります。 逆に、負荷を停止した後、CPU使用率の平均が一貫して50%未満になると、自動スケーラは、クラスタ・リソースのレプリカ値を減らしてWebLogicクラスタをスケール・ダウンします。

Kubernetes Horizontal Pod Autoscalerの詳細は、「水平ポッド自動スケーリング」を参照してください。

WLDFポリシー・ルールおよびスクリプト・アクションを使用したオペレータのRESTスケールAPIの呼出し

WebLogic Diagnostics Framework (WLDF)は、サーバーおよびアプリケーションのパフォーマンスを可視化するメトリックを収集および表示する一連のサービスおよびAPIです。 KubernetesでWebLogicクラスタの自動スケーリングをサポートするために、WLDFには、クラスタでスケーリング操作を自動的に実行するためのポリシー式を記述できるポリシーおよびアクション・コンポーネントが用意されています。 これらのポリシーは、メモリー、アイドル・スレッド、CPU負荷など、1つ以上のタイプのWebLogic Serverメトリックを監視します。 ポリシーで構成されたしきい値に達すると、ポリシーがトリガーされ、対応するスケーリング・アクションが実行されます。 WebLogic Kubernetes Operatorプロジェクトは、スクリプト・アクションとして使用するためのシェル・スクリプトscalingAction.shを提供します。これは、オペレータのRESTエンドポイントにリクエストを発行する方法を示しています。

オペレータ・バージョン4.0.5以降、オペレータのRESTエンドポイントはデフォルトで無効になっています。 Helmインストール・オプション--set "enableRest=true"を指定してオペレータをインストールし、RESTエンドポイントを有効にします。

WLDFを使用したKubernetesでのWebLogicクラスタの自動スケーリングの構成

オペレータのRESTエンドポイントにスケーリング・リクエストを発行するためのWLDFポリシーおよびスクリプト・アクション・コンポーネントの構成方法に関するガイドラインとして、次のステップを示します:

  1. scalingAction.shスクリプトを$DOMAIN_HOME/bin/scriptsにコピーして、管理サーバーポッド内でアクセスできるようにします。 詳細は、「Oracle WebLogic ServerのためのDiagnostics Frameworkの構成および使用」「スクリプト・アクションの構成」を参照してください。

  2. WLDFポリシーおよびアクションを、管理サーバーにターゲット指定された診断モジュールの一部として構成します。 WLDFポリシーおよびアクション・コンポーネントの構成の詳細は、「Oracle WebLogic ServerのためのDiagnostics Frameworkの構成および使用」での「ポリシーおよびアクションの構成」を参照してください。

    a. メモリー、アイドル・スレッド、CPU負荷などのWebLogic Serverメトリックをモニタリングするためのルール式を使用してWLDFポリシーを構成します。

    b. WLDFスクリプト・アクションを構成し、scalingAction.shスクリプトを関連付けます。

スクリプト・アクションの構成プロパティに関する重要なノート:

scalingAction.shスクリプトでは、オペレータのエンドポイントのSSL証明書にアクセスする必要があり、これは環境変数INTERNAL_OPERATOR_CERTを介して提供されます。
オペレータSSL証明書は、オペレータConfigMap weblogic-operator-cminternalOperatorCertエントリにあります:

例えば:

#> kubectl describe configmap weblogic-operator-cm -n weblogic-operator
...
Data
====
internalOperatorCert:
----
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR3akNDQXFxZ0F3SUJBZ0lFRzhYT1N6QU...
...

scalingAction.shスクリプトは、いくつかのカスタマイズ可能なパラメータを受け入れます:

  • action - scaleUpまたはscaleDown (必須)

  • domain_uid - WebLogicドメインの一意の識別子(必須)

  • cluster_name - WebLogicクラスタ名(必須)

  • kubernetes_master - KubernetesマスターURL、default=https://kubernetes

管理サーバーのポッドからscalingAction.shを起動する場合は、これをhttps://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}に設定します。

  • access_token - RESTリソースにアクセスするための認証および認可用のサービス・アカウントBearerトークン

  • wls_domain_namespace - WebLogicドメインが定義されているKubernetesネームスペース(デフォルト= default)

  • operator_service_name - WebLogic Kubernetes Operator RESTエンドポイントのサービス名、default=internal-weblogic-operator-service

  • operator_service_account - オペレータのKubernetesサービス・アカウント名 (デフォルト=weblogic-operator)

  • operator_namespace - オペレータがデプロイされているネームスペース (デフォルト=weblogic-operator)

  • scaling_size - スケール・アップまたはスケール・ダウンする管理対象サーバー・インスタンスの増分数 (デフォルト= 1)

次のツールのいずれかを使用して、診断システム・モジュール用のポリシーを構成できます。

  • WebLogic Server管理コンソール
  • WLST
  • REST
  • JMXアプリケーション

WLDFのポリシーおよびアクション・コンポーネントを使用して、オペレータのRESTエンドポイントを介してスケーリング・リクエストを開始する方法の詳細および例は、ブログを参照してください:

ネームスペース・ユーザーがWLS Kubernetesクラスタ情報を問い合せることができるようにClusterRoleBindingsを作成

WLDFスクリプト・アクションで指定されるスクリプトscalingAction.shには、ドメインの構成情報とランタイム情報の両方についてKubernetes APIサーバーに問合せするために、サービス・アカウント・ユーザー(WebLogicドメインがデプロイされているネームスペース)に付与される適切なRBAC権限が必要です。 適切なKubernetes ClusterRoleバインディングを作成するYAMLファイルの例を次に示します:

次の例のClusterRoleBinding定義では、WebLogicドメインはネームスペースweblogic-domainにデプロイされます。 namespace値を、Kubernetes環境でWebLogicドメインがデプロイされているネームスペースの名前に置き換えます。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: weblogic-domain-cluster-role
rules:
- apiGroups: [""]
  resources: ["services/status"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["weblogic.oracle"]
  resources: ["domains"]
  verbs: ["get", "list", "patch", "update"]
---
#
# creating role-bindings for cluster role
#
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: domain-cluster-rolebinding
subjects:
- kind: ServiceAccount
  name: default
  namespace: weblogic-domain
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: weblogic-domain-cluster-role
  apiGroup: "rbac.authorization.k8s.io"
---
#
# creating role-bindings
#
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: weblogic-domain-operator-rolebinding
  namespace: weblogic-operator
subjects:
- kind: ServiceAccount
  name: default
  namespace: weblogic-domain
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: "rbac.authorization.k8s.io"
---

WebLogicエクスポータ・メトリクスを使用したHorizontal Pod Autoscaler (HPA)

このブログ投稿を読んで、Kubernetes Horizontal Pod Autoscaler (HPA)を使用して、Monitoring Exporterによって提供されるWebLogicメトリクスに基づいてWebLogicクラスタをスケーリングする方法を学習します。 Prometheusアダプタを使用して、使用可能なメトリクスの名前を定期的にPrometheusから収集します。 アダプタのカスタム構成では、特定の形式に従うメトリクスのみが公開されます。 「WebLogicエクスポータ・メトリクスを使用したHorizontal Pod Autoscaler (HPA)」. 動作中のブログ投稿のデモについては、このビデオをご覧ください。 「Kubernetes Horizontal Pod AutoscalingのWebLogic Kubernetes Operatorサポート」

Prometheusアラート・アクションを使用したオペレータのRESTスケールAPIのコール

WebLogic診断フレームワークを使用した動的クラスタの自動スケーリングに加えて、Prometheusなどのサード・パーティのモニタリング・アプリケーションを使用できます。 「Prometheusを使用したKubernetesでのWebLogicクラスタの自動スケーリング」の詳細は、次のブログを参照してください。

役立つヒント

scalingAction.shのデバッグ

scalingAction.shスクリプトは、関連付けられた診断モジュールが管理サーバーにターゲット指定されているため、管理サーバーポッドのコンテナ内で実行されるように設計されています。

scalingAction.shスクリプトを検証およびデバッグする最も簡単な方法は、実行中の管理サーバーのポッドでシェルを開き、コマンドラインでスクリプトを実行することです。

次の例は、domain1-admin-serverという名前の実行中の管理サーバーポッドでbashシェルを開き、scriptAction.shスクリプトを実行する方法を示しています。 次のことを前提としています:

  • ドメイン・ホームは/u01/oracle/user-projects/domains/domain1内にあること(つまり、ドメイン・ホームはイメージ内にあります)。
  • Dockerfileは、scalingAction.sh/u01/oracle/user-projects/domains/domain1/bin/scripts/scalingAction.shにコピーされていること。
$ kubectl exec -it domain1-admin-server /bin/bash
$ cd /u01/oracle/user-projects/domains/domain1/bin/scripts && \
  ./scalingAction.sh

スクリプトが実行されたディレクトリと同じディレクトリにログscalingAction.logが生成され、エラーを調べることができます。

外部RESTエンドポイントへのアクセスの例

外部RESTエンドポイントを使用してスケーリングをテストする最も簡単な方法は、curlなどのコマンドライン・ツールを使用することです。 curlを使用してHTTPSスケール・リクエストを発行するには、次の必須ヘッダー・プロパティが必要です:

  • Bearer認可トークン
  • オペレータの外部RESTエンドポイントのSSL証明書
  • X-Requested-Byヘッダー値

次のシェル・スクリプトは、curlを使用して、必要なHTTPリクエスト・ヘッダー値でスケーリング・リクエストを発行する方法の例です。 この例では、オペレータおよびドメインYAMLファイルがKubernetesの次のフィールドで構成されていることを前提としています:

  • オペレータ・プロパティ:
    • externalRestEnabled: true
    • externalRestHttpsPort: 31001
    • オペレータのネームスペース: weblogic-operator
    • operatorのホスト名は、ホスト・シェル・スクリプトが実行されるホスト名と同じです。
  • ドメイン・フィールド:
    • WebLogicクラスタ名: ApplicationCluster
    • ドメインUID: domain1
#!/bin/sh
# Setup properties  
ophost=`uname -n`
opport=31001 #externalRestHttpsPort
cluster=cluster-1
size=3 #New cluster size
ns=weblogic-operator # Operator NameSpace
sa=weblogic-operator # Operator ServiceAccount
domainuid=domain1

# Retrieve service account name for given namespace   
sec=`kubectl get serviceaccount ${sa} -n ${ns} -o jsonpath='{.secrets[0].name}'`
#echo "Secret [${sec}]"

# Retrieve base64 encoded secret for the given service account   
enc_token=`kubectl get secret ${sec} -n ${ns} -o jsonpath='{.data.token}'`
#echo "enc_token [${enc_token}]"

# Decode the base64 encoded token  
token=`echo ${enc_token} | base64 --decode`
#echo "token [${token}]"

# clean up any temporary files
rm -rf operator.rest.response.body operator.rest.stderr operator.cert.pem

# Retrieve SSL certificate from the Operator's external REST endpoint
`openssl s_client -showcerts -connect ${ophost}:${opport} </dev/null 2>/dev/null | openssl x509 -outform PEM > operator.cert.pem`

echo "Rest EndPoint url https://${ophost}:${opport}/operator/v1/domains/${domainuid}/clusters/${cluster}/scale"

# Issue 'curl' request to external REST endpoint  
curl --noproxy '*' -v --cacert operator.cert.pem \
-H "Authorization: Bearer ${token}" \
-H Accept:application/json \
-H "Content-Type:application/json" \
-H "X-Requested-By:WLDF" \
-d "{\"spec\": {\"replicas\": $size} }" \
-X POST  https://${ophost}:${opport}/operator/v1/domains/${domainuid}/clusters/${cluster}/scale \
-o operator.rest.response.body \
--stderr operator.rest.stderr