すべて「こちら」です。
WebLogic Kubernetes Operator (「オペレータ」はオープン・ソースで、Universal Permissiveライセンス(UPL)、バージョン1.0でライセンスされています。
WebLogic Serverはオープン・ソースではありません。 WebLogic Serverのデプロイメントと同様に、WebLogic Serverインスタンスを実行するたびにライセンスが必要です。 ライセンスは、単一の開発者デスクトップ開発環境に無料で利用できます。
詳細は、「価格設定およびライセンス」を参照してください。
ご質問、フィードバックの提供、ご提案をお送りください。 方法については、「ヘルプの表示」を参照してください。
Q: どのJava EEプロファイルがKubernetesでサポート/認定されており、WebプロファイルまたはWLS Java EEのみが完全に対応していますか。
A: 完全なJava EEプロファイルをサポートしています。
Q: 多数のドメインで共有される可能性があるコンテナ(データベース、JMSなど)でWebLogic Serverドメインをどのように構成しますか。
A: Kubernetesおよびコンテナ環境では、WebLogicドメイン・ホームは永続ボリュームに外部化することも、(WebLogic Serverイメージ上のレイヤーを使用して)イメージで指定することもできます。 イメージを使用して提供されるWebLogicドメインの場合、オプションでドメイン・ログおよびストアのロケーションを永続ボリュームに配置できます。 このプロジェクトのsamplesを参照してください。
オペレータを使用する場合、デプロイされた各ドメインは、ドメインの重要な側面を記述するドメイン・リソースによって指定されます。 これらには、使用するWebLogic Serverイメージのロケーション、domain-uidというドメインの一意の識別子、ドメイン・ポッドがマウントする必要があるPVまたはPVC、WebLogicクラスタおよびサーバー、およびそのドメイン・ホームのロケーションが含まれます。
オペレータ4.0から、ドメイン構成の一部であるWebLogicクラスタは、クラスタ・リソースに関連付けることができます。 クラスタ・リソースにより、kubectl scale、Kubernetes組込みのHorizontal Pod Autoscaling、または同様のツールを使用して、現在実行されているメンバー・サーバーの数を簡単にスケーリングできます。 このクラスタ・リソースは、ドメイン・リソースから参照される必要があります。
デプロイされたドメインごとに一意のdomain-uid文字列を指定し、別のドメイン・リソースを指定することで、同じドメインの複数のデプロイメントがサポートされています。 domain-uidは、オペレータがデプロイするドメインのKubernetesリソースの名前プレフィクスまたはラベル(あるいはその両方)としてオペレータによって使用されます。 ドメイン・デプロイメントのWebLogic構成は、オプションでドメイン・リソースで構成オーバーライドを指定することでカスタマイズできます - たとえば、データ・ソースURL、ユーザー名またはパスワードの構成をオーバーライドする場合に便利です。
オペレータは、WebLogicドメイン・ホーム構成の作成方法を指定しません。 WLST、REST、またはWebLogic Deploy Tooling (WDT)と呼ばれる非常に便利な新しいツールを使用できます。 WDTでは、YAMLファイルおよびZIPファイル(バイナリを含む)を使用して、WebLogicの構成およびデプロイメント(JMS、データ・ソース、アプリケーション、オーセンティケータなど)をコンパクトに指定できます。 オペレータsamplesは、WLSTを使用してWDTを使用してドメインを作成する方法を示しています。
Q: 管理サーバーは必要ですか。 ノード・マネージャ?
A: コンテナで実行されているWebLogicとKubernetes内のWebLogicの両方の認証は、管理サーバーを含むWebLogicドメインで構成されます。 オペレータは、ドメイン・ポッド内でノード・マネージャを構成および実行 - 自分で構成する必要はありません - その存在は大部分透明です。
Q: ロケーションの透過性はどのように実現され、WLSインスタンス間の通信は処理されますか。
A: Kubernetesクラスタ内で、オペレータはDOMAINUID-WEBLOGICSERVERNAMEという各WebLogic ServerポッドおよびDOMAINUID-cluster-CLUSTERNAMEという各WebLogicクラスタに対してKubernetes ClusterIPサービスを生成します。 オペレータは、WebLogicネットワークのリスニング・アドレス構成をオーバーライドして、これを実行する必要がないようにサービス名を反映します。 サービスはDNS名として機能し、WebLogic ServersのポッドがKubernetesクラスタ内の異なるノードに移動し、他のサーバーとの通信を続行できるようにします。
Q: Kubernetesクラスタの外部からの通信はどのように処理されますか。
A:
クラスタ外部のロケーションからアプリケーションへのHTTP通信: 通常、これは、トラフィックをドメインのKubernetesサービスにリダイレクトするロード・バランサをデプロイすることで実現されます(オペレータは、これらのサービスを自動的にデプロイします)。Ingressを参照してください。 例については、クイック・スタート(「オペレータおよびイングレス・コントローラのインストール」)を参照してください。
Kubernetesクラスタの外部のロケーションとのJMS、EJBおよびその他のタイプのRMI通信: これは通常、ロード・バランサを介してHTTP経由でRMIトラフィックをトンネリングすることで実現されます。または、Kubernetes NodePortsでT3またはT3Sを直接使用することで実現されることは少なくなります。外部WebLogicクライアントを参照してください。
WebLogic Server管理コンソールへのアクセス: これはロード・バランサを介して実行できます。Model in Imageサンプルを参照してください。 または、Kubernetes NodePortサービスを使用して実行し、$ kubectl explain domain.spec.adminServer.adminService.channelsを実行します。
WebLogic Remote Consoleへのアクセス: これは、ロード・バランサまたはKubernetes NodePortサービスを使用して実行できます。リモート・コンソールの使用を参照してください。
Q: マルチキャストとユニキャストの両方を使用して、クラスタはKubernetesでサポートされていますか。
A: ユニキャストのみがサポートされています。 ほとんどのKubernetesネットワーク・ファブリックは、マルチキャスト通信をサポートしていません。 マルチキャストをサポートすると主張するが、商用ネットワーク・ファブリックです。 ユニキャストのみをサポートするFlannelとCalicoで認定されています。
Q: EJBのバインディング(プレゼンテーション/ビジネス層)では、一意のドメイン名または動的ドメイン名(あるいはその両方)が使用されますか。
A: 一意のドメイン名は強制しません。 RMI/EJB/JMS/JTA/andを使用して相互運用する必要がある2つのドメイン、またはRMI/EJB/JMS/JTA/andなどのクライアントを共有するRMI/EJB/JMS/JTA/andを両方のドメインと同時に通信する場合は、通常どおり、ドメイン名が異なるように構成されている必要があります(domain-uidsが異なる場合でも)。
Q: DataCenter内部のロード・バランシングおよびフェイルオーバー(HTTPSおよびT3s)?
A: 当初は、Kubernetesクラスタを使用してTraefikで認証されていました。これは非常に基本的なロード・バランサです。 さらに高度なロード・バランサも認定されています。 Ingressを参照してください。
Q: 成長と縮小の対処方法 クラスタ・モードおよび非クラスタ・モード。
A: 様々なメソッドを使用して、構成済のWebLogicクラスタ(事前構成済の管理対象サーバー・セット)または動的WebLogicクラスタ(テンプレート化された管理対象サーバーを使用するクラスタ)をスケーリングおよび縮小できます。 「スケーリング」を参照してください。
kubectlを使用します。Q: コンテナのライフサイクル : コンテナ内のWLSを適切にスピン・アップして正常にシャットダウンするには?
A: オペレータはcontainer/pod/WebLogic Serverライフ・サイクルを自動的に管理し、ノード・マネージャ(内部)および追加のアプローチを使用して次の操作を実行します:
これらの操作は、Kubernetesコマンドライン・インタフェースkubectlを使用して手動で行うこともできます。
詳細は、「ドメインのライフサイクル」のドキュメントを参照してください。
Q: Kubernetes (個別パッチ、オーバーレイ、CPUなど)で実行するためにパッチが適用されたOracleコンテナ・イメージを取得するにはどうすればよいですか。
A: 事前パッチ済のイメージをOracle Container Registryからダウンロードするか、WebLogic Image Toolを使用して独自のイメージを作成します。 Oracle ContainerレジストリのWebLogicコンテナ・イメージの詳細は、「Oracle Container Registryからのイメージの取得」を参照してください。
WebLogic Image Toolを使用して新しいコンテナ・イメージを作成する方法の詳細は、「カスタム・イメージの作成」を参照してください。
Q: アプリケーションのアップ・タイムに影響を与えずにパッチを適用するには、どうすればいいですか。
A: ローリング再起動を参照してください。
Q: 継続的な統合および継続的なデプロイメント・プロセスとパッチ適用はどのように統合するのですか。
A: CI/CDに関する考慮事項を参照してください。
Q: エコシステムとの統合 : ロギング、モニタリング(OS、JVM、アプリケーション・レベルなど)。
A: WebLogic Server stdoutロギングはデフォルトでポッド・ログにエコーされ、WebLogic Serverファイル・ログはオプションで外部ボリュームに保持されます。 WebLogic ServerログをElastic Stackと統合するプロジェクトに取り組んでいます。 Elastic Stackを参照してください。
モニタリングに関しては、従来はWebLogic Serverをモニタリングするために使用するすべてのツールをコンテナおよびKubernetesで実行できます。 また、前述のように、PrometheusやGrafanaなどのダッシュボードで読取りおよび表示できる形式でWebLogicメトリクスをエクスポートするWebLogic Monitoring Exporterを開発しました。