WebLogic Server for OKE でWebLogicドメインを作ってみる
はじめに
この記事はOracle Cloud Infrastructure (以下OCI) で提供されている、WebLogic Server for Oracle Container Engine for Kubernetes (以下WLS for OKE) のEnterprise Editionがプロビジョニングされた環境を前提にしています。WLS for OKEの概要やプロビジョニングの方法などについては以前の記事もご参考ください。
この記事では、WLS for OKEがプロビジョニングされた環境でWebLogicドメインを作成する方法と接続の仕組みなどを中心に見ていきたいと思います。
新規WebLogicドメインの作成
今回は2つの管理対象サーバで構成されるWebLogicドメインをWLS for OKE上に作ってみます。WLS for OKEへのWebLogic環境の作成や更新はJenkinsコンソールからone stopで行えるようになっています。
まず最初に、踏み台ホストを経由するSOCKSプロキシを構成しておいてから
ssh -D <SOCKSプロキシ用のポート> -fCqN -i <SSH秘密鍵のパス> opc@<踏み台ホストのIP>
Jenkins コンソール http://<プライベート・ロードバランサのIP>/jenkinsにアクセスし、初期アクセスの時に設定した管理ユーザとパスワードでログインします。
Jenkinsコンソールのダッシュボードから create domain のパイプラインを実行(▷のアイコン)します。
create domainのパイプラインのでは以下のような設定項目があります。
-
WebLogic Server on Container Cluster
WebLogicドメインの構成やWebLogicのバージョンなどを設定を行います -
Registry (OCIR) [オプション]
OCIRにアクセスする追加のOCIRユーザを利用する場合のOCIRユーザやAuth Tokenなどを指定します。 -
Container Cluster (OKE) Configuration
WebLogicドメインをデプロイする先のWebLogic Node Poolの選択します。 -
Load balancer Configuration
WebLogic管理対象サーバ用にプロビジョニングするロードバランサを設定を行います。 -
Identity Cloud Service (IDCS) Integration [オプション]
WebLogic上のアプリケーションや管理サーバに対するアクセスの認証にOracle Identity Cloud Service (IDCS) によるOAuth認証を利用するための設定を行います。
今回はオプションのRegistry (OCIR) や Identity Cloud Service (IDCS) Integrationは利用せずに、最も単純な構成で試してみます。
WebLogic Server on Container Cluster の設定
ここでは以下のようなパラメータを設定します。
| パラメータ | 設定する内容 |
|---|---|
| Domain_Name | 作成するWebLogicドメインの名前。 ここでは demo00。 |
| WeLogic_Version | 利用するWebLogicのバージョン。WebLogic 14.1.1の場合はJDKも選択。 ここでは 12.2.1.4
|
| Base_Image | 使用するベース・イメージ。 ここでは選択せず (Select_Base_Imageのまま) プロビジョニング時に登録されたものを利用。 |
| Administration_Username | WebLogic管理ユーザの名前。 ここでは weblogic
|
| Administration_Password | WebLogic管理ユーザのパスワード。 ここでは welcome1
|
| Managed_Server_Count | 作成する管理対象サーバの数。(最大9) ここでは 2
|
| Patch_Automatically | 定期的な自動パッチを設定する場合にチェック。 ここでは「チェックしない」 |
| Cleanup_Domain_Resource | 以前に作成に失敗した同じドメインがある場合に削除する場合にチェック。 ここでは「チェックしない」 |
Container Cluster (OKE) Configurationの設定
今回はプロビジョニング時に作成された WebLogic Node Poolに作成しますので、以下のパラメータのみ設定します。
| パラメータ | 設定する内容 |
|---|---|
| WebLogic_Node_Pool_Type | 新しくWebLogic Node Poolを作るか、既存Poolを使うかを選択。 ここでは Existing_Node_Poolを選択。 |
| Existing_Node_Pool | 利用するWebLogic Node Poolを選択。 ここでは wls4oke-wls-np (プロビジョニング時に作成されたもの) |
なお、新規にWebLogic Node Poolを作成する場合は、ノード・プールのサイズやComputeシェイプ、配置先のサブネットなどをここで指定します。
Load balancer Configurationの設定
管理対象サーバにアクセスするためのロードバランサをプロビジョニング時に作成されたパブリック・サブネットに作成するために、以下のパラメータのみを設定します。
| パラメータ | 設定する内容 |
|---|---|
| External_Lb_Shape_Min | 作成するフレキシブル・ロードバランサの最小の帯域。 ここでは 10を指定。 |
| External_Lb_Shape_Max | 作成するフレキシブル・ロードバランサの最大の帯域。 ここでは 400を指定。 |
上記以外のパラメータはロードバランサを他のサブネットに作成する際などに利用しますので、ここでは指定しません。
create domainパイプラインのビルド
以上の項目を設定したら、ページ最後にある [ビルド] のボタンでビルドを開始します。以下のようにStage Viewが表示され、処理の進行に合わせて処理状況がアップデートされていきます。
しばらく時間がかかりますので(15分くらい)パイプラインが完了するまで待ちます。
以下のように IDCS_CONFIGURATIONのまでの全てのステージが完了したらデプロイは完了です。
作成したドメインへのアクセス
まず、作成されたWebLogicドメインのWebLogic管理コンソールにアクセスしてみます。WebLogic管理コンソールには以下のURLにブラウザでアクセスします。
http://<プライベート・ロードバランサのIP>/<WebLogicドメイン名>/console
今回 demo00 のドメインを作成したので、私の環境では以下のURLになります。
http://10.0.6.13/demo00/console
アクセスするとWebLogic管理コンソールのログイン画面が表示されるため、create domainのパイプライン実行時に指定した管理ユーザ weblogicと管理ユーザのパスワード welcome1でログインします。
ログイン後に、左側の「ドメイン構成」のツリーから [demo00] ⇒ [環境] ⇒ [サーバー] を表示すると、
- 管理サーバ
- 動的クラスタ
doudemo00-clusterに所属する最大9つの管理対象サーバ
が作成されており、そのうちの管理サーバと2つの管理対象サーバが起動されていることが分かります。
作成されたWebLogicドメインに対しては以下ような経路が構成されます。
- 作成されたWebLogicドメインの管理サーバ
Jenkinsコンソールと同じプライベート・ロードバランサからアクセス - 作成されたWebLogicドメインの管理対象サーバ
ドメイン作成の際に作成されるロードバランサからアクセス
ドメイン作成後のロードバランサがどのように構成されているか、OCIコンソールから確認してみましょう。
WebLogicドメインのプロビジョニングの結果、管理対象サーバへの経路となる新しいロードバランサが1番目に追加されているのが分かります。
作成されたドメインに対する経路
WebLogic管理コンソールへの経路が具体的にどのように設定されているか少し掘り下げてみましょう。
管理コンソールやWebLogicクラスタ(管理対象サーバ)への経路は、プライベート・ロードバランサやドメイン用に作成されたロードバランサからNginx Ingress Controllerにより下図のようにルート制御されています。
Nginx Ingress Controllerの構成を確認するために、管理ホストにログインしてOKEのクラスタにアクセスしてみます。
管理ホストへのアクセスはPC上から以下のSSHコマンドでアクセスできます。
ssh -i <SSH秘密鍵のパス> -o ProxyCommand="ssh -W %h:%p –i <SSH秘密鍵のパス> opc@<踏み台ホストのパブリックIP>" opc@<管理ホストのIP>
私の環境では以下のようになります。
ssh -i ~/.ssh/mykey -o ProxyCommand="ssh -W %h:%p –i ~/.ssh/mykey opc@155.248.198.106" opc@10.0.2.9
管理ホストに接続したら、まずOKE内のnamespaceを確認してみます。
[opc@wls4oke-admin ~]$ kubectl get ns
NAME STATUS AGE
default Active 2d22h
demo00-ns Active 81m
jenkins-ns Active 2d22h
kube-node-lease Active 2d22h
kube-public Active 2d22h
kube-system Active 2d22h
wls4oke-operator-ns Active 2d22h
wlsoke-ingress-nginx Active 2d22h
[opc@wls4oke-admin ~]$
いくつかの namespace が定義されていますが、Kubernetes標準のもの以外は以下のような用途です。
| namespace | 用途 |
|---|---|
<prefix>-operator-ns |
WebLogic Kubernetes Operatorがインストールされるnamespace。<prefix> はWLS for OKEをプロビジョニングしたときに指定した Resource Name Prefix (ここではwls4oke)。 |
wlsoke-ingress-nginx |
Nginx Ingress Controllerがインストールされるnamespace。 |
jenkins-ns |
Jenkinsがインストールされるnamespace。 |
<domain name>-ns |
作成されたWebLogicドメイン用のPodが稼働するnamespace |
作成したWebLogicドメインに対する経路を制御する Ingress は <domain name>-nsの namespaceに作成されます。
[opc@wls4oke-admin ~]$ kubectl get ingress -n demo00-ns
NAME CLASS HOSTS ADDRESS PORTS AGE
wls-admin-ingress <none> * 80 90m
wls-cluster-ingress <none> * 80 90m
wls-console-help-ingress <none> * 80 90m
[opc@wls4oke-admin ~]$
これらの Ingress はそれぞれ以下の用途で作成されています。
| Ingress | 用途 |
|---|---|
wls-admin-ingress |
/<domain name>/console で管理コンソールに転送 |
wls-console-help-ingress |
/<domain name>/consolehelpで管理コンソールのヘルプに転送 |
wls-cluster-ingress |
WebLogicクラスタ(管理対象サーバ群) に転送 |
wls-admin-ingress と wls-cluster-ingress の中身はそれぞれ以下のようになっています。(wls-console-help-ingressはwls-admin-ingressと同等のため割愛します)
[opc@wls4oke-admin ~]$ kubectl get ingress/wls-admin-ingres -n demo00-ns
Error from server (NotFound): ingresses.networking.k8s.io "wls-admin-ingres" not found
[opc@wls4oke-admin ~]$ kubectl get ingress/wls-admin-ingress -n demo00-ns -o yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
helm.sh/resource-policy: keep
kubernetes.io/ingress.class: nginx
meta.helm.sh/release-name: ingress-controller
meta.helm.sh/release-namespace: default
creationTimestamp: "2023-02-26T07:13:53Z"
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: wls-admin-ingress
namespace: demo00-ns
resourceVersion: "922287"
uid: be13e2f9-f2b2-40db-9f7f-c35de7d46bd2
spec:
rules:
- http:
paths:
- backend:
service:
name: demo00-demo00-adminserver
port:
number: 7001
path: /demo00/console
pathType: Prefix
status:
loadBalancer: {}
[opc@wls4oke-admin ~]$
[opc@wls4oke-admin ~]$ kubectl get ingress/wls-cluster-ingress -n demo00-ns -o yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
helm.sh/resource-policy: keep
kubernetes.io/ingress.class: demo00-nginx-applications
meta.helm.sh/release-name: ingress-controller
meta.helm.sh/release-namespace: default
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/configuration-snippet: |
more_clear_input_headers "WL-Proxy-Client-IP" "WL-Proxy-SSL";
more_set_input_headers "X-Forwarded-Proto: https";
more_set_input_headers "WL-Proxy-SSL: true";
more_set_input_headers "is_ssl:ssl";
nginx.ingress.kubernetes.io/session-cookie-name: JSESSIONID
creationTimestamp: "2023-02-26T07:13:53Z"
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: wls-cluster-ingress
namespace: demo00-ns
resourceVersion: "922293"
uid: 408bc823-29a9-49d2-bf4d-9312b2bb3292
spec:
rules:
- http:
paths:
- backend:
service:
name: demo00-cluster-demo00-cluster
port:
number: 8001
path: /
pathType: Prefix
status:
loadBalancer: {}
[opc@wls4oke-admin ~]$
各ロードバランサに対応するIngress Controllerはそれぞれ以下のように構成されます。
[opc@wls4oke-admin ~]$ kubectl get service -n wlsoke-ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demo00-lb-external LoadBalancer 10.96.22.173 192.9.239.194 443:30706/TCP 134m
wls4oke-internal LoadBalancer 10.96.248.16 10.0.6.13 80:31736/TCP 2d22h
[opc@wls4oke-admin ~]$
IngressとIngress Controllerの関連付けは、Ingressのannotation kubernetes.io/ingress.class に指定されるクラスによって制御されています。
例えば、wls-cluster-ingress のIngressに対しては kubernetes.io/ingress.class: demo00-nginx-applicationsとIngress Classが定義されますが、この値が demo00-lb-external の Service に関連付けられたDeploymentでのコンテナの起動オプションで以下(最終行)のように指定される、という形です。
[opc@wls4oke-admin ~]$ kubectl get deployment/nginx-ingress-controller-demo00-external -n wlsoke-ingress-nginx -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
:
:
spec:
containers:
- args:
- /nginx-ingress-controller
- --configmap=$(POD_NAMESPACE)/nginx-configuration-external
- --publish-service=wlsoke-ingress-nginx/demo00-lb-external
- --annotations-prefix=nginx.ingress.kubernetes.io
- --ingress-class=demo00-nginx-applications
ここまでで、おおまかな接続の構成の原理が理解いただけたのではないでしょうか。
サンプルアプリケーションのデプロイ
さて、管理対象サーバへの経路のアクセスの確認も兼ねて、Jenkinsコンソールからサンプル・アプリケーションをデプロイしてみます。
同様にダッシュボードから sample appのパイプラインを実行します。
sample appのパイプラインでは以下のパラメータが設定できます。今回はWebLogicドメインを選択して、失敗時のロールバックを指定してビルドします。
| パラメータ | 設定する内容 |
|---|---|
| Domain_Name | デプロイ先のWebLogicドメインを選択。 ここでは demo00を選択。 |
| Undeploy_Sample_App | サンプル・アプリケーションをアンデプロイする際に指定。 ここでは「指定しない」。 |
| Rollback_On_Failure | デプロイに失敗した場合に実行前の状態にロールバックする。 ここでは「チェックを入れる」。 |
| Registry_Username | 追加のOCIRユーザで実行する場合のOCIRユーザを指定。 ここでは「指定しない」。 |
| Registry_Authentication_Token | 追加のOCIRユーザで実行する場合のOCIRユーザのAuth Tokenを指定。 ここでは「指定しない」。 |
ビルドを実行すると、ドメイン作成時と同様に処理が始まりますので完了するまでしばらく(10分強くらい)待ちます。
このパイプラインでは、既存のドメインで利用しているコンテナ・イメージに対してサンプル・アプリケーションをデプロイして追加したイメージを作成し、OCIRにコンテナ・イメージ追加した上でそのイメージを使ってドメインを再起動します。
パイプラインの実行完了後、WebLogic管理コンソールにアクセスして、[デプロイメント] を確認すると sample-appのアプリケーションがデプロイされていることが分かります。
アプリケーションに対するアクセスは、ドメイン毎に作成されたロードバランサになります(下図の赤枠)。
作成されたロードバランサのIPを確認して以下のURLでアクセスします。
https://<ドメイン用のロードバランサのIP>/sample-app
私の環境の場合は以下になります。
https://192.9.239.194/sample-app
証明書が自己証明書のため証明書に関する警告が出ますが、警告を確認して表示してください。
SOCKSプロキシを設定したままの場合(特にChrome)でアクセスすると接続できないケースがありますので、SOCKSプロキシを設定していない別のブラウザなどで確認すると確実です。(私はEdgeで確認しました)
ここまでで一通りの動作確認はおしまいです。
(おまけ) 各Jenkinsパイプラインの簡単な解説
せっかくなので今回利用していないものも含め、Jenkinsパイプラインについて用途などの概要を簡単にまとめておきます。
| パイプラインの名前 | 概要 |
|---|---|
create domain |
ベースイメージを指定してWebLogicドメインを作成 |
update domain |
既存のWebLogicドメインの設定変更(JavaEEリソース)やアプリケーションのデプロイ |
terminate domain |
作成済みのWebLogicと関連リソースを削除 |
create base image |
WebLogicのインストーラー、JDK、パッチなどからベースイメージを作成 |
rebase domain image |
既存のベースイメージを元にベースイメージを作成 |
opatch update |
既存のベースイメージにWebLogicやJDKのパッチを適用 |
automatic patching |
スケジュールに従って既存のWebLogicドメインにパッチを適用 |
backup and deploy domain |
WebLogicドメインの作成や更新時に作成するWebLogicドメインのYAMLをバックアップ ※他のパイプラインから呼び出されるパイプライン、単体では使わない |
create wls nodepool |
ドメイン作成時にWebLogic Node Poolを追加作成 ※他のパイプラインから呼び出されるパイプライン、単体では使わない |
sample app |
サンプルアプリケーションを既存のWebLogicドメインにデプロイ |
いくつかのパイプラインは他のパイプラインから呼ばれる、子のパイプラインになっており呼び出し関係は概ね以下のようになっています。
+ sample app
+ backup and deploy domain
+ create domain
+ create wls nodepool
+ update domain
+ backup and deploy domain
+ terminate domain
+ create base image
+ rebase domain image
+ opatch update
+ backup and deploy domain
+ automatic patching
create domain でドメインを作成するときに新しくのWebLogic Node Poolを作成する場合は create wls nodepool パイプラインが使用されます。また、WebLogicドメインを作成したり変更するパイプラインでドメインのYAMLのバックアップに backup and deploy domain パイプラインが使用される、という関係になっています。
各パイプラインの具体的なパラメータは、実際にJenkinsコンソール上から確認してみてください。
おわりに
今回はWLS for OKEの基本的な動作確認と初歩的な使い方として、ドメインの作成などのJenkinsコンソールの使い方を取り上げ、どのような仕組みでOKE内のWebLogic環境と接続するのか、という点を中心に解説してみました。
まずはWLS for OKEを触りながら内部の仕組みを理解いただく素材としてこの記事がお役に立てれば幸いです。