1. Oracle WebLogic Serverのアップグレード
  2. WebLogicドメインの再構成

3 WebLogicドメインの再構成

再構成ウィザードを使用して、Oracle WebLogic Server 12.2.1.4以降を使用して作成されたWebLogicサーバー・ドメインをアップグレードできます。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

  • WLSコア・インフラストラクチャ

  • ドメイン・バージョン

ノート:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。アプリケーションのアップグレード方法の詳細は、「WebLogic Server 14.1.2.0.0の旧リリースとの互換性」を参照してください。

再構成ウィザードを使用してWebLogic Serverドメインを再構成する方法を学習します。

始める前に

再構成では、CONFIG_JVM_ARGS環境変数の設定、ドメインのバックアップ、アップグレードしたドメインとともに使用するノード・マネージャの構成の選択など、追加のタスクを実行する必要が生じることがあります。

UNIXおよびLinuxシステムでのCONFIG_JVM_ARGSの設定

再構成ウィザードを実行してUNIXまたはLinuxオペレーティング・システムのドメインを再構成する前に、オペレーティング・システムの乱数ジェネレータを使用するためにCONFIG_JVM_ARGS環境変数を次の値に設定します(まだ設定していない場合)。

-Djava.security.egd=file:/dev/./urandom

これにより、再構成ウィザードでドメインを再構成するのにかかる時間が短縮されます。

ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

ノード・マネージャのアップグレード手順の決定

ノード・マネージャのデフォルト構成は、ドメインごとのノード・マネージャ構成になりました。つまり、ノード・マネージャ構成は特定のドメインに固有です。この構成により、指定されたマシン上の複数のドメインが、異なるノード・マネージャ構成を持つことができます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

表3-1に、WebLogicサーバーを12.2.1.4.0以降のバージョンから現行バージョンにアップグレードする場合の、サポートされているノード・マネージャのアップグレード・パスを示します。このコンテキストでホストごととは、ドメインごとのノード・マネージャ構成以外のノード・マネージャ構成を意味します。

表3-1 サポートされているノード・マネージャのアップグレード・パス

ノード・マネージャのアップグレード・パス WebLogic Server 12.2.1.4以降から

ドメインごとからドメインごとへ

サポート対象

ドメインごとからホストごとへ

サポート対象外

ホストごとからドメインごとへ

サポート対象

ホストごとからホストごとへ

手動構成

表3-2に、サポートされている各アップグレード・パスのノード・マネージャのアップグレード詳細を示します。

表3-2 ノード・マネージャのアップグレード詳細

ドメインごとからドメインごとへ ホストごとからドメインごとへ ホストごとからホストごとへ

これは、ドメインごとのノード・マネージャにすでに構成されているWebLogic Server 12.2.1.4.0以降のすべてのリリースでは、自動アップグレードです。環境は標準設定に更新され、後でカスタマイズできます。

ドメインをアップグレードするために再構成ウィザードまたはWLSTを使用しているかどうかに関係なく、アップグレードは自動で行われます。

この場合、再構成ウィザードでは、ドメインの再構成中に「ノード・マネージャ」画面が表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

WLSTを使用して、ドメインおよび必要なノード・マネージャ構成をアップグレードすることもできます。「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください。

複数のドメインごとのノード・マネージャが同じマシン上で実行する場合、「同じマシンでの複数のドメインごとのノード・マネージャの構成」を参照してください。

Fusion Middlewar再構成ウィザード・ウィンドウで画面の「ヘルプ」ボタンをクリックして、再構成ウィザードのコンテキスト依存ヘルプを表示します。

「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャ構成を手動で完了する必要があります

同じマシンでの複数のドメインごとのノード・マネージャの構成

ドメインごとのノード・マネージャ構成を使用して同じマシン上に複数のドメインがある場合、再構成ウィザードを実行する際、次を行います。

  • 「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択して、14cノード・マネージャの既存のマシンを再構成します。

  • 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各ドメインに一意のノード・マネージャ・ポートを使用していることを確認してください。たとえば、マシン上で実行中の3つのドメインごとのノード・マネージャがある場合、ドメイン1にはポート5556、ドメイン2にはポート5557、ドメイン3にはポート5558を使用します。

    Fusion Middlewar再構成ウィザード・ウィンドウの画面の「ヘルプ」ボタンをクリックして、再構成ウィザードのコンテキスト依存ヘルプを表示します。

