https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes%2c-try-it
WebLogicチームは、KubernetesでオーケストレーションされるWebLogicドメインの動作検証作業を実施中です。この作業の一環として、Kubernetes環境でWebLogicドメイン/クラスタをデプロイするサンプルを作成しました。これは、KubernetesとWebLogicの両方を使用してクラスタをスケールアウト・スケールインするものです。
WebLogic on Kubernetes SampleWebLogic Serverには、サーバ、アプリケーション、およびリソースを監視および診断するための豊富な機能が用意されています。このサンプルでは、これらの指標をPrometheusを通して公開し、Grafanaに表示します。Prometheusが理解できる形式でWebLogicメトリックを公開するためのWebLogic Exporterを作成しました。
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s
（訳注）
WebLogic Server on K8sは、現在動作検証中で、OpenWorld 2017では以下のような発表がありました。
Official #kubernetes support in 2017/2018 for WebLogic #Excited #oow17 @wlscommunity pic.twitter.com/LzAxi9k1SS— Michel Schildmeijer (@MNEMONIC01) 2017年10月4日
WebLogic on Kubernetes Sample
このサンプル構成は、Kubernetes環境のWebLogic Server 12.2.1.3ドメインクラスタのオーケストレーションを説明するものです。このサンプルでは、Kubernetes環境のWebLogicクラスタの異なるスケールアクションを紹介します。- ReplicaSetsの個数の増加・減少によりクラスタをスケールイン・スケールアウトする
- Open Session Count MBeanに基づいたWLDFポリシーを定義し、WebLogic Server管理サーバにスケールアクションを開始させる
WebLogicクラスタには2つのアプリケーションがデプロイされています。一つはOpen Sessionアプリケーションで、これはWLDFポリシーを呼び出して1つの管理対象サーバによりクラスタの規模を調整します。もう一つは、Memory Loadアプリケーションで、これはJVMのヒープ・メモリを割り当てます。
WLDFポリシーが呼び出されると、管理サーバと同じPodのコンテナ内で動作しているwebhookへの呼び出しが発生します。webhookはKubernetes APIを呼び出してKubernetes を起動し、Kubernetesクラスタを拡張します。これにより、WebLogicクラスタが拡張されます。
このサンプルの一環で、管理対象サーバから収集されたWLSランタイムMBeanメトリックを整形し、Prometheusが読んでGrafana UIに表示できる形式にして公開するWLS Exporterを開発しました。
Run Sample
このサンプルの実行手順は、Minikubeを使って説明していますが、このサンプルは任意のKubernetes環境で実行できます。minikube、kubectlがインストールされていることを確認し、WebLogic Server開発者インストールイメージであるoracle/weblogic:12.2.1.3-developerをビルドしてください。以下のGitHub上に、このイメージをビルドするためのDockerfileとスクリプトがあります。Oracle WebLogic Server on DockerこのサンプルでWebLogic 12.2.1.3ドメインイメージを作成します。
http://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
2個のWebアプリケーション（Open SessionアプリケーションとMemory Loadアプリケーション）をWebLogicクラスタにデプロイします。ドメインイメージ wls-12213-domainを拡張し、 wls-12213-oow-demo-domain イメージを作成します。$ cd wls-12213-domain $ docker build --build-arg ADMIN_PASS=<Admin Password> --build-arg ADMIN_USER=<Admin Username> -t wls-12213-domain .
WLDFポリシーが呼び出された際にクラスタをスケールするために使われるイメージ(oow-demo-webhook イメージ) であるwebhook イメージを作成します。$ docker build -t wls-12213-oow-demo-domain -f Dockerfile.adddemoapps .
Save the WebアプリケーションのDockerイメージとwebhookのDockerイメージをファイルシステム（*.tar）に保存して、minikubeレジストリにロードできるようにします。$ docker build -t oow-demo-webhook -f Dockerfile.webhook .
minikube を起動し、環境を設定します。$ docker save -o wls-12213-oow-demo-domain.tar wls-12213-oow-demo-domain $ docker save -o oow-demo-webhook.tar oow-demo-webhook
保存済みのWebアプリケーションのDockerイメージとwebhookのDockerイメージをminikubeにロードします。$ minikube start $ eval $(minikube docker-env)
OracleWebLogic/samples/wls-k8s ディレクトリから、WebLogic管理サーバと管理対象サーバを起動します。$ minikube ssh "docker load -i $PWD/wls-12213-oow-demo-domain.tar" $ minikube ssh "docker load -i $PWD/oow-demo-webhook.tar"
インスタンスが動作していることを確認しましょう。$ kubectl create -f k8s/wls-admin-webhook.yml $ kubectl create -f k8s/wls-stateful.yml
管理サーバと2個の管理対象サーバが動作していることを確認できるはずです。$ kubectl get pods
3個の全てのサーバがRunning状態になっていることを確認してから、作業を継続しましょう。NAME READY STATUS RESTARTS AGE ms-0 1/1 Running 0 3m ms-1 1/1 Running 0 1m wls-admin-server-0 1/1 Running 0 5m
サーバはminikubeのIPアドレスでアクセスできます。通常これは192.168.99.100です。以下の方法でIPアドレスを確認します。
WebLogic Server管理コンソールにログインするには、ブラウザでhttp://192.168.99.100:30001/consoleにアクセスします。WebLogic Serverドメインイメージ（wls-12213-domain）ビルド時に引数として渡した資格証明を使ってログインします。$ minikube ip 192.168.99.100
Prometheusを起動し、管理対象サーバを監視します。
http://192.168.99.100:32000を確認して、Prometheusが両管理対象サーバを監視していることを確認します。メトリックのプルダウンメニューをクリックしてwls_scrape_cpu_secondsを選択し、executeをクリックすると、各管理対象サーバから収集されたメトリックを確認できるはずです。$ kubectl create -f prometheus/prometheus-kubernetes.yml
Grafanaを起動して管理対象サーバの監視をします。
Upload and Import the file prometheus/grafana-config.jsonをアップロードしてインポートし、以前の手順で追加したデータソース（"Prometheus"）を選択します。"WLS_Prometheus"という名前のダッシュボードが生成されるはずです。$ kubectl create -f prometheus/grafana-kubernetes.yml Connect to Grafana at: http://192.168.99.100:31000 Log in with admin/pass Click "Add Data Source" and then connect Grafana to Prometheus by entering: Name: Prometheus Type: Prometheus Url: http://prometheus:9090 Access: Proxy Click the leftmost menu on the menu bar, and select Dashboards > Import.
3つのグラフ、まず「Managed Servers Up Time」、続いてWebアプリケーション「Open Session Count」、3番目に「Used Heap Current Size」がが確認できます。
Webアプリケーション“Memory Load”を実行するためには、ブラウザでhttp://192.168.99.100:30011/memoryloadappにアクセスします。"Run Memory Load"をクリックすると、メモリのスパイクの状況を"Used Heap Current Size"とラベルされたGrafanaのグラフに表示します。
kubectlを呼び出し、クラスタのレプリカの個数を増やして、Kubernetesクラスタをスケールします。
The Kubernetesクラスタには、WebLogic Serverの管理サーバとwebhookが動作する1個のPod、そして1個の管理対象サーバがそれぞれ動作する3個のPodが表示されるはずです。“kubectl get pods” を実行して、 ms-0, ms-1, ms-2 and wls-admin-server-0 を確認しましょう。$ kubectl scale statefulset ms --replicas=3
WebLogic Server管理コンソールもまたms-0、ms-1、 ms-2が実行中で、ms-3 と ms-4 が停止している状況を示しています。Prometheusは3個の管理対象サーバすべてのメトリックを表示し、Grafanaのグラフ「サーバ稼働時間」では、管理対象サーバを表す3行が表示されます。
それでは、Kubernetesクラスタを2つのレプリカにスケールダウンしましょう。
コマンド "kubectl get pods"もしくは管理コンソールを使ってスケールの確認ができます。$ kubectl scale statefulset ms --replicas=2
管理コンソールで、スケーリングイベントをトリガーするWLDFルールを定義しました。OpenSessionAppというApplicationRuntimeのWebAppComponentRuntimeMBeanのOpenSessionsCurrentCountを監視するように構成したWLDFスマートルールを定義しました。このルールは、毎秒サンプリングした過去10秒の間で、"DockerCluster"と呼ばれるWebLogicクラスタ内の5％以上のサーバで開かれたセッションの平均個数が0.01以上に達した場合、RESTアクションを呼び出すというものです。このRESTアクションでは、webhookを呼び出して、1個"ms"という名前のStatefulsetをスケールアップします。WLDF ルールは1分アラームで構成されているため、1分間に別のアクションを呼び出すことはありません。
WebアプリケーションOpen Sessionへは、ブラウザでhttp://192.168.99.100:30011/opensessionappにアクセスします。
1分もしくは2分以内に、新たなms-1インスタスが作成されます。このms-1インスタンスは管理コンソールやkubectlコマンド、grafanaで確認できます。
Grafanaに接続して、OpenSessionCountの収集メトリックをグラフ"Open Sessions Current Count"で確認します。
環境のクリーンアップの準備ができたら、以下のコマンドでサービスを停止します。
最後に、minikubeを停止します。$ kubectl delete -f prometheus/grafana-kubernetes.yml $ kubectl delete -f prometheus/prometheus-kubernetes.yml $ kubectl delete -f k8s/wls-stateful.yml $ kubectl delete -f k8s/wls-admin-webhook.yml
$ minikube stop
Summary
このサンプルでは、Kubernetes環境でのWebLogicドメインの実行を紹介しています。WebLogicチームは現在、Kubernetes上でのWebLogicドメイン/クラスタの動作検証に取り組んでいます。動作検証の一環として、KubernetesのWebLogicドメイン/クラスタの管理、アプリケーションのアップグレード、アプリケーションのアップグレード、パッチ適用、および安全なWebLogic環境のガイドラインを公開する予定です。以下のガイドラインのブログを参照してください。Security Best Practices for WebLogic Server Running in Docker and Kubernetes動作検証作業の一環で、WebLogicチームはWebLogic Kubernetes Operatorをリリースする予定です。これはKubernetes APIを拡張し、ドメインやクラスタのWebLogic Serverインスタンス、アプリケーションをKubernetesユーザーの代わりに構成、管理するものです。WebLogic Kubernetes OperatorはKubernetesの設定を知っており、Kubernetesのリソースとコントローラに立脚していますが、WebLogicデプロイメントの自動化および管理のためのWebLogicドメインやアプリケーション固有の知識も含まれています。WebLogic Kubernetes Operatorのリリースについての今後の発表と、KubernetesへのWebLogic環境のデプロイ方法とビルド方法に関するガイドラインに乞うご期待！
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes
https://orablogs-jp.blogspot.jp/2017/10/security-best-practices-for-weblogic.html
Safe Harbor Statement
上記の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。上記の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
0 件のコメント:
コメントを投稿