Oracle® Exalogic Elastic Cloud Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51447-02 |
|
![]() 前 |
![]() 次 |
この章では、オラクル社のベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法について説明します。
この章は次の項で構成されています:
ノード・マネージャによって、管理サーバーおよび管理対象サーバーの起動と停止が可能です。
プロセス
この章で説明する手順は、第2.2項「ExalogicにおけるOracle SOAデプロイメント・トポロジの表示」に示すように、Exalogicエンタープライズ・デプロイメント・トポロジの各種コンポーネントに対してSOAHOST1およびSOAHOST2で実行する必要があります。
この章の手順は、コンポーネント固有の章に示す情報を使用して、VIPとIPのペアごとに複数回実行する必要があります。
推奨事項
Exalogicエンタープライズ・デプロイメント・トポロジにおけるノード・マネージャ構成について、次の2つの主要な推奨事項があります。
ノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが常駐するミドルウェア・ホーム内)以外の保存場所に配置することをお薦めします。詳細は、第12.2項「ノード・マネージャの設定」を参照してください。
ドメイン内のノード・マネージャとサーバーの間の通信にホスト名検証を使用することもお薦めします。これには、ドメイン内で使用される様々なアドレスに対する証明書の使用が必要です。この章では、ホスト名検証のためにホスト内で証明書を構成する手順について説明します。詳細は、第12.3項「ノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
注意: このガイドで使用するパスワードは、単なる例として使用しています。本番環境ではセキュアなパスワードを使用してください。たとえば、ランダムな順序の大文字と小文字の両方および数字で構成されるパスワードを使用します。 |
この項では、Exalogicエンタープライズ・デプロイメント用のノード・マネージャの設定方法について説明します。
この項の内容は次のとおりです。
ノード・マネージャの構成ファイルとログ・ファイルの新しいディレクトリをMW_HOMEディレクトリの外部に作成し、ノード・マネージャのすべての構成タスクをこのディレクトリから実行します。
新しいディレクトリを作成する手順は、次のとおりです。
次のコマンドをSOAHOST1およびSOAHOST2で実行します。
mkdir -p /u02/private/oracle/config/nodemanager
次のディレクトリ内のnodemanager.properties
ファイルをコピーします。
/u01/oracle/products/access/wlserver_10.3/common/nodemanager
コピー先は、SOAHOST1およびSOAHOST2上に作成した新しいnodemanagerフォルダです。
次のディレクトリ内のstartNodeManager.sh
ファイルをコピーします。
/u01/oracle/products access/wlserver_10.3/server/bin
および次のフォルダ内にあるnodemanager.domains
ファイル。
/u01/oracle/products/access/wlserver_10.3/common/nodemanager
コピー先は、SOAHOST1およびSOAHOST2上に作成した新しいnodemanagerフォルダです。
SOAHOST1およびSOAHOST2のstartNodeManager.sh
(SOAHOST1およびSOAHOST2内の新しいnodemanager
フォルダ内にある)を、テキスト・エディタを使用して開き、次の変更を行います。
SOAHOST1およびSOAHOST2上で次のように実行します。
NODEMGR_HOME="/u02/private/oracle/config/nodemanager
SOAHOST1およびSOAHOST2上の次のディレクトリにあるnodemanager.properties
ファイルを更新します。
/u02/private/oracle/config/nodemanager
SOAHOST1上で、ファイルを次のように編集します。
NodeManagerHome: /u02/private/oracle/config/nodemanager ListenAddress= 192.168.10.1 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log Properties Value SecureListener Set the value to "false". StartScriptEnabled Set the value to "true", StopScriptEnabled Set the value to "true", StopScriptName Specify a name for the stop script, for example stopWebLogic.sh. DomainsFile /u02/private/oracle/config/nodemanager/nodemanager.domains
SOAHOST2上:
NodeManagerHome: /u02/private/oracle/config/nodemanager ListenAddress= 192.168.10.2 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log Properties Value SecureListener Set the value to "false". StartScriptEnabled Set the value to "true", StopScriptEnabled Set the value to "true", StopScriptName Specify a name for the stop script, for example stopWebLogic.sh. DomainsFile /u02/private/oracle/config/nodemanager/nodemanager.domains
次のディレクトリにあるstartNodeManager.sh
を使用することで、SOAHOST1およびSOAHOST2でノード・マネージャを起動します。
/u02/private/oracle/config/nodemanager
たとえば、次のコマンドをSOAHOST1およびSOAHOST2で実行します。
./startNodeManager.sh
この項では、ノード・マネージャと管理サーバーとの間の通信用のホスト名検証証明書を設定する方法を説明します。これは、次の手順で構成されています。
この章で(例として)追加される証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応しています。サーバーが仮想ホスト名を使用している場合は、常に、そのサーバーを1つのノードから別のものに移行できることを意味します。結果として、キーストアおよび信頼キーストアが保持されているディレクトリは、理想的にはフェイルオーバーからアクセス可能な共有記憶域に配置する必要があります。同じノードまたは異なるノードで追加のホスト名が使用されている場合、この例の手順を拡張して、次のようにする必要があります。
必要なホスト名を証明書ストアに追加します(それらがHOST.mycompany.comおよびVIP.mycompany.comとは異なる場合)。
ノード・マネージャ(ノード・マネージャによって追加のホスト名が使用される場合)またはサーバー(管理対象サーバーによって追加のホスト名が使用される場合)のアイデンティティおよび信頼ストアの場所情報を変更します。
次の手順に従って、HOST上に自己署名証明書を作成します。これらの証明書は、ネットワーク名または別名を使用して作成する必要があります。信頼できるCA証明書を使用する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverの保護のアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comおよびVIP.mycompany.com用の証明書を構成します。つまり、物理ホスト名(HOST)と仮想ホスト名(VIP)の両方がHOSTで使用されていると想定しています。また、HOST.mycompany.comがノード・マネージャによって使用されるアドレスであり、VIP.mycompany.comが管理対象サーバーまたは管理サーバーによって使用されるアドレスであると想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノード、または2つの管理対象サーバーが共存してそのうちの1つのサーバーが物理ホスト名でリスニングして1つのサーバーが仮想ホスト名を使用する(これは移行サーバーを使用するサーバーの場合)ノードによくある状況です。
WL_HOME
/server/bin/setWLSEnv.shスクリプトを実行することで環境を設定します。Bourneシェルで、次のコマンドを実行します。
cd WL_HOME/server/bin
. ./setWLSEnv.sh
CLASSPATH
環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリの下のcertsという名前のディレクトリを作成します。証明書は、複数のWebLogicドメインで共有できることに注意してください。
cd ASERVER_HOME
mkdir certs
注意: サーバーが(手動またはサーバー移行によって)フェイルオーバーしたときに、フェイルオーバー・ノードから適切な証明書にアクセスできるように、キーストアおよび信頼キーストアが保持されているディレクトリは、すべてのノードからアクセスできる共有記憶域上にあることが必要です。様々な目的(たとえば、HTTP呼出しのために設定されたSSLなど)に使用する証明書には、一元管理されたストアまたは共有ストアを使用することをお薦めします。 |
ディレクトリを、先ほど作成したディレクトリに変更します。
cd certs
ユーザー定義ディレクトリからutils.CertGen
ツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。
構文(すべてを1行で指定します):
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]
例:
java utils.CertGen Key_Passphrase SOAHOST1.mycompany.com_cert SOAHOST1.mycompany.com_key domestic SOAHOST1.mycompany.com java utils.CertGen Key_Passphrase SOAHOST2.mycompany.com_cert SOAHOST2.mycompany.com_key domestic SOAHOST2.mycompany.com java utils.CertGen Key_Passphrase ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com java utils.CertGen Key_Passphrase OUDADMINVHN.mycompany.com_cert OUDADMINVHN.mycompany.com_key domestic OUDADMINVHN.mycompany.com
次の手順に従って、SOAHOST1上にアイデンティティ・キーストアを作成します。
utils.ImportPrivateKey
ユーティリティを使用してappIdentityKeyStore
という新しいアイデンティティ・キーストアを作成します。証明書と同じディレクトリ(つまり、ASERVER_HOME
/certs
)の下にこのキーストアを作成します。
注意: アイデンティティ・ストアは、 |
SOAHOST1.mycompany.com
、SOAHOST2.mycompany.com
およびADMINVNH.mycompany.com
の証明書および秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートされた証明書と鍵のペアごとに異なる別名を使用するようにしてください。
構文(すべてを1行で指定します):
java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentitySOAHOST1 Key_Passphrase ASERVER_HOME/certs/SOAHOST1.mycompany.com_cert.pem ASERVER_HOME/certs/SOAHOST1.mycompany.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentitySOAHOST2 Key_Passphrase ASERVER_HOME/certs/SOAHOST2.mycompany.com_cert.pem ASERVER_HOME/certs/SOAHOST2.mycompany.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityADMVHN Key_Passphrase ASERVER_HOME/certs/ADMINVNH.mycompany.com_cert.pem ASERVER_HOME/certs/ADMINVNH.mycompany.com_key.pem
次の手順に従って、各ホスト、SOAHOST1およびSOAHOST2に信頼キーストアを作成します。
標準Javaキーストアには、必要なルートCA証明書の大部分がすでに含まれているため、それをコピーして新しい信頼キーストアを作成します。標準Java信頼キーストアを直接変更することはお薦めしません。WL_HOME
/server/libディレクトリの下に配置されている標準JavaキーストアCA証明書を、その証明書と同じディレクトリにコピーします。次に例を示します。
cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStoreSOAHOST1.jks
標準Javaキーストアのデフォルト・パスワードはchangeit
です。デフォルト・パスワードは常に変更することをお薦めします。これを行うには、keytool
ユーティリティを使用します。構文は次のとおりです。
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
次に例を示します。
keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreSOAHOST1.jks -storepass changeit
CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書に署名するために使用します。これは、WL_HOME
/server/lib
ディレクトリに配置されています。このCA証明書は、keytool
ユーティリティを使用してappTrustKeyStore
にインポートする必要があります。構文は次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias Alias_Name
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
次に例を示します。
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreSOAHOST1.jks -storepass Key_Passphrase
SOAHOST1およびSOAHOST2上の次のディレクトリに配置されているnodemanager.properties
ファイルを編集することで、カスタム・キーストアを使用するようにノード・マネージャを構成します。
/u02/private/oracle/config/nodemanager_directory
次の行をnodemanager.properties
ファイルに追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity_Keystore CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password CustomIdentityAlias=Identity_Keystore_Alias CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate
次に例を示します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ASERVER_HOME/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=Key_Passphrase CustomIdentityAlias=appIdentitySOAHOST1 CustomIdentityPrivateKeyPassPhrase=Key_Passphrase
第12.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.properties
ファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.properties
ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。
MW_HOMEに共通記憶域または共有記憶域のインストールを使用している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第12.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートすることで、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになったら、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。
各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。
cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1 cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2
注意: 必ず、たとえば、...HOST1に |
次の手順に従って、WLS_SERVERのアイデンティティおよび信頼キーストアを構成します。
第8.18.2項「Oracle Traffic Directorを介したアクセスの検証」に示すURLにあるOracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
アイデンティティおよび信頼キーストアを構成するサーバーの名前(WLS_SERVER)をクリックします。選択したサーバーの「設定」ページが表示されます。
「構成」→「キーストア」を選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理のための「カスタムIDとカスタム信頼」方法を選択します。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: 次のようなアイデンティティ・キーストアの完全修飾パス。
ASERVER_HOME/certs/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: 空白のままにします。デフォルトのJKSになります。
カスタムIDキーストアのパスフレーズ: 第12.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password
)。この属性は、キーストアのタイプに応じてオプションの場合も必須の場合もあります。すべてのキーストアで、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「信頼」セクションで、信頼キーストアのプロパティを定義します。
カスタム信頼キーストア: 次のような信頼キーストアの完全修飾パス。
ASERVER_HOME/certs/appTrustKeyStoreSOAHOST1.jks
カスタム信頼キーストアのタイプ: 空白のままにします。デフォルトのJKSになります。
カスタム信頼キーストアのパスフレーズ: 第12.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」でNew_Passwordとして指定したパスワード。この属性は、キーストアのタイプに応じてオプションの場合も必須の場合もあります。すべてのキーストアで、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。
「保存」をクリックします。
管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックし、変更を有効化します。
「構成」→「SSL」を選択します。
「ロックして編集」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングするホスト名に使用する別名を入力します。次に例を示します。
wls_oam1
の場合、appIdentitySOAHOST1
を使用します。
wls_oam2
の場合、appIdentitySOAHOST2
を使用します。
ADMINSERVER
の場合、ユーザーappIdentityADMVHN
。
「秘密鍵のパスフレーズ」および「秘密鍵のパスフレーズを確認」フィールドで、第12.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックし、変更を有効化します。
第8.5.3項「SOAHOST1での管理サーバーの起動」の説明に従って、変更を適用したサーバーを再起動します。
前述の手順を実行したら、影響を受ける管理対象サーバーのホスト名検証をBea Hostname Verifier
に設定します。これを行うには、次の手順を実行します。
Oracle WebLogic Server管理コンソールにログインします。
チェンジ・センターから「ロックして編集」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「管理対象サーバー」を選択します。サーバーの設定ページが表示されます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
ホスト名検証をBea Hostname Verifier
に設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
次のディレクトリにあるstartNodeManager.sh
を実行することで、SOAHOST1およびSOAHOST2でノード・マネージャを起動します。
/u02/private/oracle/config/nodemanager
ノード・マネージャを起動するには、次のコマンドをSOAHOST1およびSOAHOST2で実行します。
./startNodeManager.sh
注意: まだ、ノード・マネージャの構成も起動もしていない場合は、 |
注意: ノード・マネージャの出力から、ノード・マネージャが適切なストアおよび別名を使用していることを確認します。ノード・マネージャの起動時に次のように表示されます。 <Loading identity key store: FileName=ASERVER_HOME/certs/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true> サーバーにテスト構成変更を適用し、ノード・マネージャによってSSLエラーが報告されることなくそれが続行される場合、ホスト名検証は機能しています。 |