同じマシンでの2つのホストごとのノード・マネージャの実行

次のすべての項目がアップグレード・シナリオに適用する場合、14cドメインに2つ目のノード・マネージャを作成するには、再構成プロセス中に追加のステップが必要です。

  • 既存のドメインの一部のみを14cにアップグレードします。

  • 14cドメインのホストごとのノード・マネージャの使用を続行します。

  • 既存のホストごとのノード・マネージャと14cのホストごとのノード・マネージャが同じマシンで実行されます。

再構成ウィザードの実行時には、次のようになります。

  • 「ノード・マネージャ」画面で、「手動ノード・マネージャ・セットアップ」を選択します。このオプションにより、14cドメインのホストごとのノード・マネージャとしてのノード・マネージャ構成がアップグレードされている状態が維持されます。

  • 「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択して、14cノード・マネージャの既存のマシンを再構成します。また、「デプロイメントとサービス」を選択して、デプロイメントおよびサービスのマシンの割当てを確認します。

  • 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたら、各マシンの名前を、12cドメインで使用されている名前以外に変更します。また、既存のノード・マネージャで使用されているノード・マネージャのポート番号とは異なるノード・マネージャのポート番号を入力します。このドメインの各14cマシンには同じポート番号を使用します。

  • デプロイメントおよびサービスが新しいマシン名に割り当てられていることを確認します。

WebLogicドメインの再構成

WebLogicドメインの構成には、グラフィカルFusion Middleware再構成ウィザードまたはWebLogic Scripting Tool (WLST)の2つのツールの選択肢があります。

注意:

ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードまたはWLSTを使用してドメインをアップグレードする前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成プロセス中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。この回避策は、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

ドメインを再構成する場合:

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、14.1.2.0)に更新されます。

  • WebLogicサーバー14.1.2.0.0では、本番モードを選択すると、より厳密な設定である保護された本番モードが自動的に有効になります。実際に実装したいのが中程度の設定である本番モードの場合は、アップグレード後に、保護された本番モードを明示的に無効にする必要があります。詳細は、「アップグレード後のドメイン・モードの変更」を参照してください。

  • すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

  • 起動スクリプトが更新されます。

  • 管理サーバーのドメインを再構成した後で、再構成されたドメインをドメイン内のすべてのリモート管理対象サーバーにポートする必要があります。リモート・マシンの管理対象サーバー・ドメインの更新を参照してください。

  • WLSTまたは再構成ウィザードのいずれかを使用してホストごとのノード・マネージャにドメインを再構成した後で、ノード・マネージャ構成を完了するための追加のステップを実行する必要があります。「ノード・マネージャ構成の完了」および「ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)」を参照してください。

グラフィカル・モードでのWebLogicドメインの再構成

再構成ウィザードを使用してドメインを再構成するには、まずDOSコマンド・プロンプトまたはUNIXシェルからこれを起動し、表示される一連の画面に必要なアップグレードの詳細を入力します。

ノート:

GUIモードで再構成ウィザードを実行できない場合、WLSTスクリプトを使用してドメインを再構成することをお薦めします。「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください。

Windowsコマンド・プロンプトまたはUNIXシステムから、再構成ウィザードをグラフィカル・モードで起動するには:

  1. ドメインが存在するシステムにログインします。
  2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。
  3. 次のディレクトリに移動します。ここでORACLE_HOMEは、Oracleホーム・ディレクトリです。

    Windowsの場合: ORACLE_HOME\oracle_common\common\bin

    UNIX:の場合: ORACLE_HOME/oracle_common/common/bin

  4. 次のコマンドを実行します。

    Windowsの場合: reconfig.cmd

    UNIXの場合: sh reconfig.sh

    ノート:

    reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効である場合、次のエラー・メッセージが表示されます。

    *sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

    コマンドに-Dpython.cachedir=valid_directoryオプションを含めることで、キャッシュ・ディレクトリを変更できます。

    再構成ウィザード・セッションのログ・ファイルを作成するには、コマンドに-log=reconfig.log -log_priority=debugパラメータを含めます。ログ・ファイルのファイル名(config_today.logなど)を指定できます。ログ・ファイルは、Oracleホーム・ディレクトリのlogsディレクトリに格納されます。log_priorityに有効な他の値は、OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびALLです。

    「ドメインの選択」画面が表示されます。

