wsadmin ツールを使用して、あるセルからプロパティー・ファイルを抽出し、
抽出したプロパティー・ファイルにある環境固有の変数を変更し、
変更したプロパティー・ファイルを別のセルに適用します。
環境固有の変数を変更することで、プロパティー・ファイルが移植可能になります。
始める前に
編集するプロパティー・ファイルが製品のバージョン 7.0.0.7 より前に作成されたものである場合には、
プロパティー・ファイルを調べて、以下のような XMI ID が含まれているかどうかを確認してください。
#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=ID#VirtualHost_1
#
#Properties
#
name=default_host
EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell
XMI ID とは、バージョン 7.0.0.7 より前の製品が構成オブジェクトの作成時に生成する固有 ID です。
XMI ID は、同一オブジェクトについて、別の環境では異なる可能性があります。
この例では、環境のデフォルト・ホストの VirtualHost リソースで、
XMI ID が VirtualHost_1 となっています。
この XMI ID が、別の環境では VirtualHost_2 といった別の値であることがあります。
XMI ID を含むプロパティー・ファイルは移植することができません。
抽出したプロパティーに XMI ID が含まれる場合、それを別の環境に適用するには、まず、リソース ID の変更が必要です。
プロパティー・ファイルの同じ仮想ホスト・セクションで、移植可能なリソース ID を含むものは、以下のようになります。
#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=default_host
#
#Properties
#
name=default_host
EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell
この例では、環境内で VirtualHost オブジェクトを一意的に識別するキー属性として、name が使用されます。
オブジェクトは、同じタイプの異なるインスタンスの中で一意的に識別する、複数のキー属性を持つことができます。
このタスクについて
移植可能なリソース ID を含むプロパティー・ファイルは、別の環境に適用できます。
移植可能なリソース ID が設定されるようにプロパティー・ファイルを抽出するには、PortablePropertiesFile オプションを true に設定した extractConfigProperties コマンドを使用します。
このオプションを指定して抽出したプロパティー・ファイルは、移植可能です。
抽出したプロパティー・ファイルは、各リソースを一意的に識別しません。
リソース ID には、属性名と値の対が 1 つ以上ある場合があります。
例えば、nodeName 属性でノードを識別し、
serverName 属性でサーバーを識別します。
デフォルトでは、抽出したプロパティー・ファイルは移植可能でありません。
ただし、PortablePropertiesFile オプションに true を設定して抽出したプロパティー・ファイルは移植可能です。
PortablePropertiesFile オプションを true に設定してプロパティー・ファイルを抽出したら、プロパティー・ファイルにある EnvironmentVariablesSection を変更し、プロパティー・ファイルをターゲット環境にコピーし、applyConfigProperties コマンドを実行してプロパティー・ファイルを別のセルに適用します。
以下の構文に示すように、これらのコマンドで対話モードを使用することもできます。
AdminTask.command_name('-interactive')
手順
- wsadmin スクリプト・ツールを開始します。
Jython 言語を使用して wsadmin を開始する場合は、サーバー・プロファイルの
bin ディレクトリーから以下のコマンドを実行します。
wsadmin -lang jython
- PortablePropertiesFile オプションに true を設定して extractConfigProperties コマンドを使用し、プロパティー・ファイルを抽出します。
例えば、サーバー server1 のプロパティーを移植可能なフォーマットで
server.props ファイルに抽出するには、以下の wsadmin コマンドを実行します。
AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=server1
-options [[PortablePropertiesFile true]] ]')
プロパティー・ファイルが Server、
Node、Application、Cluster、または AuthorizationGroup のタイプのリソースを参照し、それがターゲット環境に存在しない場合には、
GenerateTemplates オプションに true を設定することを検討してください。
AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=
-options [[GenerateTemplates true][PortablePropertiesFile true]] ]')
GenerateTemplates オプションを使用すると、抽出したプロパティー・ファイルに、
同じタイプの別のオブジェクトの作成をサポートするプロパティー・セクションが含まれます。
デフォルトでは、このオプションは使用不可になっています。
- オプション: 抽出したプロパティー・ファイルをエディターで開き、
リソース ID を調べ、それらが移植可能であることを確認します。
移植可能な ID は、各リソースを一意的に識別しません。
以下の例では、プロパティー・ファイルのさまざまなサブセクションの移植可能な ID を示しています。
- 例 1: リソース ID に対して 1 つの属性名と値を使用
この例では、jndiName が、DataSource を識別する移植可能なリソース ID です。
#
# SubSection 1.0.1.0 # DataSource attributes
#
Resou:rceType=DataSource
ImplementingResourceType=JDBCProvider
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=Derby JDBC
Provider(XA):DataSource=jndiName#jdbc/DefaultEJBTimerDataSource
- 例 2: リソース ID に対して複数の属性名と値の対を使用
この例では、nodeName 属性と serverName 属性で合わせて coreGroupServer リソースを識別します。
#
# SubSection 1.0.8.0 # CoreGroupServer Section
#
ResourceType=CoreGroupServer
ImplementingResourceType=CoreGroup
ResourceId=Cell=!{cellName}:CoreGroup=!{coreGroup}:CoreGroupServer=nodeName#myNode04,serverName#server1
AttributeInfo=coreGroupServers
- 例 3: singleton のリソース ID
この例では、セルに Security オブジェクトが 1 つしかありません。
Security オブジェクトは singleton オブジェクトと見なされるため、
このリソースを一意的に識別するのに属性は不要です。
#
# SubSection 1.0 # Security Section
#
ResourceType=Security
ImplementingResourceType=Security
ResourceId=Cell=!{cellName}:Security=
トラブルの回避 (Avoid trouble): JDBCProvider や ThreadPool といった一部のリソースでは、同じ名前で複数回作成することが可能です。
こうしたオブジェクトでは、名前の値がキー属性となります。
特定の有効範囲の下で、こうしたオブジェクトのインスタンスを同じ名前で複数作成しないでください。
gotcha
- 必要に応じて、抽出したプロパティー・ファイルを変更します。
- 抽出した移植可能プロパティー・ファイルが Server、
Node、Application、Cluster、または AuthorizationGroup のタイプのリソースを参照し、それがもう一方の環境に存在せず、
かつ、GenerateTemplates オプションに true を指定して extractConfigProperties コマンドが実行された場合には、
プロパティー・ファイルを編集して、リソースの作成を有効にします。
GenerateTemplates オプションを使用すると、既存のサーバーに類似した別のサーバーを作成することができます。
例えば、このオプションを使用してサーバー・プロパティーを抽出すると、
抽出したプロパティー・ファイルに、別のサーバーを作成するためのテンプレートが含まれます。
デフォルトでは、このテンプレート・セクションをスキップします。
SKIP=false を設定し、新しいオブジェクトの作成に必要なプロパティーを設定すると、applyConfigProperties コマンドが実行されたときに、製品によって、新しいオブジェクトが作成され、編集済みのプロパティー・ファイルが提供されます。後続のセクションに既存サーバーの構成プロパティーが含まれていて、applyConfigProperties コマンドの実行時にそれらのセクションが処理されるため、新しく作成されたサーバーの構成は、プロパティー・ファイル抽出元の古いサーバーと同じになります。
nodeName、cellName、および serverName の変数を変更することによって、
作成された新しいサーバーを反映するように環境セクションを変更する必要があります。
このオプションは、サーバー、クラスター、アプリケーション、および許可グループの各セクションの前に、
テンプレート・プロパティー・セクションを生成します。
デフォルトでは、セクションは使用不可になっています。
ターゲット環境に存在しない各オブジェクトについて、それに対応するセクションを編集します。
適切なプロパティー値を挿入し、SKIP=true を削除します。
プロパティー・ファイルの最後に、新しいターゲット環境を反映する環境固有の変数を設定します。
- オブジェクトを識別するキーとして使用されているプロパティーは、変更または削除しないでください。
オブジェクト内のキー属性を変更または削除した場合には、
プロパティー・ファイル中の後続のセクションで、そのオブジェクトを再び参照してはなりません。
後続のセクションで指定されたリソースは、検出されません。
例えば、以下のセクション内の仮想ホスト・プロパティーについて検討します。
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=admin_host
#
#Properties
#
name=admin_host #required
#
# SubSection 1.0.1 # MimeTypes section
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=admin_host
AttributeInfo=mimeTypes(type,extensions)
name=admin_host が
name=my_host に変更された場合、
ResourceId==!{cellName}:VirtualHost=admin_host を含む MIME タイプ・セクションは、前のセクションで名前が変更されているため、
ResourceId で指定されたリソースを検出できなくなります。
同様に、name=admin_host が削除された場合、
MIME タイプ・セクションは、ResourceId で指定されたリソースを検出できなくなります。
- プロパティー・ファイルを検証します。
validateConfigProperties コマンドを実行します。
プロパティー・ファイルの検証に関するトピックを参照してください。
- 抽出した移植可能プロパティー・ファイルを別の環境にコピーします。
- 抽出した移植可能プロパティー・ファイルが Server、
Node、Application、Cluster、または AuthorizationGroup のタイプのリソースを参照し、それがもう一方の環境に存在せず、
かつ、GenerateTemplates オプションに true を指定して extractConfigProperties コマンドが実行されなかった場合には、
もう一方の環境にリソースを作成します。
プロパティー・ファイルが最初に別の環境に適用されたために、
プロパティー・ファイル内のリソース ID が、ターゲット環境に存在しないリソースを参照することがあります。
Server、Node、Application、Cluster、または AuthorizationGroup のタイプのリソースがターゲット環境に存在せず、
プロパティー・ファイルでリソースの作成を有効にしていない場合には、リソースのプロパティーを適用する前に、ターゲット環境にそのリソースを作成します。
また、属性が別のリソースを参照することもあります。
参照されたすべてのリソースが存在することを確認し、
必要であれば、Server、Node、Application、Cluster、または AuthorizationGroup のタイプの欠落しているリソースを作成します。
- applyConfigProperties コマンドを使用し、抽出した移植可能プロパティー・ファイルをもう一方の環境で適用します。
例えば、プロパティー・ファイル server.props を適用し、レポート
rep.txt を生成するには、次の wsadmin コマンドを実行します。
AdminTask.applyConfigProperties('[-propertiesFileName server.props -reportFileName rep.txt]')
プロパティー・ファイルに指定されているリソースがターゲット環境に存在し、プロパティー・ファイルに指定されているプロパティー値がターゲット環境に既に設定されている値と同じである場合は、そのプロパティーがスキップされるか、またはターゲット環境で設定されません。この製品では、プロパティー・ファイルに指定されているものと異なるプロパティーのみが適用されます。
プロパティー・ファイルに指定されているリソースがターゲット環境に存在しない場合は、新しいリソースが作成され、そのリソースの全プロパティーがプロパティー・ファイルのリソースの値から設定されます。Server、Node、Application、Cluster、または AuthorizationGroup タイプのリソースは、extractConfigProperties コマンドが GenerateTemplates オプションを true に設定して実行され、かつプロパティー・ファイルにこれらのタイプの新規リソースが 1 つ以上指定されている場合を除いて作成されません。
トラブルの回避 (Avoid trouble): プロパティー・ファイル内のリソースの属性が、ターゲット環境に存在しない別のリソースを参照している場合、参照されているこのリソースは
applyConfigProperties コマンドでは作成されません。
例えば以下のプロパティー・ファイルでは、
coreGroupName
は
HAManagerService リソースの属性で、
コア・グループ・リソースを名前で参照しています。
myCoreGroup という名前のコア・グループがターゲット環境に存在しない場合、
applyConfigProperties コマンドを使用してこのプロパティー・ファイルを適用しても、
コア・グループのリソースは作成されません。
#
# SubSection 1.0 # HAManagerService Section
#
ResourceType=HAManagerService
ImplementingResourceType=HAManagerService
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:HAMana
gerService=
AttributeInfo=hamanagerservice
#
#
#Properties
#
isAlivePeriodSec=120 #integer,required,default(120)
transportBufferSize=10 #integer,required,default(1)
enable=true #boolean,default(false)
context=null
activateEnabled=true #boolean,default(false)
description=Template version of HAManager service.
coreGroupName=myCoreGroup
gotcha
タスクの結果
適用されたプロパティー・ファイルでターゲット環境が更新されます。