More than 1 year has passed since last update.

WebLogic Server for OKE をプロビジョニングしてみる

Last updated at 2023-03-01Posted at 2023-02-24

WebLogic Server for OKE をプロビジョニングしてみる

はじめに

Oracle Cloud Infrastructure (以下OCI) で提供されているサービスには、コンテナ上でのWebLogic環境を簡単に利用できる WebLogic Server for Oracle Container Engine for Kubernetes (以下WLS for OKE) があります。この記事では、WLS for OKEの簡単な仕組みにも触れつつ、まずは環境を作成する流れについてまとめてみたいと思います。

この記事では、以下のような方を対象としています。

OCIの使い方について基礎的な知識をお持ちの方
WebLogicについて基礎的な知識をお持ちの方
Java EEとコンテナ(Kubernetes)の関係に興味のある方
30日間トライアルを含む利用可能なOCIアカウントをお持ちの方

なお、本記事を作成するにあたっては、Windows 10 + Google Chrome ブラウザにて試しています。

WLS for OKEはネットワークの構成や権限設定など細かくカスタマイズ可能ですが、初めての方のためにできるだけシンプルな構成でのプロビジョニングを取り上げます。

WLS for OKEとは？

Kubernetes上のアプリケーションと言えば、Node.js や Python、Java、Go などの Polyglot な言語でコンテナアプリケーションを稼働させるイメージが強いですが、従来のアプリケーションを再利用して、スケール変更やオート・ヒーリングなどの運用を自動化・効率化のために利用するというシーンもあります。
WLS for OKE はJava EEのアプリケーション・サーバであるWebLogicの環境とアプリケーションをコンテナ化し、Kubernetesに対する操作のみでWebLogicのクラスタリング機能などと連動したアプリケーションを環境を自動運用するためのWebLogic Kubernetes OperatorをベースにしたOCI上のサービスです。

WLS for OKEは以下ような代表的なコンポーネントで構成されます。

Oracle Container Engine for Kubernetes (OKE)
- OCIで提供されるマネージドKubernetesサービス。WebLogicとそのアプリケーションがこのOKE上で稼働します。
Oracle Container Infrastructure Registry (OCIR)
- OCIで提供されるコンテナ・レジストリのサービス。WebLogicやアプリケーションのコンテナ・イメージが格納されます。
WebLogic Kubernetes Operator
- WebLogic Serverの構成(＝WebLogicドメイン)をYAMLベースの定義でKubernetesに制御させるためのKubernetes Operator。WLS for OKEではこのOperatorが自動で構成されます。
WebLogic Deploy Tooling (WDT) / WebLogic Image Tool (WIT) & Jenkins
- WDT と WIT は、YAMLで記述したWebLogicの設定やアプリケーションのアーカイブ(ZIPファイル)からWebLogic Operatorが使用するコンテナイメージをビルドしてくれるコマンドベースのツールキットです。
- WLS for OKEに自動で構成されるJenkins 環境には、WDTとWITを利用したイメージのビルドからWLSドメインやアプリケーションのデプロイまで、利用に必要なビルド・パイプラインが事前定義されていますので、WDTやWITの使い方を深く知らなくても簡単に利用できるようになっています。

Jenkins環境も含め、上図のような利用に必要なネットワークの構成、ロードバランサ、管理用のホストや踏み台ホストまで、必要な全てのリソースをリソース・マネージャの仕組みを利用してプロビジョニングできるようになっています。

WLS for OKEの基本的なプロビジョニングの流れ

WLS for OKEはOCI Marketplaceからプロビジョニングを行います。事前準備も含めると最低限の手順は以下の通りです。

WLS for OKEリソース用のコンパートメントを作成
コンパートメントに対するポリシーとルート・ポリシーの設定
動的グループの作成、動的グループのためのポリシーの設定
OCIR用のAuth Tokenの作成
Vault と Secret の作成
SSHキー・ペアの作成
OCI MarketplaceからWLS for OKEをプロビジョニング

