WebLogic Server のアプリケーションを Azure Virtual Machines に移行するMigrate WebLogic Server applications to Azure Virtual Machines

このガイドでは、既存の WebLogic アプリケーションを移行して Azure Virtual Machines で実行する場合に知っておくべきことについて説明します。This guide describes what you should be aware of when you want to migrate an existing WebLogic application to run on Azure Virtual Machines. Azure Marketplace で入手できる WebLogic Server ソリューションの概要については、「Azure の Oracle WebLogic Server とは」を参照してください。For an overview of available WebLogic Server solutions in the Azure Marketplace see What is Oracle WebLogic Server on Azure?

移行前Pre-migration

移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。To ensure a successful migration, before you start, complete the assessment and inventory steps described in the following sections.

"移行の完了" が意味することを定義するDefine what you mean by "migration complete"

このガイドおよび対応する Azure Marketplace オファーが、WebLogic Server ワークロードの Azure への移行を促進するための出発点となります。This guide, and the corresponding Azure Marketplace Offers, are a starting point to accelerate the migration of your WebLogic Server workloads to Azure. 移行作業の範囲を定義することが重要です。It's important to define the scope of your migration effort. たとえば、既存のインフラストラクチャから Azure Virtual Machines に厳密な "リフト アンド シフト" を行うのでしょうか。For example, are you doing a strict "lift and shift" from your existing infrastructure to Azure Virtual Machines? その場合、移行の際に多少の "リフト アンド改良" を取り入れたくなる可能性があります。If so, you may be tempted to work in some "lift and improve" as you migrate.

このガイドで詳しく説明されている必要な変更を考慮して、できるだけ純粋な "リフ トアンド シフト" に近づけることをお勧めします。It's better to stick as close to pure "lift and shift" as possible, accounting for the necessary changes as detailed in this guide. このマイルストーンに到達したことがわかるように、"移行の完了" が意味することを定義してください。Define what you mean by "migration complete" so that you know when you've reached this milestone. "移行の完了" に到達したら、「スナップショットの作成」の説明に従って、Virtual Machines のスナップショットを取得できます。When you've reached your "migration complete", you can take a snapshot of your Virtual Machines as described in Create a snapshot. スナップショットから正常に復元できることを確認した後は、これまでに達成した移行の進捗を無駄にする心配なしに、より安心して機能強化を行えます。After you've verified that you can successfully restore from your snapshot, it's safer to do the improvements without fear of losing the migration progress you've achieved thus far.

事前構築済みの Marketplace オファーが適切な出発点であるかどうか判断するDetermine whether the pre-built Marketplace offers are a good starting point

Oracle と Microsoft は提携して、Azure ソリューション テンプレートのセットを Azure Marketplace に導入し、Azure への移行の確固たる出発点を提供しています。Oracle and Microsoft have partnered to bring a set of Azure solution templates to the Azure Marketplace to provide a solid starting point for migrating to Azure. Oracle Fusion Middleware」ドキュメントでオファーの一覧を参照し、既存のデプロイに最も適合するものを選択してください。Consult the Oracle Fusion Middleware documentation for the list of offers and choose the one that most closely matches your existing deployment. オファーの一覧は、概要記事の「Azure の Oracle WebLogic Server とは」で確認できます。You can see the list of offers in the overview article What is Oracle WebLogic Server on Azure?

既存のオファーがいずれも適切な開始点でない場合は、Azure 仮想マシンのリソースを使用して手動でデプロイを再現する必要があります。If none of the existing offers are a good starting point, you'll have to reproduce the deployment by hand using Azure Virtual Machine resources. 詳細については、「IaaS とは」を参照してください。For more information, see What is IaaS?.

WebLogic バージョンに互換性があるかどうか確認するDetermine whether the WebLogic version is compatible

