
![[16.0.0.3 and later]](../ng_v16003plus.gif)
Docker コンテナーまたは Node.js サーバー内の Liberty のプロビジョン可能なクラスターの構成
Docker コンテナーまたは Node.js サーバーにおける Liberty サーバーの自律型デプロイメントをサポートするように集合を構成できます。スケーリング・コントローラーは Liberty ソフトウェアを登録ホストにインストールし、新しいサーバーを作成することができます。また、 スケーリング・コントローラーは、リソース使用量およびオプションのスケーリング・ポリシーに基づいて、デプロイされたサーバーの開始または停止を行うことができます。使用可能なサーバーの数が、アプリケーションの需要が高いと増大し、低いと減少します。
手順
- JVM 弾力性のための自動スケーリング可能クラスターの構成のステップに従います。
ご覧ください: 「Configuring a Liberty auto-scalable cluster for JVM elasticity」のビデオには、この手順が示されています。[トランスクリプト]
- stackGroups ディレクトリー構造に入れられる package_name.deploy.xml ファイル内で使用されるクラスター名に既存の動的クラスター・メンバーが属していることを確認します。
このクラスター・メンバーは、package_name.deploy.xml ファイル内に定義された、デプロイされるメンバーと同じタイプでなければなりません。例えば、スタックが Docker の場合、Liberty Docker メンバーが存在している必要があります。
package_name は、スケーリング・コントローラーがターゲット・ホストにプロビジョンするサーバー・パッケージの名前です。パッケージについて詳しくは、ステップ 5 を参照してください。
- オプション: スケーリング・コントローラーにスケーリング・ポリシーを追加します。 スケーリング・ポリシーの定義を参照してください。
- 各ターゲット・ホストをスケーリング・コントローラーに登録します。
ホストを登録すると、スケーリング・コントローラーはファイルをそのホストに転送できるほか、 そのホスト上のファイル、コマンド、その他のリソースにアクセスできるようになります。 registerHost コマンドを使用して、ターゲット・ホストを登録します。 スケーリング・コントローラーの server.xml ファイルで、 --host、--port、--user、--password の各パラメーターの値を見つけます。 Linux または Windows オペレーティング・システム上のターゲット・ホストの場合などに、SSH 秘密鍵ファイルを使用しない場合は、 --rpcUser と --rpcUserPassword のパラメーターを設定して、オペレーティング・システム・ログイン・ユーザーとパスワードを含めます。 --rpcUser で指定するユーザーには、ターゲット・デプロイメント・ロケーションへのオペレーティング・システムの権限が必要です。
wlp/bin/collective registerHost targetHost --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword --rpcUser=osUser --rpcUserPassword=osUserPassword
ホストが既に登録されている場合は、updateHost コマンドを使用して登録情報をリセットすることができます。 ターゲット・ホストがコントローラー・ホストと同じコンピューターにある場合、コントローラー・ホストに対しても updateHost コマンドを実行する必要があります。詳しくは、ホスト・コンピューターの Liberty 集合への登録を参照してください。
- DeployService デプロイ操作のデプロイメント・ルールを構成する、package_name.deploy.xml という名前のファイルを作成します。
デプロイ・ルール入力変数に値を設定する、名前と値のペアを追加できます。
<deploy> <useRule id="rule_ID" /> <variable name="aName" value="aValue" /> ... </deploy>
rule_ID には、Liberty によって提供されるデプロイ・ルールの id 値を指定するか、 ユーザー独自のデプロイ・ルールの id 値を指定します。この package_name.deploy.xml ファイルは、スタック・グループ packages ディレクトリーに入ります (ステップ 7)。
variable の名前と値には、デプロイ・ルールに定義された inputVariable を使用します。
Node.js サーバーについては、『デプロイメント REST API を使用した Node.js サーバーのデプロイ』のステップ 2 のアプリケーション .tgz コンテンツおよびロケーションについての情報を参照してください。
- スケーリング・コントローラーの server.xml ファイル内に、集合コントローラー用のユーザー名とパスワードを設定します。
<collectiveController user="adminUser" password="adminPassword" />
- WLP_STACK_GROUPS_DIR のロケーション (デフォルトでは $WLP_USER_DIR/shared/stackGroups) に package_name.deploy.xml ファイルを置きます。
スケーリング・コントローラーは、ファイル・システム内のデフォルト・パッケージ・ロケーションをモニターし、更新に動的に対応します。このファイルをデフォルト・ロケーションに置く場合は、デフォルト属性をどれも変更する必要はありません。
デフォルトのスタック・グループ defaultStackGroup を使用できます。 あるいは、stackGroups の独自のサブディレクトリー (myStackGroup など) を作成して、それに packages のサブディレクトリーを追加します。
wlp/usr /servers /shared ... /stackGroups /defaultStackGroup /installables /packages /myStackGroup /packages
スケーリング・コントローラーは、このファイルを使用して、登録ホストに新規サーバーを作成します。
ヒント: 新しいサーバーが作成されるのは、スケーリング・ポリシーが使用可能になっていて、新規サーバーを必要とする場合のみです。新規サーバーを作成するようスケーリング・コントローラーを強制するには、 スケーリング・コントローラーのスケーリング・ポリシーの min 値を調整し、場合によっては max 値も調整します。例えば、 スケーリング・コントローラーにスケーリング・ポリシーがなく、3 つのスケーリング・メンバーからなる集合がある場合、スケーリング・コントローラーの server.xml ファイルに、少なくとも 4 つの実行中メンバーが存在するようにスケーリング・コントローラーを強制するポリシーを追加します。<scalingDefinitions> <defaultScalingPolicy enabled="true" min="4" max="6"/> </scalingDefinitions>
Liberty Elasticity のクラスター命名規則は、StackGroupName.PackageName です。 スタックのデプロイ時に、デプロイされたサーバーの server.xml ファイルに <clusterMember name="StackGroupname.PackageName" が自動的に設定されます。 対応する <scalingPolicy> エレメントには、<bind clusters="StackGroupName.Packagename"/> ステートメントが含まれます。ただし、Docker および Node.js 用に Liberty によって提供されるデプロイ・ルールでは、clusterName を任意の値に設定できます。
- デプロイ変数を調べて、必要であれば環境に合わせて変更します。
子エレメント deployVariable は、デプロイされたスタックに注入される置換変数を指定します。スタックがデプロイされるたびに置換変数が自動的にインクリメントするように指定できます。 例えば、deployVariable 属性を使用して、初期ポート番号値を指定し、デプロイメントのたびに値をインクリメントします。 この状況における deployVariable の目的は、ターゲット・ホストでのポート競合の回避です。
『デプロイメント REST API を使用した Docker コンテナーのデプロイ』のステップ 1c で説明されているように、Docker イメージ用のデプロイ変数を設定します。
『デプロイメント REST API を使用した Node.js サーバーのデプロイ』のステップ 3 で説明されているように、Node.js サーバー・デプロイメント用のデプロイ変数を設定します。
- オプション: スケーリング・コントローラーがファイル・システムでスタック・グループの追加、更新、削除をチェックする間隔を変更します。
スケーリング・コントローラーは stackGroups ディレクトリーおよびそのサブディレクトリーの内容をスキャンして変更がないか確認します。内容に変更があると、前に使用可能なパッケージを保有していなかったクラスターをコントローラーがプロビジョンすることになる場合があります。パッケージの更新は、コントローラーが既存のクラスターを再度プロビジョンする原因にはなりません。
デフォルトでは、コントローラーは、5000 ミリ秒ごと (5 秒ごと) に WLP_STACK_GROUPS_DIR のロケーションをスキャンします。 スキャン間隔を変更する場合、またはスキャンを無効にする場合は、 スケーリング・コントローラーの server.xml ファイルでスタック・マネージャーの scanningInterval 属性と scanningEnable 属性に新しい値を設定します。 例えば、スキャン間隔を 6 秒に設定し、スキャンを有効にする場合は、 以下のようなステートメントをスケーリング・コントローラーの server.xml ファイルに追加します。
<stackManager groupsDir="${wlp.install.dir}/usr/shared/stackGroups/" controllerUser="adminUser" controllerUserPassword="adminPassword" scanningInterval="6000" scanningEnable="true"> </stackManager>
スキャンを無効にするには、scanningEnable を false に設定します。
- オプション: ファイル・システムで新しいスタック・グループの追加、更新、削除があるかスキャンするように、スケーリング・コントローラーに指示します。
スケーリング・コントローラーに WLP_STACK_GROUPS_DIR のロケーションでスタック・グループの追加、更新、削除をチェックさせる StackManager MBean 操作を実行します。 スケーリング・コントローラーの server.xml ファイルに scanningEnable="false" が指定されていても、 StackManager MBean 操作を実行して、追加、更新、削除のスキャンを実行させることができます。
StackManager MBean については、提供されている MBean のリストを参照してください。
- オプション: サーバーへのルーティングを有効にするため IHS を始動します。
IBM HTTP Server (IHS) が動的にプロビジョンされたクラスターにある Web アプリケーションをディスカバーしてルーティングを行えるようにするには、 スケーリング・コントローラーが置かれるホストで動的ルーティングを有効にします。IHS は、 プロビジョンされたサーバーのルーティング情報を動的ルーティング・サービスから取得します。サーバー状況が使用可能にされている場合、 ルーティング情報を表示することができます。
IHS がインストールされていない場合、『Liberty 集合に対する動的ルーティングのセットアップ』を参照してください。また、以下のビデオに、IBM Installation Manager を使用して動的ルーティングのサポートをインストールする方法が示されています。
ご覧ください: 「Enabling IHS for Liberty Dynamic Routing」のビデオには、IHS をインストールし、WebSphere Application Server の Web サーバー・プラグインをインストールし、動的ルーティングのインテリム・フィックスを適用する方法が示されています。[トランスクリプト]

ファイル名: twlp_autoscale_deployxml.html