ここから実際にプロビジョニングしてみます。

WLS for OKEのプロビジョニング

最初にリソース権限に関連する事前準備を行います。コンパートメントや動的グループ、ポリシーの作成など権限が与えられていない場合はテナンシ管理者に作成を依頼してください。

[事前準備] 1. WLS for OKEリソース用のコンパートメントの作成

まず事前準備として、WLS for OKEを作成するコンパートメントを作成します。任意の階層に、任意の名前のコンパートメントを作成します。
私の環境の場合、以下のような構成の <mycompartment> が割り当てられています。

ルート・コンパートメント
　+- member
　   +- <myompartment>

今回はこのコンパートメントにWLS for OKEに関連するリソースを全て作成していきます。

[事前準備] 2. コンパートメントのポリシーとルート・ポリシーの設定

次の事前準備として、作成したWLS for OKEのリソースを管理するための権限をコンパートメントに定義しておきます。ここでは以下のように作成したコンパートメントのリソース管理権限を、自分のアカウントに全て付与することにします。作成したコンパートメントの上位のコンパートメント (上述の私の環境の場合では memberのコンパートメントやルート・コンパートメント) に対して、以下のステートメントを含む任意の名前のポリシー作成します。

Allow group <mygroup> to manage all-resources in compartment <mycompartment>

※ <mygroup> は自信のアカウントが所属するグループを指定します。

次に、テナンシレベルのリソースに対する以下のステートメントを含むポリシーをルート・コンパートメントに作成します。

Allow group <mygroup> to inspect tenancies in tenancy
Allow group <mygroup> to use tag-namespaces in tenancy

[事前準備] 3. 動的グループの作成、動的グループのためのポリシー設定

マーケットプレイスからのプロビジョニングの仕組みとして動的グループを利用するため、動的グループを作成し、動的グループに対しての権限を付与します。
任意の名前で動的グループを作成し、以下のように「作成したコンパートメント内のインスタンス」に合致するように一致ルールを設定します。

instance.compartment.id = '<作成したコンパートメントのOCID>'

私の環境の場合は、図のような形で「作成したコンパートメント内のインスタンス」にも合致するようになっています。(赤枠の部分が必要な一致ルール)

次に、作成した動的グループに対してのコンパートメント上のリソースに対する権限とOKEに対する app-catalog-listing のread権限を付与します。

Allow dynamic-group <mydynamicgroup> to manage all-resources in compartment <mycompartment>
Allow service oke to read app-catalog-listing in compartment <mycompartment>

このポリシーは作成したコンパートメントに任意の名前で作成します。(上位のコンパートメントでもOK)

権限関連の事前準備はこれでOKです。

[事前準備] 4. OCIR用のAuth Token の作成

次は、コンテナレジストリであるOCIRにアクセスするためのAuth Token(認証トークン)を作成します。既にAuth Tokenを作成済みの場合は流用しても構いません。

コンソール右上のユーザ・プロファイルの設定から

[認証トークン] のリソースを選び、[トークンの作成] から任意の名前(説明)でAuth Tokenを作成しておきます。

作成するとAuth Tokenの値が表示されますが、ダイアログを一度閉じるとその後は一切表示できませんので、Auth Tokenの値は手元のメモに残して保管しておいてください。

私の環境では上図の AuthToken-ocirを使います。

[事前準備] 5. VaultとSecretの作成

WLS for OKEをプロビジョニング、及び利用する際にOKEなどが利用する「OCIRへアクセスするためのAuth Token」を必要とします。Auth Tokenの値は秘匿なデータのためそのまま平文で入力・保管する訳にはいかないため、暗号化された形でVaultで管理されるSecretに格納しておきます。もちろん既にVaultやSecretを作成するためのマスター暗号化キーが作成済みの場合は流用することも可能です。

