WebLogic Server アプリケーションを Azure Kubernetes Service に移行する

  • [アーティクル]

このガイドでは、既存の WebLogic Server (WLS) アプリケーションを移行して Azure Kubernetes Service (AKS) で実行する場合に知っておくべきことについて説明します。

移行前

移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。

ターゲットが移行作業に適したターゲットであることを確認する

WLS アプリケーションを Azure に正常に移行する最初の手順は、最も適切な移行ターゲットを選択することです。 WLS は、Azure 仮想マシン (VM) または Azure Kubernetes Service (AKS) で適切に実行されます。 VM ターゲットは、オンプレミスのデプロイに最も近いため、最も簡単な選択です。 仮想マシンの管理とデプロイのエクスペリエンスは、オンプレミスにあるものに非常に似ています。 この容易さのトレードオフは、経済的コストです。 一般に、VM ベースのソリューションの 1 分あたりのコストは、AKS と比較して高くなります。 AKS ベースのソリューションの実行コストは低くなりますが、AKS の要件に合わせてアプリケーションを制限する必要があります。 変更を最小限に抑えることが移行作業の最も重要な要素である場合は、VM ベースの移行を検討してください。 この場合は、「WebLogic Server のアプリケーションを Azure Virtual Machines に移行する」を参照してください。 Kubernetes 内で実行するようにアプリケーションを変換してランタイム コストを削減できる場合は、AKS ベースの移行を検討してください。 この場合は、「WebLogic Server アプリケーションを Azure Kubernetes Service に移行する」に進みます。

事前構築済みの Azure Marketplace オファーが適切な出発点であるかどうか判断する

AKS が適切なデプロイ ターゲットであると判断したら、Oracle WLS Kubernetes Operator (演算子) が Kubernetes で WLS を実行する唯一の方法であることを受け入れる必要があります。 この事実を受け入れた後、事前構築済みの Azure Marketplace オファーが適切な出発点であるかどうかを判断する必要があります。 事前構築済みの Azure Marketplace オファーについて考慮すべき点を次に示します。

  • Oracle と Microsoft は、このオファーを作成して、イメージ内のモデル ドメイン ホーム ソース タイプを使用して、AKS に WLS をすばやくプロビジョニングできるようにします。 この概念については、この記事の後半で詳しく説明します。
  • 大まかに言えば、オファーによって次の手順が自動化されます。
    • 必要に応じて、既存の WAR デプロイまたは EAR デプロイを実行します。
    • WebLogic Image Tool (WIT) を使用してコンテナーにラップします。 詳細については、Oracle のマニュアルの「WebLogic Image Tool」を参照してください。
    • AKS に WebLogic Kubernetes Operator をインストールして構成します。
    • 演算子を使用して全体を実行します。 演算子は WebLogic Deploy Tooling (WDT) を呼び出して WebLogic 環境を立ち上げ、メタデータ モデルに基づいて反復可能な方法でドメイン ライフサイクル操作を実行します。 詳細については、Oracle のマニュアルの「WebLogic Deploy Tooling」を参照してください。
  • 事前構築済みのオファーでは、App Gateway、Elastic ログ、データベース統合など、多数の Azure サービス統合が提供されますが、多くの前提条件が簡素化されます。 これらの前提により、このオファーは、演算子を自分でマスタリングして使用する場合ほど柔軟ではありません。

事前構築済みの Azure Marketplace オファーを使用しない場合は、演算子を直接使用する方法を学習する必要があります。 演算子の習得については、この記事の範囲外です。 WLS Kubernetes Operator の完全なドキュメントは、Oracle にあります。

このセクションの残りの部分では、事前構築済みの Azure Marketplace オファーを使用するか、演算子を直接使用するかを決定するための考慮事項について説明します。