再構成ウィザードでは、表3-3にリストされる順序で一連の画面が表示されます。

ノート:

ドメインおよび他の要因により、アプリケーションによって、次の表に表示される画面のほかに、追加の構成画面が表示されます。これらの画面の詳細は、画面で「ヘルプ」ボタンをクリックしてください。

再構成のプロセス中に「拡張構成」画面が表示される場合は、オプションを選択しないで、すべての拡張構成をスキップしてくだい。必要に応じて、後でWLST、構成ウィザードまたはWebLogic Server管理コンソールを使用して、サーバーおよびクラスタの追加やデプロイメント・ターゲット指定の変更などの拡張構成を実行できます。

表3-3 既存のWebLogicドメインの再構成

画面 画面がいつ表示されるか 次のアクションを実行

ドメインの選択

常時

ドメイン・ディレクトリへのフルパスを入力するか、「参照」をクリックして、ドメイン・ディレクトリに移動して選択します。

「次へ」をクリックして、続行します。

再構成セットアップの進行状況

常時

再構成テンプレートのアプリケーションの進行状況を表示します。

処理が終了したら、「次へ」をクリックして、続行します。

再構成のサマリー

常時

すべての再構成済テンプレートの再構成プロセスに関する情報が表示されます。

「次へ」をクリックして、続行します。

ドメイン・モードおよびJDK

常時
ドメイン・モードは、再構成時には変更できません。ドメイン・モードは、アップグレード後に変更できます。

ノート:

WebLogic Server 14.1.1.0.0以前からアップグレードし、ドメインが本番モードであった場合は、本番モードのままではありますが、保護された本番モードはドメイン構成ファイルで明示的に無効になります。ただし、アップグレードしてから本番モードに切り替えると、保護された本番モードが有効になります。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

「次へ」をクリックして、続行します。

この時点で追加のドメイン構成画面が表示される場合があります。

追加の画面はドメイン構成によって異なります。

画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。

拡張構成

常時

詳細構成タスクを実行する各カテゴリ(存在する場合)のチェック・ボックスを選択します。

使用可能なチェック・ボックスは、ドメイン構成によって異なります。

「次へ」をクリックして、続行します。

構成のサマリー

常時

構成を確認します。

構成を変更するには「戻る」ボタンをクリックし、ドメイン再構成プロセスを完了するには「再構成」ボタンをクリックします。

再構成に成功しました

常時

再構成プロセスの最終ステータスを表示します。

構成ウィザードを終了するには、「終了」をクリックします。

WebLogic Scripting Toolを使用したWebLogicドメインの再構成

WLSTを使用してドメインを再構成するには、readDomainForUpgradeコマンドを使用します。このコマンドを使用して、既存のホストごとのノード・マネージャ構成をドメインごとの構成へ移行します。

ノート:

元のドメインがドメインごとのノード・マネージャ構成を使用している場合、ノード・マネージャは自動的にアップグレードされ、追加のステップは必要ありません。

元のドメインがホストごとのノード・マネージャを使用していて、その構成の使用を続行する場合、「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャを手動で再構成する必要があります

例3-1は、オフラインでWLSTを使用してmy_domainというドメインを再構成する方法を示しています。

例3-2は、DOMAIN_HOME/nodemanagerにあるドメインごとの構成に、既存のホストごとのノード・マネージャ構成を移行する方法を示しています。

