原文はこちら。
https://blogs.oracle.com/weblogicserver/voyagerhaproxy-as-load-balancer-to-weblogic-domains-in-kubernetes
Overview
負荷分散は、スケーラブルで復元力のあるアプリケーションを構築するために広く使用されているテクノロジーです。負荷分散の主な機能は、サーバーの監視と、ネットワークトラフィックの複数のサーバー（Webアプリケーション、データベースなど）への分散です。Kubernetesで動作するコンテナ化されたアプリケーションでは、負荷分散も必要です。Oracle WebLogic Server Kubernetes Operator version 1.0で、Voyager/HAProxyのサポートを追加しました。create-weblogic-domain.shスクリプトを拡張してVoyager/HAProxyをすぐに使用できるようにしています。
Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator/tree/release/1.0
このスクリプトは、1個のWebLogicドメイン/クラスタのサーバへの負荷分散をサポートしています。このエントリでは、Kubernetesの複数のWebLogicドメインにデプロイされたアプリケーションに対して負荷分散のサポートを拡張するためのVoyager/HAProxyの設定方法を説明します。
Basics of Voyager/HAProxy
HAProxyとVoyagerに詳しくない方は、HAProxyとVoyagerの基本を時間を掛けて学ぶ価値があります。
HAProxyは、TCPおよびHTTPベースのアプリケーション用の可用性の高いロードバランサとプロキシサーバを提供する、無料のオープンソース・ソフトウェアです。（プロセッサ速度とメモリ使用量の面で）高速で効率的であることはよく知られています。HAProxyの初心者ガイドは以下からどうぞ。
HAProxy Starter Guide version 1.9-dev1
http://cbonte.github.io/haproxy-dconv/1.9/intro.html
VoyagerはHAProxyを使うIngressコントローラです（IngressについてはKubernetesのドキュメントを参照してください）。
Ingress
https://kubernetes.io/docs/concepts/services-networking/ingress/
Kubernetesクラスタにインストールすると、VoyagerオペレータはKubernetes IngressリソースとVoyager自身のIngress CRDを監視し、状況に応じてHAProxyインスタンスを自動作成、更新、削除します。 Voyagerオペレータの仕組みを理解するには、voyagerの概要をご覧ください。
Voyager Overview
https://appscode.com/products/voyager/7.1.1/concepts/overview/
Running WebLogic Domains in Kubernetes
wls-operator-quickstartプロジェクトをGitHubからあなたのローカル環境にチェックアウトしてください。このプロジェクトを使うと、最小限の作業でWebLogic Operatorとドメインを設定できます。READMEのPre-Requirementsの章に記載の手順を実行して、ローカル環境を構成してください。
Quick Start of WLS Operator
https://github.com/lilyhe123/wls-operator-quickstart
wls-operator-quickstartプロジェクトとWebLogic Operatorを使用して、Kubernetes上で実行される2つのWebLogicドメインを、それぞれ独自の名前空間に設定します。
- 'domain1'という名前のドメインは名前空間 'default'で実行され、2個の管理対象サーバ 'domain1-managed-server1'と 'domain1-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
- 'domain2'という名前のドメインは名前空間 'test1'で実行され、2個の管理対象サーバ 'domain2-managed-server1'と 'domain2-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
- Webアプリケーション 'testwebapp.war' は、domain1とdomain2の両方のクラスタに別々にデプロイされます。このWebアプリケーションには、どちらの管理対象サーバがHTTPリクエストを処理しているかを表示するデフォルトページがあります。
次の手順を実行して、HAProxyの背後にあるWebLogicドメインを準備します。
# change directory to root folder of wls-operator-quickstart
$ cd xxx/wls-operator-quickstart
# Build and deploy weblogic operator
$ ./operator.sh create
# Create domain1. Change value of `loadBalancer` to `NONE` in domain1-inputs.yaml before run.
$ ./domain.sh create
# Create domain2. Change value of `loadBalancer` to `NONE` in domain2-inputs.yaml before run.
$ ./domain.sh create -d domain2 -n test1
# Install Voyager
$ kubectl create namespace voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
| bash -s -- --provider=baremetal --namespace=voyager
以下のようにWebLogicドメインの状態を確認します。
# Check status of domain1
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/domain1-admin-server 1/1 Running 0 5h
pod/domain1-managed-server1 1/1 Running 0 5h
pod/domain1-managed-server2 1/1 Running 0 5h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/domain1-admin-server NodePort 10.105.135.58 <none> 7001:30705/TCP 5h
service/domain1-admin-server-extchannel-t3channel NodePort 10.111.9.15 <none> 30015:30015/TCP 5h
service/domain1-cluster-cluster-1 ClusterIP 10.108.34.66 <none> 8001/TCP 5h
service/domain1-managed-server1 ClusterIP 10.107.185.196 <none> 8001/TCP 5h
service/domain1-managed-server2 ClusterIP 10.96.86.209 <none> 8001/TCP 5h
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h
# Verify web app in domain1 via running curl on admin server pod to access the cluster service
$ kubectl -n default exec -it domain1-admin-server -- curl http://domain1-cluster-cluster-1:8001/testwebapp/
# Check status of domain2
$ kubectl -n test1 get all
NAME READY STATUS RESTARTS AGE
pod/domain2-admin-server 1/1 Running 0 5h
pod/domain2-managed-server1 1/1 Running 0 5h
pod/domain2-managed-server2 1/1 Running 0 5h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/domain2-admin-server NodePort 10.97.77.35 <none> 7001:30701/TCP 5h
service/domain2-admin-server-extchannel-t3channel NodePort 10.98.239.28 <none> 30012:30012/TCP 5h
service/domain2-cluster-cluster-1 ClusterIP 10.102.228.204 <none> 8001/TCP 5h
service/domain2-managed-server1 ClusterIP 10.96.59.190 <none> 8001/TCP 5h
service/domain2-managed-server2 ClusterIP 10.101.102.102 <none> 8001/TCP 5h
# Verify the web app in domain2 via running curl in admin server pod to access the cluster service
$ kubectl -n test1 exec -it domain2-admin-server -- curl http://domain2-cluster-cluster-1:8001/testwebapp/
Kubernetesで両WebLogicドメインが稼働してから、異なるHAProxy機能を使って、2個のWebLogicドメインに帯する単一エントリポイントとしてVoyagerを構成します。
Using Host Name-Based Routing
Ingressリソースファイル 'voyager-host-routing.yaml' を作成します。このファイルにはホスト名ベース・ルーティングを使ったIngressリソースが含まれています。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
name: hostname-routing
namespace: default
annotations:
ingress.appscode.com/type: 'NodePort'
ingress.appscode.com/stats: 'true'
ingress.appscode.com/affinity: 'cookie'
spec:
rules:
- host: domain1.org
http:
nodePort: '30305'
paths:
- backend:
serviceName: domain1-cluster-cluster-1
servicePort: '8001'
- host: domain2.org
http:
nodePort: '30305'
paths:
- backend:
serviceName: domain2-cluster-cluster-1.test1
servicePort: '8001'
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-host-routing.yaml
Testing Load Balancing with Host Name-Based Routing
ホスト名ベース・ルーティングを行うには、通常はDNSの変更を伴う仮想ホスティングを設定する必要があります。デモ目的のため、curlコマンドを使用して、ホスト名ベース・ルーティングによるロードバランシングをシミュレートします。
# Verify load balancing on domain1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server2
# Verify load balancing on domain2
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server1
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server2
結果は以下の通りです。
- ホスト名 'domain1.org' を指定すると、リクエストはdomain1の管理対象サーバで処理される。
- ホスト名 'domain2.org' を指定すると、リクエストはdomain2の管理対象サーバで処理される。
Using Path-Based Routing and URL Rewriting
この章では、URL書き換えによるパスベース・ルーティングを使用して、ホスト名ベース・ルーティングと同じ動作を実現します。
Ingressリソースファイル 'voyager-path-routing.yaml'を作成します。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
name: path-routing
namespace: default
annotations:
ingress.appscode.com/type: 'NodePort'
ingress.appscode.com/stats: 'true'
ingress.appscode.com/rewrite-target: "/testwebapp"
spec:
rules:
- host: '*'
http:
nodePort: '30307'
paths:
- path: /domain1
backend:
serviceName: domain1-cluster-cluster-1
servicePort: '8001'
- path: /domain2
backend:
serviceName: domain2-cluster-cluster-1.test1
servicePort: '8001'
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-path-routing.yaml
Verify Load Balancing with Path-Based Routing
負荷分散の結果を検証するため、curlコマンドを使います。別の方法として、Webブラウザから直接URLにアクセスすることもできます。
# Verify load balancing on domain1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain1-managed-server2
# Verify load balancing on domain2
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
<li>InetAddress.hostname: domain2-managed-server2
異なるURLを指定してパスベース・ルーティングによりトラフィックが異なるWebLogicドメインに振り分けられることを確認できます。URL書き換え機能を使えば、最終的に各ドメインの同じコンテキスト・パスを持つWebアプリケーションにアクセスできます。
Cleanup
このエントリの手順を使った演習終了後は、Kubernetesで作成した全てのリソースをクリーンアップしたいと思うことでしょう。
# Cleanup voyager ingress resources
$ kubectl delete -f voyager-host-routing.yaml
$ kubectl delete -f voyager-path-routing.yaml
# Uninstall Voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
| bash -s -- --provider=baremetal --namespace=voyager --uninstall --purge
# Delete wls domains and wls operator
$ cd <QUICKSTART_ROOT>
$ ./domain.sh delete --clean-all
$ ./domain.sh delete -d domain2 -n test1 --clean-all
$ ./operator.sh delete
Summary
このエントリでは、Voyagerロードバランサを構成し、WebLogic ServerドメインにデプロイしたTCPベースおよびHTTPベースのアプリケーションのための、可用性の高いリクエストの負荷分散とプロキシサーバ機能を提供する方法を説明しました。このエントリで提供したサンプルでは、Voyagerを複数のWebLogicドメインの前の単一ポイントとして使用する方法を説明しました。ホスト名ベースルーティング、パスベースルーティング、URL書き換えなどのVoyager機能の使用方法を示す例を示しました。このブログが皆様のお役に立つことを願いつつ、是非Kubernetes上のWebLogic環境でVoyagerを使用してみてください。