まず、WLS 「ドメイン」の概念を理解する必要があります。 ドメインは、論理的に関連した WLS リソースのグループです。 WLS ドメインの正規定義については、「Oracle のマニュアル」を参照してください。 AKS 上で WLS を実行するには、AKS がドメインをどのように扱うかを決定する必要があります。 さまざまな選択肢を「ドメイン ホーム ソース タイプ」と呼びます。 WLS Kubernetes Operator は、ドメイン ホーム ソース タイプの 3 つの選択肢をサポートしています。 事前構築済みの Azure Marketplace オファーでは、この表の最初のものを使用します。

ドメイン ホーム ソース タイプ 説明 肯定的な側面 否定的な側面
イメージ内のモデル WLS とアプリケーションはコンテナー イメージ内にあり、それ以外はすべてそのイメージの外部に保持されます。 事前構築済みプランでサポートされます。 公式サンプルとして文書化されています。「Oracle」を参照してください。 ほとんどの場合、WDT が頻繁に使用されます。 ほとんどの「クラウドネイティブ」オプション。 最も単純な CI/CD 統合。 最大の学習曲線。
PV のドメイン ドメインは Kubernetes 永続ボリューム上に存在します。 概念的には、VM での実行に似ています。 WLS コンソールを使用して変更を行います。これらの変更は AKS ポッドの再起動後も保持されます。 公式サンプルとして文書化されています。「Oracle」を参照してください。 NFS に関連するいくつかの課題を軽減する必要があります。 詳細については、「Oracle」を参照してください。 このアプローチは、最も「クラウドネイティブ」ではない手法です。状態は完全に AKS クラスターの外側に存在します。
イメージ内のドメイン ドメインはコンテナー イメージ内に存在します。 アプリケーションは、ドメイン イメージにオーバーレイされたコンテナー イメージに含まれています。 PV 内のドメイン以外の「クラウドネイティブ」。 CI/CD の方が簡単です。 WLS コンソールを使用できません。 より多くのコンテナー イメージを維持する必要があります。

重要

PV 内のドメイン ソース タイプを選択した場合は、SMB ではなく NFS を強くお勧めします。 NFS は UNIX オペレーティング システムや GNU/Linux などの他のバリアントから進化しました。 このため、Docker などのコンテナー テクノロジで NFS を使用する場合、同時読み取りとファイル ロックの問題が発生する可能性は低くなります。

NFS v4.1 を有効にしてください。 v4.1 より前のバージョンでは問題が発生します。

演算子のドキュメントには、さまざまなオプションを比較する便利なテーブルも含まれています。 詳細については、「ドメイン ホーム ソース タイプを選択する」を参照してください。

事前構築済みの Azure Marketplace オファーを理解するには、「クイック スタート: Azure portal を使用して Azure Kubernetes Service に WebLogic Server をデプロイする」を参照してください。 事前構築済みの Azure Marketplace オファーのリファレンス ドキュメントについては、「Oracle」を参照してください。

演算子を直接使用する感覚をつかむには、「演算子のドキュメント」のサンプルを試してください。

AKS で WLS ドメインを処理するさまざまな方法を紹介しました。事前構築済みの Azure Marketplace オファーを使用するか、演算子を直接使用して自分で行うかを選択できるようになりました。

WebLogic バージョンに互換性があるかどうか確認する

既存の WLS バージョンは、演算子がサポートするバージョンのいずれかである必要があります。 Oracle はこれらのバージョンを Oracle Container Registry (OCR) で維持しています。 サポートされているバージョンの一覧を表示するには、次の手順に従います。

  1. Oracle Container Registry の Web サイトにアクセスしてログインします。 詳細については、https://container-registry.oracle.com/を参照してください。
  2. サポート資格がある場合は、[ミドルウェア] を選択して、[weblogic_cpu] を検索します。 [weblogic_cpu] を選択します。
  3. Oracle からのサポート資格がない場合は、[ミドルウェア] を選択して、[weblogic] を検索します。 [weblogic] を選択します。

Note

運用環境に移行する前に、Oracle からサポート エンタイトルメントを取得してください。 これを行わないと、セキュリティ上のクリティカルな欠陥に対してパッチが適用されていない安全でないイメージを実行することになります。 Oracle の重要なパッチの更新の詳細については、「重要なパッチの更新、セキュリティ アラートおよびセキュリティ情報」を参照してください。