例3-3は、/Oracle/Middleware/custom/nodemanagerにあるドメインごとの構成に、/Oracle/Middleware/oracle_common/common/nodemanagerにある既存のホストごとの構成を移行する方法を示しています。

setOptionコマンドで使用可能なノード・マネージャ・オプションの詳細は、『Oracle WebLogic Server WLSTコマンド・リファレンス』のsetOptionを参照してください。使用可能なノード・マネージャのWLSTコマンドの詳細は、『Oracle WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。

例3-1 WebLogicドメインの再構成

# Open the domain for upgrade.
wls:/offline> readDomainForUpgrade('c:/domains/my_domain')

# Save the updated domain.
wls:/offline/my_domain> updateDomain()

# Close the domain.
wls:/offline/my_domain> closeDomain()

既存のドメインがホストごとのノード・マネージャを使用していて、ドメインごとのノード・マネージャ構成に移動する場合、いくつかのオプションがあります。

  • 既存のホストごとの構成を移行して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

  • Oracle推奨のデフォルトに基づいた新しい構成を使用して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

  • 既存のホストごとの構成を移行して、カスタムの場所でドメインごとの構成を作成します。

  • Oracle推奨のデフォルトに基づいた新しい構成を使用して、カスタムの場所でドメインごとの構成を作成します。

例3-2 デフォルトの場所での新規ノード・マネージャ構成の作成

#Read domain for reconfiguration
readDomainForUpgrade('domains/mydomain')
 
#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')
 
#Browse Node Manager properties
cd('/')
cd('NMProperties')
 
# Create per domain Node Manager with new default configuration. Existing
# Node Manager properties will not be migrated in this case.
setOption('NodeManagerType','PerDomainNodeManager')
setOption('NodeManagerUpgradeType','New')
 
# Update the domain to commit the changes.
updateDomain()

例3-3 カスタムの場所への既存の構成の移行

#Read domain for reconfiguration
readDomainForUpgrade('/domains/mydomain')
 
#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')
 
#Browse node manager properties
cd('/')
cd('NMProperties')
 
# Create custom location Node Manager, migrating an existing Node Manager
# configuration with default values for Oracle-recommended default properties.
setOption('NodeManagerType','CustomLocationNodeManager')
setOption('NodeManagerHome','/Oracle/Middleware/custom/nodemanager/')
setOption('NodeManagerUpgradeType','Migrate')
setOption('OldNodeManagerHome','/Oracle/Middleware/Oracle_Home/oracle_common/
common/nodemanager')
setOption('NodeManagerUpgradeOverwriteDefault','true')
 
# Update the domain to commit the changes.
updateDomain()

ノード・マネージャ構成の完了

再構成したドメインがホストごとのノード・マネージャ構成を使用していて、そのドメインのホストごとのノード・マネージャの使用を続行する場合、ノード・マネージャの構成タスクのセットを実行する必要があります。

  1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerを作成します。

  2. nodemanager.propertiesおよびnodemanager.domainsファイルを以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、ステップ1で作成したディレクトリにコピーします。

  3. 以前のインストールにnm_data.properties、SerializedSystemIni.dataまたはsecurity/SerializedSystemIni.datファイルが含まれている場合は、それをステップ1で作成したディレクトリにコピーします。SerializedSystemIni.datをコピーする場合は、nodemanagerディレクトリの下にsecurityディレクトリを作成して、そこにファイルを格納します。

  4. nodemanager.propertiesファイルに次の編集を行います。ORACLE_HOMEは、WebLogic ServerインストールのOracleホーム・ディレクトリです:

    • DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsファイルを指すように更新します。

    • JavaHomeをWebLogic Serverに対して使用しているJDKのjreディレクトリを指すように更新します。ファイルにjavaHomeプロパティ設定(小文字のj)も含まれる場合、必要ではないため削除します。

    • NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerを指すように更新します。

    • LogFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logを指すように更新します。

  5. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。

    以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

    1. setWLSEnvを実行します。

      cd WL_HOME/server/bin

      . ./setWLSEnv.sh (UNIX)

      setWLSEnv.cmd (Windows)

      ノート:

      UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

    2. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

    3. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。

      java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

    4. DemoIdentity.jksファイルを生成するには、次のコマンドを実行します。

      java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

  6. ORACLE_HOME/wlserver/server/binディレクトリから、startNodeManager.cmd (Windows)またはstartNodeManager.sh (UNIX)を実行します。

  7. ノード・マネージャを使用してサーバーを起動できることを確認します。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)