Vaultの作成は [アイデンティティとセキュリティ] のメニューにある [ボールト] から行います。

[ボールト] の作成からVaultの作成を行います。必要な情報は以下の通りです。

作成先のコンパートメント：事前に作成したWLS for OKEを作成するコンパートメントを指定
作成するVaultの名前：任意の名前を指定 (ここでは default_vault)
仮想プライベート・ボールトにするか否か：どちらでも可 (高度なセキュリティ要件が無い限り、安価な方=チェックをしない　でOK)

作成したVaultを選択して、最初にマスター暗号化キーを作成します。コンソール右側の [リソース] メニューの [マスター暗号化キー] ⇒ [キーの作成] から作成します。ここでは以下の内容を指定します。

作成先のコンパートメント：事前に作成したWLS for OKEを作成するコンパートメントを指定
保護モード：HSM
名前：任意のマスター暗号化キーの名前 (ここではdefault_key )
キーのシェイプ:アルゴリズムと長さ：AES、256ビット

マスター暗号化キーを作成後、[リソース] メニューの [シークレット] ⇒ [シークレットの作成] から「OCIRのAuth Token用」のシークレットを作成します。各シークレットの作成には以下の値を指定します。

設定欄	OCIRのAuth Token用
コンパートメントに作成	WLS for OKEのコンパートメント
名前	AuthToken-ocir (任意の名前)
説明	(必要に応じて入力)
キーの選択	`default_key`
シークレット・タイプ・テンプレート	プレーン・テキスト
シークレット・コンテンツ	メモしておいたAuth Tokenの値

事前に作成しておくべき最低限のOCIリソースの作成は以上です。

[事前準備] 6. SSHキー・ペアの作成

踏み台ホストや管理ホストへのログインで利用するSSHキー・ペアを作成します。以下の要件を満たすSSHキーであれば作成するツールや手法は問いません。

SSH-2 RSAキーであること
キーサイズは2048ビット
OpenSSH形式のフォーマット
パスフレーズは空

LinuxなどのUnixライクな環境、Windows 10 以上の環境の場合、以下のコマンドで作成できます。

ssh-keygen -b 2048 -t rsa -f mykey

このほか、PuTTY Key Generatorを使って作成しても構いません。普段使用するSSHクライアントに合わせて作成します。(私の環境ではPuTTY Key Generatorを使っています)
プロビジョニングの際には、ここで作成したキーペアの公開鍵(上記の例の場合 mykey.pub)を使用します。

ここまでで一通りの事前準備は完了です。

7. OCI MarketplaceからWLS for OKEをプロビジョニング

ここからがWLS for OKEのプロビジョニングの本番です。

OCIコンソールのメニューから [マーケットプレイス] ⇒ [すべてのアプリケーション] を選び、検索キーワード WebLogic で検索すると WLS for OKE を含むWebLogic関連のサービス群が表示されます。

WebLogicのエディション別 (WebLogic Enterprise EditionとWebLogic Suite)、課金モデル別 (BYOLとUCM)で分かれていますので、任意の物を選択してください。

ここでは Oracle WebLogic Server Enterprise Edition for OKE で試します。

記事執筆時の時点ではOCIコンソールの表示言語が日本語の場合にドロップダウンが表示されない不具合が発生しています。ドロップダウンが正しく表示されない場合は、コンソール右上の地球マークから言語設定を English に変更して試してみてください。(次の画面で表示言語を日本語に戻しても大丈夫です)

ここではバージョンはデフォルトに設定されている最新のものを選び、コンパートメントには事前に作成した WLS for OKEのコンパートメントを指定します。チェックボックスにチェックを入れて [スタックの起動 (Launch Stack)] からプロビジョニングを開始します。

「スタック情報」のページは「名前」「説明」だけ設定して次に進みます。ここで設定した名前は、リソース・マネージャのスタックの名称として使用されます。