事前構築済みの Azure Marketplace オファーを使用すると、OCR と Azure Container Registry (ACR) から WLS イメージを選択できるため、OCR から使用できるすべてのバージョンが暗黙的にサポートされます。 オファーに ACR からイメージをプルするように指示する場合は、OCR に記載されているサポートされているバージョンのいずれかから派生していることを確認します。

サーバー容量をインベントリする

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 たとえば、ノード プール内の VM のサイズ、コンテナーによって使用されるメモリの量、コンテナーが必要とする CPU 共有の数などの選択に役立ちます。

AKS でノード プールのサイズを変更できます。 方法については、「Azure Kubernetes Service (AKS) でノード プールのサイズを変更する」を参照してください。

すべてのシークレットをインベントリする

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。 WebLogic Server などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。 すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 必ず、WAR 内の weblogic.xml を確認してください。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 詳細については、「Azure Key Vault の基本的な概念」をご覧ください。

シークレットの強固なインベントリを作成したら、シークレットに関する演算子のドキュメントを参照してください。 詳細については、「シークレット」を参照してください。

すべての証明書をインベントリする

パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。

keytool -list -v -keystore <path to keystore>

証明書の強固なインベントリを作成したら、事前構築済みの Azure Marketplace オファーを使用して証明書を直接インストールできます。 詳細については、「TLS/SSL の構成」を参照してください。 演算子を直接使用している場合は、「演算子の外部証明書の更新」を参照してください。

サポートされている Java バージョンが正しく動作することを検証する

Azure への WebLogic の移行パスのすべてにおいて、パスごとに異なる特定の Java バージョンが必要です。 そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。

Note

現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。

現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。

java -version

Note

Azure 仮想マシン上の WLS に移行する場合、特定の Java バージョンの要件は、仮想マシンにプレインストールされている Java によって決まります。 AKS 上の WLS に移行する場合、特定の Java バージョンは、選択したコンテナー イメージによって決まります。 さまざまな選択肢がありますが、それらはすべて Oracle JDK を使用します。

JNDI リソースをインベントリする

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、Oracle ドキュメントの「WebLogic Server データ・ソース」を参照してください。 JMS メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。 JMS の構成の詳細については、Oracle WebLogic Server 12.2.1.4.0 を参照してください。

事前構築済みの Azure Marketplace オファーを使用している場合、デプロイ時にカスタマイズできる JNDI リソースのセットは、オファーがサポートするものに制限されます。 オファーのドキュメントのJNDI を検索してください。 演算子を直接使用している場合は、選択したドメイン ホーム ソース タイプに応じて JDNI リソースを定義できます。 PV 内のドメインでは、WLST または管理コンソールを使用して、通常の方法で設定できます。 イメージ内のドメインまたはイメージ内のモデルでは、「通常のオーバーライド」を参照してください。

ドメインの構成を検査する

WebLogic Server の主な構成単位は、ドメインです。 そのため、config.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。 このファイルには、サブディレクトリに格納されている追加の XML ファイルへの参照が記載されています。 Oracle では、通常、[管理コンソール] を使用して WebLogic Server の管理可能なオブジェクトとサービスを構成し、WebLogic Server で config.xml ファイルを保守できるようにすることを推奨しています。 詳細については、「ドメイン構成ファイル」を参照してください。

アプリケーション内

WEB-INF/weblogic.xml ファイルおよび WEB-INF/web.xml ファイルを調べます。

事前構築済みの Azure Marketplace オファーにより、ドメイン リソースが自動的に作成されます。 演算子を直接使用している場合は、ドメインの表示方法を完全にカスタマイズできます。 詳細については、「ドメイン リソース」を参照してください。

セッション レプリケーションが使用されているかどうか確認する