既存の WebLogic バージョンは、IaaS オファーのバージョンと互換性がある必要があります。Your existing WebLogic version must be compatible with the version in the IaaS offers. このクエリでは、WebLogic バージョン 12.2.1.3 のオファーが表示されます。This query will show the offers for WebLogic version 12.2.1.3. 既存の WebLogic バージョンがそのバージョンと互換性がない場合は、Azure IaaS リソースを使用して手動でデプロイを再現する必要があります。If your existing WebLogic version is not compatible with that version, you'll have to reproduce the deployment by hand using Azure IaaS resources. 詳細については、Azure のドキュメントを参照してください。For more information, see the Azure documentation.

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

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。Document the hardware (memory, CPU, disk) of the current production server(s) as well as the average and peak request counts and resource utilization. この情報により、VM サイズの選択がわかります。This information must inform the choice of VM size. 詳細については、「クラウド サービスのサイズを構成する」を参照してください。For more information, see Sizes for Cloud Services.

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

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。Before the advent of "configuration as a service" technologies such as Azure Key Vault, there wasn't a well-defined concept of "secrets". 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。Instead, you had a disparate set of configuration settings that effectively functioned as what we now call "secrets". WebLogic Server などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。With app servers such as WebLogic Server, these secrets are in many different config files and configuration stores. すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。Check all properties and configuration files on the production server(s) for any secrets and passwords. 必ず、WAR 内の weblogic.xml を確認してください。Be sure to check weblogic.xml in your WARs. また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。Configuration files containing passwords or credentials may also be found inside your application. 詳細については、「Azure Key Vault の基本的な概念」をご覧ください。For more information, see Azure Key Vault basic concepts.

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

パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。Document all the certificates used for public SSL endpoints. 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。You can view all certificates on the production server(s) by running the following command:

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

サポートされている Java バージョンが正しく動作することを検証するValidate that the supported Java version works correctly

Azure への WebLogic の移行パスのすべてにおいて、パスごとに異なる特定の Java バージョンが必要です。All of the migration paths for WebLogic to Azure require a specific Java version, which varies for each path. そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。You'll need to validate that your application is able to run correctly using that supported version.

注意

現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。This validation is especially important if your current server is running on an unsupported JDK (such as Oracle JDK or IBM OpenJ9).

現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。To obtain your current Java version, sign in to your production server and run the following command:

java -version

注意

Azure 仮想マシン上の WebLogic に移行する場合、特定の Java バージョンの要件は、仮想マシンにプレインストールされている Java によって決まります。When migrating to WebLogic on Azure virtual machines, the requirements for the specific Java versions are determined by the pre-installed Java on the virtual machines.

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

すべての JNDI リソースをインベントリします。Inventory all JNDI resources. たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。For example, datasources such as databases may have an associated JNDI name that allows JPA to correctly bind instances of EntityManager to a particular database. JNDI リソースとデータベースの詳細については、Oracle ドキュメントの「WebLogic Server データ・ソース」を参照してください。For more information on JNDI resources and databases, see WebLogic Server Data Sources in the Oracle documentation. JMS メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。Other JNDI-related resources, such as JMS message brokers, may require migration or reconfiguration. JMS 構成の詳細については、「JMS リソース構成の理解」を参照してください。For more information on JMS configuration see Understanding JMS Resource Configuration.

ドメインの構成を検査するInspect your domain configuration

WebLogic Server の主な構成単位は、ドメインです。The main configuration unit in WebLogic Server is the domain. そのため、config.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。As such, the config.xml file contains a wealth of configuration that you must carefully consider for migration. このファイルには、サブディレクトリに格納されている追加の XML ファイルへの参照が記載されています。The file includes references to additional XML files that are stored in subdirectories. Oracle では、通常、 [管理コンソール] を使用して WebLogic Server の管理可能なオブジェクトとサービスを構成し、WebLogic Server で config.xml ファイルを保守できるようにすることを推奨しています。Oracle advises that you should normally use the Administration Console to configure WebLogic Server's manageable objects and services and allow WebLogic Server to maintain the config.xml file. 詳細については、「ドメイン構成ファイル」を参照してください。For more information, see Domain Configuration Files.

アプリケーション内Inside your application

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

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