WLS for OKEのプロビジョニングの作業は、次の「変数の構成」のページがほぼ全てです。ここでWLS for OKEの構成情報を設定してます。
今回はVCNを含む全てのリソースを自動プロビジョニングする前提で、指定するパラメータを順番に見ていきます。明示的な設定が必要な項目のみ表に記載していきます。

WebLogic Server on ContainerCluster (OKE)
Resource Name Prefix	wls4oke (任意の英数字)
SSH Public Key	事前に作成したSSH公開鍵 (mykey.pub)

Resource Name Prefixには任意の英数字を指定します。作成されるOCIリソースや、Kubernetesリソースの名称のプレフィクスとして利用されますので、長すぎない英数字で指定します。また、事前に作成したSSH公開鍵をここで指定します。

Network
Virtual Cloud Network Strategy	Create New VCN
Network Compartment	`<mycompartment>`

今回はVCNやSubnetをまとめて新規作成します。上の表以外に、各ネットワークのCIDRやロードバランサのBandwidthなどを入力できますが、特に指定が無い場合はデフォルト値で構いません。

Container Cluster (OKE) Configuration
Non-WebLogic Node Pool Shape	VM.Standard.E4.Flex (OCPU=1, Memory=16GB)
Nodes in the Node Pool or non-WebLogic pods	1
WebLogic Node Pool Shape	VM.Standard.E4.Flex (OCPU=1, Memory=16GB)
Nodes in the Node Pool for WebLogic pods	1

ここではOKEのクラスタの構成を設定します。WLS for OKEには

Non-WebLogi Node Pool：Jenkinsなど管理コンポーネントのPodが配置されるNode Pool
WebLogic Node Pool：WebLogicのPodが配置されるNode Pool

の2つのNode Poolが構成されるため、それぞれのNode PoolのComputeシェイプとWorker Nodeの数を指定します。今回は節約のため最小の構成を指定しています。
追加でPodやServiceのCIDR、ストレージに対する暗号化用のSecretなども指定できますが、今回は省略します。

Administration Instances
Availability Domain for compute instances	TGjA:US-SANJOSE-1-AD-1
Administration Instance Compte Shape	VM.Standard.E2.1
Bastion Instance Shape	VM.Standard.E2.1

Administration Instance の設定では、踏み台ホスト、管理ホストのCompute Shapeと配置先のAD(Availability Domain)を指定します。

File System
Availability Domain for File System	TGjA:US-SANJOSE-1-AD-1

File Systemの設定ではFile Storage Systemを配置するADの指定のみです。

Registry (OCIR)
Registry User Name	`oracleidentitycloudservice/<username>`
OCIR Auth Token Compartment	`<mycompartment>`
Validated Secret for OCIR Auth Token	AuthToken-ocir (事前に作成したAuthToken用Secret)

OCIRに対する設定はOCIRへのアクセスに利用するユーザと、Auth Tokenのシークレットを指定します。
OCIRに対してdocker loginする場合に指定するユーザ名には通常、

<tenancy-namespace>/<username>

Oracle Identity Cloud Serviceとフェデレートされている場合(=私の環境)は

<tenancy-namespace>/oracleidentitycloudservice><username>

を利用しますが、ここで指定するRegistry User Nameには <tenancy-name>の指定は不要です。指定するとプロビジョニングに失敗しますのでご注意ください。

OCI Policies
OCI Policies	チェックを外す

最後に OCI Policies の項では「自動的に必要なポリシーを設定するか否か」を指定します。
この項目をチェックする場合、テナンシ管理者などのようなルート・コンパートメントに対してポリシーや動的グループを作成できる権限が必要です。
今回はそのような権限を持たないユーザを想定して事前にポリシーや動的グループを作成、またはテナンシ管理者に作成してもらう前提でプロビジョニングしますので、ここではチェックを外して実行します。

これで全て設定は完了です。[次] のページに進んで、内容を確認して [作成] でプロビジョニングが開始され、リソース・マネージャのスタックのジョブの画面に遷移します。