Oracle の Coherence*Web の有無にかかわらず、アプリケーションがセッション レプリケーションに依存している場合は、次の 3 つの選択肢があります。

  • Coherence*Web は、Azure 仮想マシンで WebLogic Server と共に実行できますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。 スタンドアロン Coherence を使用している場合は、Azure の仮想マシンでそれを実行することもできますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。 詳細については、「Azure Cache for Redis」を参照してください。

これらのすべての選択肢において、WebLogic が HTTP セッション状態のレプリケーションを行う方法を習得することをお勧めします。 詳細については、Oracle のドキュメントの「HTTP セッション状態のレプリケーション」を参照してください。

事前構築済みの Azure Marketplace オファーでは、Application Gateway イングレス コントローラーを介したセッション アフィニティがサポートされます。 オファーをデプロイするときに、[Cookie ベースのアフィニティを有効にする] を選択します。 「オファーのドキュメンテーション」で Cookie ベースのアフィニティを検索します。

データソースの文書化

アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。

  • データソース名
  • 接続プールの構成
  • JDBC ドライバーの JAR ファイルの場所

WebLogic の JDBC ドライバーの詳細については、「WebLogic Server での JDBC ドライバの使用方法」を参照してください。

事前構築済みの Azure Marketplace オファーでは、最も一般的なデータベースがサポートされています。 詳細については、「データベース」を参照してください。 PV 内のドメインでは、WLST または管理コンソールを使用して、通常の方法で設定できます。 イメージ内のドメインまたはイメージ内のモデルでは、「通常のオーバーライド」を参照してください。

WebLogic がカスタマイズされているかどうか確認する

次のうち、どのカスタマイズが行われたかを確認し、作業内容を把握します。

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、setDomainEnv、commEnv、startWebLogic、stopWebLogic などがあります。
  • JVM に渡される特定のパラメーターはありますか?
  • サーバーのクラスパスに追加された JAR はありますか?

これらのカスタマイズは、AKS によって実行されるコンテナー イメージでキャプチャする必要があります。 事前構築済みの Azure Marketplace オファーの場合、このようなカスタマイズは、カスタム コンテナー イメージを作成し、Azure Container Registry で使用できるようにすることで最適に処理され、デプロイ時にそのレジストリをポイントします。 詳細については、「イメージの選択」を参照してください。 演算子を直接使用している場合は、「JVM メモリと Java オプション環境変数」を参照してください。

REST 経由の管理が使用されているかどうか確認する

アプリケーションのライフサイクルに REST 経由の管理の使用が含まれている場合は、REST API にアクセスするために使用されているポートを把握し、それらがどのように認証され、公開されているかを確認する必要があります。 移行後、アプリケーションのライフサイクルが移行前と同様の方法で動作できるように、これらの同じポートと認証メカニズムが公開されていることを確認する必要があります。 詳細については、「RESTful 管理サービスによる Oracle WebLogic Server の管理」を参照してください。

REST 経由で管理を使用し続けることが合理的な唯一のドメイン ホーム ソース タイプは、PV 内のドメインです。 他の ドメイン ホーム ソース タイプと共に使用できますが、加えられた変更は一時的なものであり、ポッドを再起動すると保持されません。

オンプレミスへの接続が必要かどうかを判断する

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、「オンプレミス ネットワークを Azure に接続するためのソリューションを選択する」をご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。

Java Message Service (JMS) キューまたはトピックが使用中かどうか確認する

アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行する必要があります。 Azure Service Bus と Advanced Message Queuing Protocol は、JMS を使用している場合の優れた移行方法となります。 詳細については、「Azure Service Bus と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。

JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。

Oracle メッセージ ブローカーを使用している場合は、このソフトウェアを Azure 仮想マシンに移行し、そのまま使用できます。

独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認する

共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。

  • アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。
  • サーバーのクラスパスにそれらのライブラリを追加します。

これらのライブラリは、「WebLogic がカスタマイズされているかどうか確認する」の説明と同じ手法を使用して処理できます。

OSGi バンドルが使用されているかどうか確認する

WebLogic Server に追加されている OSGi バンドルを使用した場合は、同等の JAR ファイルを Web アプリケーションに直接追加する必要があります。