再構成したドメインがホストごとのノード・マネージャ構成を使用している場合は、ホストごとのノード・マネージャがすでに存在する既存のドメインのマシンで、14cドメインのホストごとのノード・マネージャを引き続き使用できます。

ドメイン内のマシンごとに次のステップを実行します。

ノート:

この項のステップを実行する前に、ドメイン内の各リモート・マシンにドメインを解凍したことを確認してください。コマンドに-nodemanager_type=ManualNodeManagerSetupパラメータおよび-overwrite_domain=trueパラメータを含めます。たとえば: 

./unpack.sh -domain=domain_home -template=template_jar -nodemanager_type=ManualNodeManagerSetup -overwrite_domain=true

  1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerディレクトリを作成します。

  2. nodemanager.domainsおよびnodemanager.propertiesファイルを、以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、ステップ1で作成したディレクトリにコピーします。12cドメインがnodemanager.domainsファイルにリストされている場合、その行を削除またはコメント・アウトします。

  3. 各マシンでnodemanager.propertiesファイルを適切に編集します。具体的には、次のとおりです。

    • SecureListenerが、SSLノード・マネージャを使用している場合はtrueに設定され、プレーン・ノード・マネージャを使用している場合はfalseに設定されていることを確認してください。

    • DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsを指すように変更します。

    • PropertiesVersionを14.1.2.0.0に変更します。

    • NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerに変更します。

    • JavaHomeを、WebLogic Server 14.1.2.0.0で使用しているJavaインストールのjreディレクトリを指すように変更します。

    • javaHome行は、14cで必要ではないため削除します。

    • ListenPortを、構成ウィザードの「マシン」画面で指定した値に変更します。

    • LogFileを目的の場所およびファイル名に変更します。推奨値はORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logです。

  4. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。

    以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

    1. setWLSEnvを実行します。

      cd WL_HOME/server/bin

      . ./setWLSEnv.sh (UNIX)

      setWLSEnv.cmd (Windows)

      ノート:

      UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

    2. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

    3. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。

      java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

    4. DemoIdentity.jksファイルを生成するには、次のコマンドを実行します。

      java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

  5. ORACLE_HOME/wlserver/server/binディレクトリから、ノード・マネージャを起動します。

  6. 管理サーバーが実行中の場合、管理サーバーを再起動します。

  7. ノード・マネージャを使用してサーバーを起動できることを確認します。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

リモート・マシンの管理対象サーバー・ドメインの更新

WebLogicドメインに複数の管理対象サーバーが含まれ、各管理対象サーバー・ドメイン・ディレクトリが管理サーバーのホスト・マシンのリモート・マシン上にある場合、そのリモート・マシン上のドメインを更新するには2つの方法のいずれかを使用できます。

  • packコマンドを使用して、ドメインのテンプレートJARを生成します。packコマンドでは必ず-managed=true引数を指定してください。JARをリモート・マシンに移動してから、リモート・マシンでunpackコマンドを使用して管理対象サーバー・ドメインを作成します。『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

  • オンライン・モードでWLST writeTemplateコマンドを使用します。リモート・マシンから管理サーバーへの接続時にwriteTemplateコマンドを実行する場合は、管理サーバー上のドメインをテンプレートJARファイルを動的にパックして、そのテンプレートJARを指定されたディレクトリに転送します。

    次のサンプルのWLSTスクリプトは、writeTemplateを使用してリモート・マシン上で管理対象サーバー・ドメインを作成または更新する方法を示しています。ドメインの各リモート・マシン上でスクリプトを実行します。このスクリプト手順では、次のタスクが実行されます。

    • 管理サーバーへのログイン

    • 管理サーバー・ドメインをJARファイルにパックして、それをリモート・マシン上の指定されたテンプレート・ディレクトリに書き込む

    • 管理サーバーからの切断

    • テンプレートJARの読取り

    • リモート・マシン上でのドメインの作成

    import os
 