Oracle の Coherence*Web の有無にかかわらず、アプリケーションがセッション レプリケーションに依存している場合は、次の 3 つの選択肢があります。If your application relies on session replication, with or without Oracle Coherence*Web, you have three options:

  • Coherence*Web は、Azure 仮想マシンで WebLogic Server と共に実行できますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。Coherence*Web can run alongside a WebLogic Server in the Azure virtual machines, but you must manually configure this option after you provision the offer. スタンドアロン Coherence を使用している場合は、Azure の仮想マシンでそれを実行することもできますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。If you are using standalone Coherence, you can also run it in an Azure virtual machine, but you must manually configure this option after you provision the offer.
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。Refactor your application to use a database for session management.
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。Refactor your application to externalize the session to Azure Redis Service. 詳細については、「Azure Cache for Redis」を参照してください。For more information, see Azure Cache for Redis.

これらのすべての選択肢において、WebLogic が HTTP セッション状態のレプリケーションを行う方法を習得することをお勧めします。For all of these options, it's a good idea to master how WebLogic does HTTP Session State Replication. 詳細については、Oracle のドキュメントの「HTTP セッション状態のレプリケーション」を参照してください。For more information, see HTTP Session State Replication in the Oracle documentation.

データソースの文書化Document datasources

アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。If your application uses any databases, you need to capture the following information:

  • データソース名What is the datasource name?
  • 接続プールの構成What is the connection pool configuration?
  • JDBC ドライバーの JAR ファイルの場所Where can I find the JDBC driver JAR file?

WebLogic の JDBC ドライバーの詳細については、「WebLogic Server での JDBC ドライバの使用方法」を参照してください。For more information on JDBC drivers in WebLogic, see Using JDBC Drivers with WebLogic Server.

WebLogic がカスタマイズされているかどうか確認するDetermine whether WebLogic has been customized

次のうち、どのカスタマイズが行われたかを確認し、作業内容を把握します。Determine which of the following customizations have been made, and capture what's been done.

  • スタートアップ スクリプトは変更されていますか?Have the startup scripts been changed? このようなスクリプトには、setDomainEnvcommEnvstartWebLogicstopWebLogic などがあります。Such scripts include setDomainEnv, commEnv, startWebLogic, and stopWebLogic.
  • JVM に渡される特定のパラメーターはありますか?Are there any specific parameters passed to the JVM?
  • サーバーのクラスパスに追加された JAR はありますか?Are there JARs added to the server classpath?

REST 経由の管理が使用されているかどうか確認するDetermine whether Management over REST is used

アプリケーションのライフサイクルに REST 経由の管理の使用が含まれている場合は、REST API にアクセスするために使用されているポートを把握し、それらがどのように認証され、公開されているかを確認する必要があります。If the lifecycle of your application includes using Management over REST, you need to capture which ports are used to access the REST API and determine how they are authenticated and exposed. 移行後、アプリケーションのライフサイクルが移行前と同様の方法で動作できるように、これらの同じポートと認証メカニズムが公開されていることを確認する必要があります。After migration, you'll need to ensure that these same ports and authentication mechanisms are exposed so your application lifecycle can operate in a similar fashion as before the migration. 詳細については、「RESTful 管理サービスによる Oracle WebLogic Server の管理」を参照してください。For more information, see Administering Oracle WebLogic Server with RESTful Management Services.

オンプレミスへの接続が必要かどうかを判断するDetermine whether a connection to on-premises is needed

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。If your application needs to access any of your on-premises services, you'll need to provision one of Azure's connectivity services. 詳しくは、「オンプレミス ネットワークを Azure に接続するためのソリューションを選択する」をご覧ください。For more information, see Choose a solution for connecting an on-premises network to Azure. または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。Alternatively, you'll need to refactor your application to use publicly available APIs that your on-premises resources expose.

Java Message Service (JMS) キューまたはトピックが使用中かどうか確認するDetermine whether Java Message Service (JMS) Queues or Topics are in use

アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行する必要があります。If your application is using JMS Queues or Topics, you'll need to migrate them to an externally-hosted JMS server. Azure Service Bus と Advanced Message Queuing Protocol は、JMS を使用している場合の優れた移行方法となります。Azure Service Bus and the Advanced Message Queuing Protocol can be a great migration strategy for those using JMS. 詳細については、「Azure Service Bus と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。For more information, see Use JMS with Azure Service Bus and AMQP 1.0.

JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。If JMS persistent stores have been configured, you must capture their configuration and apply it after the migration.

Oracle メッセージ ブローカーを使用している場合は、このソフトウェアを Azure 仮想マシンに移行し、そのまま使用できます。If you're using Oracle Message Broker, you can migrate this software to Azure virtual machines and use it as-is.

独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認するDetermine whether you are using your own custom created Shared Java EE Libraries

共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。If you're using the Shared Java EE library feature, you have two options:

  • アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。Refactor your application code to remove all dependencies on your libraries, and instead incorporate the functionality directly into your application.
  • サーバーのクラスパスにそれらのライブラリを追加します。Add the libraries to the server classpath.

OSGi バンドルが使用されているかどうか確認するDetermine whether OSGi bundles are used

WebLogic Server に追加されている OSGi バンドルを使用した場合は、同等の JAR ファイルを Web アプリケーションに直接追加する必要があります。If you used OSGi bundles added to the WebLogic server, you'll need to add the equivalent JAR files directly to your web application.

アプリケーションに OS 固有のコードが含まれているかどうかを判断するDetermine whether your application contains OS-specific code

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。If your application contains any code with dependencies on the host OS, then you'll need to refactor it to remove those dependencies. たとえば、ファイル システムのパスで / または \ を使用している場合、File.Separator または Paths.get に置き換えることが必要になる可能性があります。For example, you may need to replace any use of / or \ in file system paths with File.Separator or Paths.get.

Oracle Service Bus が使用されているかどうか確認するDetermine whether Oracle Service Bus is in use

アプリケーションが Oracle Service Bus (OSB) を使用している場合は、OSB がどのように構成されているかを把握する必要があります。If your application is using Oracle Service Bus (OSB), you'll need to capture how OSB is configured. 詳細については、「Oracle Service Bus のインストールについて」を参照してください。For more information, see About the Oracle Service Bus Installation.

アプリケーションが複数の WAR で構成されているかどうか確認するDetermine whether your application is composed of multiple WARs

アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。If your application is composed of multiple WARs, you should treat each of those WARs as separate applications and go through this guide for each of them.

アプリケーションが EAR としてパッケージ化されているかどうか確認するDetermine whether your application is packaged as an EAR

アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ず application.xml および weblogic-application.xml ファイルを調べて、その構成を把握してください。If your application is packaged as an EAR file, be sure to examine the application.xml and weblogic-application.xml files and capture their configurations.

実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定するIdentify all outside processes and daemons running on the production servers

デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。If you have any processes running outside the application server, such as monitoring daemons, you'll need to eliminate them or migrate them elsewhere.

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

現在、WLST を使用してデプロイを実行している場合は、実行内容を評価する必要があります。If you currently use WLST to perform your deployment, you'll need to assess what it's doing. WLST がデプロイの一部としてアプリケーションの (ランタイム) パラメーターを変更している場合は、移行後にアプリケーションをテストする際、この動作が引き続き機能することを確認する必要があります。If WLST is changing any (runtime) parameters of your application as part of the deployment, you'll need to make sure that this behavior continues to work while testing your application after migration.

ファイル システムが使用されているかどうかとその使用方法を判断するDetermine whether and how the file system is used

VM ファイルシステムは、永続化、スタートアップ、およびシャットダウンに関して、オンプレミスのファイルシステムと同じように動作します。VM filesystems operate the same way as on-premises filesystems with respect to persistence, startup, and shutdown. それでも、ファイルシステムのニーズを認識し、VM のストレージ サイズとパフォーマンスが十分に確保されていることを確認することが重要です。Even so, it's important to be aware of your filesystem needs and ensure the VMs have adequate storage size and performance.

読み取り専用の静的コンテンツRead-only static content

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。If your application currently serves static content, you'll need an alternate location for it. 静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。You may wish to consider moving static content to Azure Blob Storage and adding Azure CDN for lightning-fast downloads globally. 詳細については、「Azure Storage での静的 Web サイト ホスティング」と「クイック スタート:Azure ストレージ アカウントと Azure CDN との統合」を参照してください。For more information, see Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with Azure CDN.