事前構築済みの Azure Marketplace オファーに提供される WAR または EAR に含めることも、演算子を直接使用することもできます。

アプリケーションに OS 固有のコードが含まれているかどうかを判断する

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで / または \ を使用している場合、File.Separator または Paths.get に置き換えることが必要になる可能性があります。

AKS 上の WLS は Oracle Linux 上で実行されます。 OS 固有のコードは、Oracle Linux と互換性がある必要があります。 特定の OS 情報を検出する方法については、「WebLogic バージョンに互換性があるかどうか確認する」の手順に従ってください。

Oracle Service Bus が使用されているかどうか確認する

アプリケーションが Oracle Service Bus (OSB) を使用している場合は、OSB がどのように構成されているかを把握する必要があります。 詳細については、「Oracle Service Bus のインストールについて」を参照してください。

OSB は、事前構築済みの Azure Marketplace オファーでは直接サポートされていません。 OSB を使用する必要がある場合は、演算子を直接使用する必要があります。

アプリケーションが複数の WAR で構成されているかどうか確認する

アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。

アプリケーションが EAR としてパッケージ化されているかどうか確認する

アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ず application.xml および weblogic-application.xml ファイルを調べて、その構成を把握してください。

事前構築済みの Azure Marketplace オファーでは、WAR と EAR がサポートされています。 演算子を直接使用すると、WAR と EAR もサポートされます。

実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する

デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。

WebLogic Scripting Tool (WLST) を使用しているかどうか確認する

現在、WLST を使用してデプロイを実行している場合は、実行内容を評価する必要があります。 WLST がデプロイの一部としてアプリケーションの (ランタイム) パラメーターを変更している場合は、移行後にアプリケーションをテストする際、この動作が引き続き機能することを確認する必要があります。

WLST の使用と互換性がある唯一の ドメイン ホーム ソース タイプは、PV 内のドメインです。 詳細については、「PV 上のドメイン ホーム」を参照してください。

ファイル システムが使用されているかどうかとその使用方法を判断する

Kubernetes は、永続ボリューム (PV) を持つファイル システムを扱います。 永続ボリュームのマウントは、事前構築済みの Azure Marketplace オファーでサポートされており、演算子を直接使用する場合でもサポートされています。 PV 内のドメインを使用している場合、ファイル システムは構成の中心的な側面です。

読み取り専用の静的コンテンツ

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。 詳細については、「Azure Storage での静的 Web サイト ホスティング」と「クイック スタート:Azure ストレージ アカウントと Azure CDN との統合」を参照してください。 また、Azure Spring Apps Enterprise プランのアプリに静的コンテンツを直接デプロイすることもできます。 詳細については、「Web の静的ファイルのデプロイ」を参照してください。

動的に公開される静的コンテンツ

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。 「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。 また、Azure Spring Apps Enterprise プランのアプリに静的コンテンツを直接デプロイすることもできます。 詳細については、「Web の静的ファイルのデプロイ」を参照してください。

ネットワーク トポロジを決定する

Azure Marketplace オファーの現在のセットが、移行の出発点となります。 移行する必要があるアーキテクチャの側面がオファーに含まれていない場合は、ソリューション テンプレートの 1 つを使用して基本的なオファーを立ち上げた後でも、既存のデプロイのネットワーク トポロジを把握し、Azure で再現する必要があります。

これは非常に広範なトピックですが、次のリファレンスを使用すると、移行作業に多少の方向性を打ち出すことができます。

  • このリファレンスは、「Fast Track Deployment Guide」にある、Azure へのネットワーク トポロジの移行に関連するトピックの概要を列挙しています。
  • このリファレンスでは、「WebLogic Server Clustering」にある、ネットワーク トポロジに影響を与えるクラスタリングに関する重要事項について説明しています。
  • データ ソースは WebLogic システム内の別々のサーバーであるため、ネットワークト ポロジ分析の一部としてそれらを考慮する必要があります。 「WebLogic Server データ・ソース」。
  • メッセージング ソースも別々のサーバーです。 「WebLogic Sever メッセージング」
  • 負荷分散は、基本要件です。 このリファレンスでは、「Load Balancing in a Cluster」にある、負荷分散の WebLogic Server 側について説明しています。