wlsHome = os.getenv('WL_HOME')
mwHome = os.path.join(wlsHome, '..')
 
#Substitute the administrator user name and password values below as needed
connect('adminuser','adminpassword','admin_server_url')
 
#Create the path on the local machine where the template will be stored, 
#The specified template JAR should not already exist. The timeout value 
#specifies the number of milliseconds to elapse before the connection between
#the Administration Server and remote machine times out (default is 120000).
templatePath = '/user_templates/myTemplate.jar'
timeout = 180000
 
#get the packed template from the Administration Server
writeTemplate(templatePath, timeout)
 
#disconnect from online WLST connection to the Administration Server
disconnect()
 
#read the template that was downloaded from the Administration Server
readTemplate(templatePath)
 
#specify the domain directory where the domain needs to be created
domainPath = 'domains/myDomain'
 
#create the domain
writeDomain(domainPath)

ドメインのアップグレード・プロセスに関する重要なノート

WebLogic Serverアプリケーションのアンデプロイが必要かどうか、ドメイン・ディレクトリに存在しなければならない最小のファイルのセットなど、ドメインのアップグレード・プロセスに関するいくつかの主要な点に留意してください。

  • WebLogic Serverアプリケーションをアンデプロイする必要はありません。通常、WebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 14.1.2.0.0の新たなアプリケーション環境で動作します。アップグレード前にWebLogic移行分析ツールを実行して、新しいバージョンに含まれなくなったクラスとAPIを識別し、アプリケーションを正常にデプロイするために必要な変更をレポートします。詳細は、使用されないAPIの識別を参照してください。

  • 少なくとも、ドメイン・ディレクトリに次のファイルが含まれている必要があります:

    • config.xml

    • セキュリティ関連のファイル(SerializedSystemIni.dat、DefaultAuthenticatorInit.ldift、DefaultAuthorizerInit.ldift、DefaultRoleMapperInit.ldift)

      セキュリティ関連のファイルがないと、サーバーは起動されず、認証エラー・メッセージがログに記録されます。

    • ドメイン内にあるトランザクション・ログ・ファイル(..tlog)。Oracle WebLogic Server JTAアプリケーションの開発のトランザクション・ログ・ファイルを使用したトランザクションのリカバリを参照してください。

  • ターゲットのコンピュータ上のドメイン・ディレクトリに含まれるすべての内容がこのプロセスにおいて更新されます。

  • アプリケーション環境内のすべてのコンピュータのドメインをアップグレードする必要があります。

  • 再構成ウィザードでは、WebLogicドメインのアップグレード時に、ドメインに存在する可能性のある独自のアプリケーションはアップグレードされません。

  • WebLogic Liquid Data、またはAquaLogic Data Services Platformのリソースを含むドメインは、WebLogic Server 14.1.2.0.0にアップグレードできません。

アップグレード後のタスクの実行

アプリケーション環境のアップグレード後、起動スクリプトへのカスタマイズの再適用、ファイル権限の確認、およびリモート・サーバーの起動オプションなどのタスクの実行が必要な場合があります。

この項には次のトピックが含まれます:

必ずしもすべてのステップを実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要なステップを決定してください。

アップグレード後のドメイン・モードの変更

アップグレード後、ドメインのドメイン・セキュリティ・モードは、アップグレード前の元の設定のままです。たとえば、セキュリティ強化のためにドメイン・モードを変更する場合は、WebLogicリモート・コンソールを使用するかDomainMBeanを変更して、設定を明示的に変更する必要があります。

現在ドメインが本番モードに設定されていて、セキュリティを強化する場合は、アップグレード後にWebLogicリモート・コンソールを使用してドメイン・モードを変更し、保護された本番モードを有効にします。Oracle WebLogic Remote Consoleオンライン・ヘルプのドメイン・モードの変更に関する項。

注意:

ドメイン・モードの変更には、ドメイン全体の再起動が必要で、ローリング再起動では不十分です。ドメイン・モードを変更する前に、すべての管理対象サーバーを停止する必要があります。

ドメインを14c (14.1.2.0.0)にアップグレードするときに、明示的なセキュア・モード設定がない場合、再構成ウィザードによって、アップグレード後のドメインではセキュア・モードが明示的に無効に設定されます。これは、元のドメインに存在していた動作を保持するためです。明示的なセキュア・モード設定がある場合、その設定がアップグレード後のドメインに保持されます。詳細は、『Oracle WebLogic Server本番環境の保護』のドメイン・モードがデフォルトのセキュリティ構成に与える影響の理解に関する項を参照してください。

ノート:

保護された本番モードでは、より制限的で厳しいセキュリティ設定が強制され、脅威に対する脆弱性が軽減されます。ドメインがセキュアであることを確認するには、保護された本番モードを有効にした後で、証明書の取得および格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションを選択する必要があります。これらのオプションが適切に構成されていない場合は、WebLogic Serverの使用がブロックされます。

WebLogicドメインの作成後には、適切なセキュリティ構成の選択など、整合性を確保するための主要なステップがいくつか残っています。詳細は、『Oracle WebLogic Serverセキュリティの管理』のドメイン作成後の保護に関する項を参照してください。

使用されないAPIの識別

新しいバージョンに含まれなくなったクラスとAPIを把握して、アプリケーションを正常にデプロイするために必要な変更に対処することが重要です。WebLogic移行分析ツールを使用して、このようなクラスとAPIを識別します。

WebLogic移行分析ツールは、WebLogicサーバー14.1.2.0.0で削除された(つまり使用されなくなった) WebLogicアプリケーション内のAPIを識別してレポートを生成する、コマンドライン・ユーティリティです。このレポートの目的は、実行中のWebLogicサーバーのクラスパスにある削除(weblogic.jarなど)のみを表示することです。このレポートは、クラスに含まれないすべてのjarファイルについてのレポートを目的とはしていません。WebLogicアプリケーションに関連付けられているもののみがレポートされます。

ノート:

このレポートでは、存在しない(つまり非推奨になった) APIとクラスに関連する潜在的なすべての問題を把握することはできません。たとえば、リフレクションを使用している場合、このレポートでは検出されません。同様に、このレポートによって、ライブラリが削除されたために問題を引き起こした可能性があると示されることがありますが、そのライブラリの独自のコピーが別の場所にある場合もあります。

移行分析ツールを実行するには、次を実行します:
java -jar $WL_HOME/server/lib/weblogic.migration-analysis-tool.jar <archive-file-name> <archive-2> <archive-3>
ここで、<archive-file-name>パラメータは分析対象のファイルです。たとえば:
java -jar $WL_HOME/server/lib/weblogic.migration-analysis-tool.jar /tmp/em_example.war

起動スクリプトへのカスタマイズの再適用

アプリケーション環境の14.1.2.0.0へのアップグレードを完了するには、起動スクリプトへのカスタマイズの再適用が必要になる場合があります。次の節では、デフォルト起動スクリプトおよびカスタム起動スクリプトをカスタマイズする方法について説明します。

デフォルト起動スクリプト

再構成ウィザードによるアップグレード・プロセスでは、デフォルト起動スクリプトに対して行われたカスタマイズの内容(JAVA_OPTIONS環境変数の設定など)は保持されません。アップグレード・プロセスが完了した後に、デフォルト起動スクリプトを再びカスタマイズする必要があります。

カスタム起動スクリプト

カスタム起動スクリプトを更新するには:

  • JDKバージョンをWebLogic Serverで使用しているJDKに設定します。

  • 次のようにCLASSPATH変数を更新します。

    • WebLogic Server 14.1.2.0.0のクラスを変数の先頭に追加します。

    • バージョン10.3より前の未使用のすべてのWebLogicクラスを削除します。

ファイル権限の確認