動的に公開される静的コンテンツDynamically published static content

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。If your application allows for static content that is uploaded/produced by your application but is immutable after its creation, you can use Azure Blob Storage and Azure CDN as described above, with an Azure Function to handle uploads and CDN refresh. Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。We've provided a sample implementation for your use at Uploading and CDN-preloading static content with Azure Functions.

ネットワーク トポロジを決定するDetermine the network topology

Marketplace オファーの現在のセットが、移行の出発点となります。The current set of Marketplace offers is a starting point for your migration. 移行する必要があるアーキテクチャの側面がオファーに含まれていない場合は、ソリューション テンプレートの 1 つを使用して基本的なオファーを立ち上げた後でも、既存のデプロイのネットワーク トポロジを把握し、Azure で再現する必要があります。If the offer does not cover aspects of your architecture that you need to migrate, you'll need to capture the network topology of your existing deployment and reproduce that in Azure, even after standing up the basic offer with one of the solution templates.

これは非常に広範なトピックですが、次のリファレンスを使用すると、移行作業に多少の方向性を打ち出すことができます。This is a very broad topic, but the following references can give some direction to your migration efforts:

JCA アダプターとリソース アダプターの使用の考慮Account for the use of JCA Adapters and Resource Adapters

既存のアプリケーションが、JCA アダプターやリソース アダプターを使用して他のエンタープライズ システムに接続している場合は、これらの成果物の構成が Azure Virtual Machines で実行されている WebLogic サーバーに適用されるようにしてください。If your existing application is using JCA Adapters and/or Resource Adapters to connect to other enterprise systems, ensure that the configuration for these artifacts is applied to the WebLogic Server running in Azure Virtual Machines. 詳細については、「リソース・アダプタの作成と構成」を参照してくださいFor more information, see Creating and Configuring Resource Adapters

カスタム セキュリティ プロバイダーと JAAS の使用の考慮Account for the use of custom security providers and JAAS

アプリケーションで JAAS を使用している場合は、セキュリティ プロバイダーの構成が正しく移行されていることを確認する必要があります。If your application is using JAAS, you need to make sure the configuration of security providers is correctly migrated. 詳細については、Oracle のドキュメントの「WebLogic セキュリティ・プロバイダの構成について」を参照してください。For more information, see About Configuring WebLogic Security Providers in the Oracle documentation.

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

多くの場合、高可用性を実現するために、アプリケーションは複数の WebLogic サーバーにデプロイされています。Most likely, you've deployed your application on multiple WebLogic servers to achieve high availability. これらのクラスターをオンプレミスのインストールから Azure Virtual Machines で実行されている WebLogic に直接移行できます。You can migrate these clusters directly from your on-premises installation to WebLogic running in Azure Virtual Machines. 詳細については、Oracle のドキュメントの「ドメイン構成ファイル」を参照してください。For more information, see Domain Configuration Files in the Oracle documentation.

負荷分散の要件の考慮Account for load-balancing requirements

負荷分散は、Oracle WebLogic Server クラスターの Azure への移行において不可欠な部分です。Load balancing is an essential part of migrating your Oracle WebLogic Server cluster to Azure. 最も簡単な解決策は、Oracle WebLogic Server クラスター向けの Azure Marketplace オファーで提供される Azure Application Gateway の組み込みサポートを使用することです。The easiest solution is to use the built-in support for Azure Application Gateway provided in the Azure Marketplace offer for Oracle WebLogic Server cluster. このトピックに関するチュートリアルについては、「チュートリアル: ロード バランサーとして Azure Application Gateway を使用して、Azure に WebLogic Server クラスターを移行する」を参照してください。For a tutorial on this topic, see Tutorial: Migrate a WebLogic Server cluster to Azure with Azure Application Gateway as a load balancer.

その他の Azure 負荷分散ソリューションと比較した Azure Application Gateway の機能の概要については、「Azure の負荷分散オプションの概要」を参照してください。For a summary of the capabilities of Azure Application Gateway compared to other Azure load-balancing solutions, see Overview of load-balancing options in Azure.