JCA アダプターとリソース アダプターの使用の考慮

デプロイがリソース アダプターに依存している場合、最もサポートされているオプションは、PV 上のドメイン ホームです。

カスタム セキュリティ プロバイダーと JAAS の使用の考慮

アプリケーションで JAAS を使用している場合は、セキュリティ プロバイダーの構成が正しく移行されていることを確認する必要があります。 詳細については、Oracle のドキュメントの「WebLogic セキュリティ・プロバイダの構成について」を参照してください。

デプロイがセキュリティ プロバイダーに依存している場合、最もサポートされているオプションは、PV 上のドメイン ホームです。

WebLogic クラスタリングが使用されているかどうか確認する

演算子は、AKS で WLS を実行する可能性のあるすべての方法でクラスタリングを処理します。

EJB クラスタリングを検査する

アプリケーションがローカル EJB を使用している場合は、それらをクラスター化された EJB に移行する必要があります。 詳細については、「クラスター化された EJB とローカル EJB」を参照してください。

負荷分散の要件の考慮

負荷分散を考慮する最善の方法は、組み込みの Azure Marketplace オファーによって提供される App Gateway 統合を使用することです。 詳細については、「チュートリアル: ロード バランサーとして Azure Application Gateway を使用して、Azure に WebLogic Server クラスターを移行する」を参照してください。

Java EE アプリケーション クライアント機能が使用されているかどうか確認する

デプロイが Java Enterprise Edition アプリケーション クライアントに依存している場合は、演算子を直接使用することをお勧めします。 詳細については、「外部クライアント」を参照してください。

複数のコンテナー イメージが必要かどうかを判断する

WebLogic Server ドメインには複数のクラスターを含めることができます。 たとえば、多層アプリケーションは 1 つのドメインで表現できますが、「フロントエンド」と「バックエンド」という 2 つのクラスターがあります。 バックエンドを更新せずに、フロントエンドを更新できると便利です。その逆も同様です。 ただし、イメージ内のモデル ドメイン ホーム ソース タイプでは、ドメイン全体が 1 つのコンテナー イメージで表示されます。 このユース ケースに対応するには、クラスターをそれぞれ独自のコンテナー イメージを持つ独自のドメインに分割する必要があります。 演算子は、複数の名前空間で複数のドメインを管理できます。 詳細については、「ドメイン名前空間の選択戦略の選択」を参照してください

複数のドメインを採用すると、ドメイン間で T3 アクセスの問題が発生する可能性があります。 これらの問題を解決するには、「不明なホスト アクセスを有効にする必要あるかどうかを判断する」の説明に従ってカスタム チャネルを有効にします。

不明なホスト アクセスを有効にする必要があるかどうかを判断する

次のシナリオでは、WebLogic にパッチを適用して、不明なホスト アクセスを有効にする必要がある場合があります。

  • カスタム チャネルを介して AKS の外部クライアントから AKS の WLS クラスターへの T3 アクセスを許可します。
  • カスタム チャネル経由で AKS の異なる WLS ドメイン間で T3 アクセスを許可します。

パッチの詳細については、「My Oracle Support (MOS) でパッチ検索を使用する方法」のガイダンスに従い、パッチを検索します30656708。

パッチが適用されたら、「不明なホスト アクセスを有効にする」を参照してください。

移行

このセクションの手順では、分析によって事前構築済みの Azure Marketplace オファーを使用することを決定していることを前提としています。

オファーをプロビジョニングする

Azure portal でオファーを開くには、「https://aka.ms/wlsaks」を参照してください。 [作成] を選択し、オファーのドキュメンテーションの指示に従います。 前の手順で収集した情報を使用して、オファーのフィールドに入力します。

ドメインの移行

オファーをプロビジョニングしたら、次の手順に従ってドメインを出力します。