次のようにファイル権限を確認します。

  • アップグレード・プロセスにおいてドメイン・ディレクトリのバックアップを行った場合、バックアップ・ファイルには機密情報が含まれている可能性があるため、バックアップ・ファイルを保護する必要があります。

  • アップグレード・プロセスでは、ファイル権限は保持されません。デフォルト以外のファイル権限がファイルに設定されている場合は、これらを確認し、リセットする必要があります。

  • UNIXシステムでは、アップグレード・プロセス中に作成される新しいファイルの所有権と権限は、アップグレードを実行するユーザーに割り当てられます。たとえば、アップグレードがrootにより実行される場合、新しいファイルの所有権はrootに割り当てられます。このため、後でドメイン内のこれらのファイルを更新するユーザーにはroot権限が必要となります。したがって、アップグレード・プロセス中に作成されたファイルに設定されている権限を確認または修正することをお薦めします。

リモート・サーバー起動オプションの確認

管理サーバーを起動したら、JAVA_HOME、BEA_HOME、CLASSPATHなどのリモート・サーバー起動オプションが、対象の管理対象サーバーにインストールされているWebLogic Server を参照していることを確認します。これはWebLogic Serverリモート・コンソールを使用して行います。詳細は、Oracle WebLogic Serverリモート・コンソール・オンライン・ヘルプの管理対象サーバーの起動引数の構成に関する項を参照してください。

ノート:

リモート・サーバー起動オプションが正しく設定されていないと、ノード・マネージャを使用して管理対象サーバーを起動するときに、次のようなメッセージがログ・ファイルに書き込まれることがあります。このメッセージは再帰的に送信されるため、最終的に使用可能なディスク容量がすべて消費されるおそれがあります。

No config.xml was found.

Would you like the server to create a default configuration and boot? (y/n): 
java.io.IOException: The handle is invalid

Windowsノード・マネージャ・サービスの再作成

Windowsシステムで、ノード・マネージャをドメインのWindowsサービスとして実行していて、引き続きこれを使用する場合、再構成する必要があります。

Windows用のノード・マネージャ・サービスの構成方法の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

オプションで、uninstallNodeMgrSrv.cmdを実行して、インストールからノード・マネージャ・サービスを削除できます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

アプリケーション環境の本番環境へのプロモート

アプリケーション環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行います。テスト・アプリケーション環境でアプリケーション(外部クライアント・アプリケーションを含む)の動作をテストすることをお薦めします。非推奨となったAPIまたは削除されたAPIがアプリケーションで使用されている場合は、実行時に警告または例外が発生するおそれがあります。発生した場合は、アプリケーション環境を本番環境にプロモートする前に、必要な修正を行う必要があります。

すべてのテスト基準をクリアしていれば、「ステップ4: アップグレード計画の作成」で定義したアップグレード計画に従って、アプリケーション環境を本番環境にプロモートできます。

新しい14.1.2.0.0のアプリケーション環境が本番環境にデプロイされたら、既存の環境から新しい環境にリクエストをリダイレクトできるようになります。このようにして、最終的には、既存の環境を安全な停止状態にすることができます。これは、ロード・バランサなどを使用して行います。

FIPS 140-2準拠の維持

WebLogic Server 14.1.2.0.0以降、WebLogic ServerのFIPS 140-2準拠の実装は、Dell JCEおよびDell BSAFE JSSEプロバイダ(旧RSA JCEおよびRSA BSAFE JSSE)ではなく、Jipher JCEおよびSunJSSEプロバイダに依存するように変更されました。

アップグレード後にFIPSモードを引き続き使用する場合は、Jipher JCEおよびSunJSSEプロバイダを使用するように環境を更新する必要があります。『Oracle WebLogic Serverセキュリティの管理』のJipher JCEおよびSun JSSEプロバイダを使用したFIPSモードの有効化に関する項を参照してください。

また、Dell JCEおよびDell BSAFE JSSEプロバイダをWebLogic Server環境から削除する必要があります。『Oracle WebLogic Serverセキュリティの管理』のDell JCEおよびDell BSAFE JSSEプロバイダの削除に関する項を参照してください。