作成が完了するまでしばらく(30分程度)待ちましょう。

リソース・マネージャのログの最後の方に、下記のような踏み台ホストや管理ホストのIPアドレスやJenkinsコンソールへのアクセス方法などが表示されますので、手元にメモとして残しておきます。

Admin_Instance_Id = ocid1.instance.oc1.us-sanjose-1.anzwuljrssl65iqcht2cyrp4coymjqeohkreuq6npdssvm2s4lxpy7e7daoa
Admin_Instance_Private_IP = [
  "10.0.2.9",
]
Bastion_Instance_Id = ocid1.instance.oc1.us-sanjose-1.anzwuljrssl65iqctmozbtvr7bxovynw3zcuubzjn33o42xvzzox254ihlpq
Bastion_Instance_Public_IP = [
  "155.248.198.106",
]
Fss_Path = /wls4oke
Jenkins_Console_Url = Follow the steps below to get the Jenkins URL
=======================================================================================================
1. Get the IP address of internal LB by executing the below command in Admin instance
kubectl get svc -n wlsoke-ingress-nginx -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[*].status.loadBalancer.ingress[0].ip}'
2. The Jenkins URL: http://<<ip from above step>>/jenkins
=======================================================================================================

WLS for OKE環境への接続

ここでは確認のためにプロビジョニングされたJenkinsのコンソールに接続してみます。

ドキュメントにもあるように、Non-WebLogic Pool上に作成されるJenkinsのPodに、図のように踏み台ホストを経由するSSHによるSOCKSプロキシを経由してプライベート・ロードバランサにアクセスすることでJenkinsコンソールに接続できます。
接続先のロードバランサのIPアドレスはリソース・マネージャのログの通り、管理ホストにログインして調べることも可能ですが、ここではOCIコンソールで作成されたロードバランサのIPアドレスを確認します。

SSHによるSOCKSプロキシを構成するためには、ブラウザを起動するPC上で下記のコマンドを実行します。

ssh -D <SOCKSプロキシ用のポート> -fCqN -i <SSH秘密鍵のパス> opc@<踏み台ホストのIP>

私の環境の場合、以下のようになります。(PowerShellなどで実行します)

ssh -D 1088 -fCqN -i ~/.ssh/mykey opc@155.248.198.106

SOCKSプロキシを起動したら、Webブラウザ側でSOCKS5プロキシのアドレス(=127.0.0.1)とポート(=1088)をプロキシとして設定します。ChromeとFireFoxのそれぞれの設定は以下で行えます。

Chromeの場合
Chrome起動時のオプションに --proxy-server="socks5://127.0.0.1:1088" を追加して起動。(起動中のChromeは全て閉じる必要があります。)
FireFoxの場合
FireFoxの設定の [一般] ⇒ [ネットワーク設定/接続設定] から設定できます。

JenkinsコンソールへのアクセスURLはログの通り http://<ロードバランサのIP>/jenkins ですので、このURLにアクセスすると、Jenkinsの管理ユーザ設定画面が表示されますので、ユーザ名、パスワード等を入力して [管理者の作成] を行います。

管理者作成後にログインが完了すると以下のように成功画面に遷移します。

トップに戻ると、以下のようにWLS for OKEでプリセットされるイメージビルドやドメイン作成などのジョブの一覧が確認できます。

おわりに

思いのほか長くなってしまったため、今回はここまでで止めておこうと思います。。
WLS for OKEのプロビジョニングは、事前準備が若干多めですがプロビジョニング自体は簡単ですので一度お試しください。
次回以降で、WebLogicドメインの作成の仕方や、内部の仕組みになどを取り上げて解説していきたいと思います。

(追記) この環境を前提としてJenkinsパイプラインを使ってWebLogicドメインを作成する「WebLogic Server for OKEでWebLogicドメインを作ってみる」の記事も作成しましたので、ぜひご参考ください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up