[デプロイが進行中です] ページから移動した場合は、次の手順でそのページに戻る方法について説明します。 [デプロイが完了しました] と示されたページが表示されたままの場合は、5 つ目の手順にスキップできます。

  1. ポータル ページの左上にあるハンバーガー メニューを選択し、[リソース グループ] を選択します。

  2. [任意のフィールドのフィルター] というテキストが表示されているボックスに、前に作成したリソース グループの最初の数文字を入力します。 推奨される方法に従った場合は、名前のイニシャルを入力してから、適切なリソース グループを選択します。

  3. 左側のナビゲーション ウィンドウの [設定] セクションで、[デプロイ] をすると、このリソース グループへのデプロイの順序付けされた一覧が表示され、最新のものが最初に表示されます。

  4. このリストの一番古いエントリまでスクロールします。 このエントリは、前のセクションで開始したデプロイに対応します。 次のスクリーンショットに示すように、一番古いデプロイを選択します。

    Screenshot of Azure portal showing the resource group deployments list.

  5. 左側のパネルで、[出力] を選択します。 このリストには、そのデプロイの出力値が表示されます。 出力には有用な情報が含まれています。 ドメインを検査して演算子と対話できるようにする出力に興味があります。 出力のその他の値については、「AKS での WebLogic ユーザー ガイド」で詳しく説明されています。

  6. shellCmdtoConnectAksという名前の出力を見つけます。 出力の値を Bash シェルに貼り付け、コマンドを実行します。 このコマンドを使用すると、「クラスターへの接続」の説明に従って、kubectl を使用できます。

  7. shellCmdtoOutputWlsDomainYamlという名前の出力を見つけます。 出力の値を Bash シェルに貼り付け、コマンドを実行します。 このコマンドは、ドメイン リソースを YAML ファイルとして出力します。

  8. 現在のデプロイメントのドメイン YAML が作成されたので、「ドメイン リソース YAML ファイルのデプロイ」の知識を適用し、このガイダンスを参照してドメインを移行する方法に関する手がかりを得ることができます。 このガイダンスでは、Kubernetes の操作方法に適応する必要がありますが、知っておくと依然として役に立ちます。

キーストアの考慮

アプリケーションで使用されるすべての SSL キーストアの移行を考慮する必要があります。 詳細については、「キーストアの構成」を参照してください。

JMS ソースの接続

データベースに接続した後、WebLogic のドキュメントの「Fusion Middleware Oracle WebLogic Server JMS リソースの管理」の手順に従って JMS を構成できます。

ログの考慮

ログ記録をマスターしないとクラウドを実行できません。 演算子は、Elasticsearch と Kibana を使用するためのサンプルを提供します。 詳細については、演算子のドキュメントを参照してください。 Azure では、Elastic の優れたサポートが提供されます。 詳細については、「Elastic と Azure の統合とは ?」を参照してください。 これら 2 つのリソースの知識を組み合わせて、AKS 上の WLS 用の Azure 最適化ログ ソリューションを実現できます。

アプリケーションの移行

デプロイ時に WAR ファイルまたは EAR ファイルを提供することを選択したかどうかにかかわらず、CI/CD を使用してアプリケーションを更新する必要があります。 演算子のドキュメントには、この更新を行う方法を示すサンプルがあります。 詳細については、「Update 3」を参照してください。 その他の更新プログラムのサンプルは移行に関連しており、検討する価値があります。

テスト

アプリケーションに対するコンテナー内テストは、Azure 内で実行されている新しいサーバーにアクセスするように構成する必要があります。 CI/CD に関する考慮事項と同様に、ネットワーク セキュリティ規則により、Azure にデプロイされたアプリケーションにテストでアクセスできるようにする必要があります。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

移行後

「移行前」ステップで定義した移行の目標に到達したら、エンド ツー エンドの受け入れテストを実施して、すべてが予期したとおりに機能することを確認します。 移行後の拡張機能の可能性に関するガイダンスについては、次の推奨事項を参照してください。