Java EE アプリケーション クライアント機能が使用されているかどうか確認するDetermine whether the Java EE Application Client feature is used

アプリケーションで Java EE アプリケーション クライアント機能を使用している場合は、Azure Virtual Machines に移行した後も変更なしで引き続き機能するはずです。If your application uses the Java EE Application Client feature, it should continue to work unchanged after migrating to Azure Virtual Machines. 詳細については、「Java EE クライアント・アプリケーション・モジュールの使用」を参照してください。For more information, see Using Java EE Client Application Modules.

移行Migration

Azure Virtual Machines オファーで WebLogic を選択するSelect a WebLogic on Azure Virtual Machines offer

Azure Virtual Machines 上の WebLogic については、次のオファーを利用できます。The following offers are available for WebLogic on Azure Virtual Machines.

オファーのデプロイ中に、WebLogic Server ノードの仮想マシンのサイズを選択するよう求められます。During the deployment of an offer, you'll be asked to choose the Virtual Machine size for your WebLogic server nodes. VM サイズを選択する際、サイズ設定 (メモリ、プロセッサ、ディスク) のすべての側面を考慮することが重要です。It's important to consider all aspects of sizing (memory, processor, disk) in your choice of VM size. 詳細については、仮想マシンのサイズ設定に関する Azure のドキュメントを参照してくださいFor more information, see the Azure Documentation for virtual machine sizing

管理サーバーのない WebLogic Server 単一ノードWebLogic Server Single Node with no Admin Server

このオファーでは、単一の VM が作成され、それに WebLogic がインストールされますが、ドメインは構成されません。これは、高度にカスタマイズされたドメイン構成を使用する場合に便利です。This offer creates a single VM and installs WebLogic on it, but doesn't configure any domains, which is useful for scenarios where you have a highly customized domain configuration.

管理サーバーがある WebLogic Server 単一ノードWebLogic Server Single Node with Admin Server

このオファーでは、単一の VM がプロビジョニングされ、それに WebLogic Server がインストールされます。This offer provisions a single VM and installs WebLogic Server on it. ドメインが作成され、管理サーバーが起動されます。It creates a domain and starts up the admin server.

WebLogic Server N ノード クラスターWebLogic Server N-Node Cluster

このオファーでは、WebLogic Server VM の高可用性クラスターが作成されます。This offer creates a highly available cluster of WebLogic Server VMs.

WebLogic Server N ノード動的クラスターWebLogic Server N-Node Dynamic Cluster

このオファーでは、可用性が高くてスケーラブルな、WebLogic Server VM の動的クラスターが作成されますThis offer creates a highly available and scalable dynamic cluster of WebLogic Server VMs

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

開始するオファーを選択したら、オファーのドキュメントに記載されている手順に従って、そのオファーをプロビジョニングします。After you've selected which offer to start with, follow the instructions in documentation for the offers to provision that offer. 既存のドメイン名と一致するドメイン名を必ず選択してください。Make sure to choose the domain name that matches your existing domain name. ドメイン パスワードを既存のドメイン パスワードと一致させることもできます。You can even match the domain password with your existing domain password.

ドメインの移行Migrate the domains

オファーをプロビジョニングしたら、ドメインの構成を確認し、ドメインの移行方法の詳細についてこちらのガイダンスに従います。After you've provisioned the offer, you can examine the domain configuration and follow this guidance for details on how to migrate the domains.

データベースへの接続Connect the databases

ドメインを移行したら、オファーのドキュメントの手順に従うことで、データベースに接続できます。After you've migrated the domains, you can connect the databases by following the instructions in the offer documentation. これらの手順は、すべてのデータベース シークレットと、関連するアクセス文字列を考慮するのに役立ちます。These instructions will help you account for any database secrets and access strings involved.

キーストアの考慮Account for KeyStores

アプリケーションで使用されるすべての SSL キーストアの移行を考慮する必要があります。You must account for the migration of any SSL KeyStores used by your application. 詳細については、「キーストアの構成」を参照してください。For more information, see Configuring Keystores.

JMS ソースの接続Connect the JMS sources

データベースに接続した後、WebLogic のドキュメントの「Fusion Middleware Oracle WebLogic Server JMS リソースの管理」の手順に従って JMS を構成できます。After you've connected the databases, you can configure JMS by following the instructions at Fusion Middleware Administering JMS Resources for Oracle WebLogic Server in the WebLogic documentation.

認証と認可の考慮Account for authentication and authorization

ほとんどのアプリケーションには、ある種の認証および認可が備わっています。Most applications have some kind of authentication and authorization. 認証に LDAP を使用する場合、Azure 上の WebLogic Server では自動統合がサポートされます。If you use LDAP for authentication, WebLogic Server on Azure supports automatic integration. Marketplace のオファーでは、セキュリティで保護された LDAP を利用して Azure Active Directory Domain Services (Azure AD DS) が使用されます。The marketplace offer uses Azure Active Directory Domain Services (Azure AD DS) with secure LDAP. このオファーにより、Azure AD DS のデータから WebLogic Server の既定の領域が作成されます。The offer creates the default realm for WebLogic Server from data in the Azure AD DS. 詳細については、「WebLogic Server 上の Java アプリを Azure に移行するためのエンドユーザーの認可と認証」を参照してください。For more information, see End-user authorization and authentication for migrating Java apps on WebLogic Server to Azure.

ログの考慮Account for logging

ドメインを移行するときは、既存のログ構成を引き継ぐ必要があります。The existing logging configuration should be carried over when the domain is migrated. 詳細については、「java.util.logging ロガー・レベルの構成」および「Oracle WebLogic Server ログ・ファイルの構成とログ・メッセージのフィルタリング」を参照してください。For more information, see Configure java.util.logging logger levels and Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server

アプリケーションの移行Migrating your application(s)

開発チームからテスト、ステージング、および実稼働の各サーバーにアプリケーションをデプロイするために使用される手法は、状況に応じて大きく異なります。The techniques used to deploy applications from the development team into test, staging, and production servers vary greatly from case to case. 高度に進化した CI/CD プラットフォームが存在する場合、これにより、アプリケーションを WebLogic Server にデプロイすることになります。In some cases, there's a highly evolved CI/CD platform that results in the application(s) being deployed to the WebLogic Server. また、プロセスがより手動的になる場合もあります。In other cases, the process can be more manual. Azure Virtual Machines を使用してクラウドに WebLogic アプリケーションを移行する利点の 1 つは、既存のプロセスが引き続き機能することです。One benefit of using Azure Virtual Machines to migrate WebLogic applications to the cloud is that your existing processes will continue to work.

CI/CD パイプラインまたは手動デプロイ システムからのアクセスを許可するように、オファーによってプロビジョニングされたネットワーク セキュリティ グループを構成する必要があります。You'll have to configure the Network Security Group that is provisioned by the offer to allow access from your CI/CD pipeline, or manual deployment system. 詳細については、Azure ドキュメントの「セキュリティ グループ」を参照してください。For more information, see Security groups in the Azure documentation for details.

テストTesting

アプリケーションに対するコンテナー内テストは、Azure 内で実行されている新しいサーバーにアクセスするように構成する必要があります。Any in-container tests against applications must be configured to access the new servers running within Azure. CI/CD に関する考慮事項と同様に、ネットワーク セキュリティ規則により、Azure にデプロイされたアプリケーションにテストでアクセスできるようにする必要があります。As with the CI/CD concerns you must ensure the necessary network security rules allow your tests to access the application(s) deployed to Azure. 詳細については、Azure ドキュメントの「セキュリティ グループ」を参照してください。For more information, see Security groups in the Azure documentation for details.

移行後Post-migration

移行前」ステップで定義した移行の目標に到達したら、エンド ツー エンドの受け入れテストを実施して、すべてが予期したとおりに機能することを確認します。After you've reached the migration goals you defined in the pre-migration step, perform some end-to-end acceptance testing to verify that everything works as expected. 移行後の機能強化に関するトピックをいくつか記載していますが、もちろん以下に限定されません。Some topics for post-migration enhancements include, but are certainly not limited to the following: