一刻も早いリリースのために：アプリケーションの自動プロモーション
Pages: 1, 2

何も変更しませんでした、本当に！

制御された環境の果たす役割が明確になったところで、そうした環境を実際に確立するために必要なテクニックについて見ていきましょう。自動プロビジョニングはそのようなテクニックの1つです。

自動プロビジョニング

いつも設定ウィザードを使用して環境を構築しているユーザは、ウィザードでも非常に多くの手動操作を必要とするのに、そのようなプロセスを自動化で きるのだろうかと不思議に思うかもしれません。そのような方は、設定ウィザードのすべての機能をスクリプト言語で制御できるようにするBEA WebLogic Scripting Tool（WLST）に関する資料をお読みになることをお勧めします。WLSTでは、ウィザードで使用されているテンプレートをインポートし、ウィザード のグラフィカルインタフェースで可能なカスタマイズをスクリプト経由で同様に実行できます。WLSTのスクリプト作成については後で詳しく説明しますが、 今のところは、スクリプトによって環境を 構築できることを理解していただければ（あるいは信じていただければ）十分です。

表1で、異なるテスト環境間に存在すると考えられる相違点を示しました。ただし、このような相違の一部または全部がプロジェクトで適用されても、 プロビジョニングの中核部分は環境と環境の間で継承されます。その結果、それぞれの環境の同じプラットフォームに、同じアプリケーションスイートがデプロイされます。環境要件の相違を特定すれば、自動化プロセスを制御するスクリプトの内部で、成功したデプロイの共通の特徴を抽出できます。このようにして、 1つの環境に対するプロビジョニングによって他のすべての環境のためのプロトタイプが形成され、それを使用してアプリケーションスイートのテストが実施されます。 プロビジョニングの自動化スクリプトを作成する際には、それ以降のすべてのテスト環境のプロビジョニング要件をあらかじめ予測しておく必要があります。そのためには、直近のテスト環境と将来のテスト環境の間に存在すると考えられる相違を明確にすることが必要です。プロジェクトのテスト計画から該当項目を導き出し、表1のような表を作成してください。

スクリプトを使用して環境構築の自動化プロセスを制御すれば、一貫性を向上できるだけでなく、コンフィグレーションの変更管理によってプロビジョニ ングを制御することが可能になります。これは重要なメリットと言えます。環境コンフィグレーションを変更してテスト結果がよくなかった場合、その変更をそ のままにしておくとアプリケーションのパフォーマンスに悪影響を与える可能性があり、アプリケーションが使用不可になることすら考えられます。スクリプト を変更管理の下で管理すれば、スクリプトを前のバージョンに戻すこともできれば、提案したスクリプト変更が展開される前に必ず検証されるように設定するこ ともできます。また、コンフィグレーション管理システムでは変更の理由を記録でき、現在の設定に至るまでの過程を履歴として確認できるので、不適切である ことがわかっている設定、つまり試してみたが失敗だった設定に対して注意を喚起できることも少なくありません。

スクリプトを使用したプロビジョニングのメリットとして過小評価されがちなのは、 スクリプトによってプロビジョニングとデプロイのパターンを取得できる点 です。多くの場合、複数のマシンによる多数のサーバを備えた多層環境でのプロビジョニングは複雑なため、予想よりもはるかに時間がかかり、事前にはわから なかった多くの困難の存在が明らかになります。例えばプロビジョニングスクリプトを作成するときに、その時点ではわからないことの詳細を説明するコメント を挿入するなどの配慮がなされていれば、将来のプロジェクトでそのスクリプトを参照して、そのプロジェクトでプロビジョニングの問題にどう対処したかを詳 細に知ることができ、後のプロジェクトで同様の解決策をとるためのモデルとして活用できます。Orbismでは、プロビジョニングとデプロイの両方のタス クについて、BEAのコンサルタントの現場での体験に基づいた最新の リファレンス ソリューション ライブラリを構築しており、このような分野でよく見られる課題を対象にした一連のモデルソリューションを利用できるようになっています。

自動デプロイ

デプロイは取るに足らないオペレーションなので、自動化するメリットはほとんどないように思えるかもしれません。しかし、アプリケーション自体がき わめて些細なものでない限り、ほとんどの場合、デプロイをスクリプト化するとスクリプトの開発に手間をかけただけのメリットを得ることができます。

デプロイをスクリプト化すれば、一連のテストのテスト条件を一貫したものにすることができます。手動でデプロイした場合、同じ手順を同じ順序で行っ たかどうかを確認することは困難です。プロセスを自動化した場合、どのような手順が行われたかはスクリプトの内容を見れば明らかです。また、プロビジョニ ングのスクリプトと同様に、デプロイのスクリプト自体もコンフィグレーション管理と変更管理の対象にすることができます。

デプロイの作業は、単に新しい一連のデプロイファイルをデプロイツールで実行すればいいというだけでは済まない場合があります。デプロイファイルで は、明確な設定によってアプリケーションのコンポーネントに必要なリソースが定義されています。これらの正しい値は環境によって異なるため、正しくデプロ イするためにはデプロイファイルを修正する必要があります。WebLogic Platform 9.x環境にアプリケーションをデプロイする場合、このような値を適用する方法としてデプロイの計画を立てることが推奨されています。WebLogic Platform 9.2のオンラインドキュメントのこのページに、 異なる対象環境に同じアプリケーションをデプロイする場合のデプロイ計画の使用方法が説明されています。WebLogic Platform 8.1ではデプロイをカスタマイズするときに、アーカイブファイルを解凍し、展開した内容を解析および編集して、再度アーカイブを圧縮するという複雑な手 順が必要な場合があります。このような複雑な手順は自動化するに限ります。POサンプルファイルには、デプロイのためにデプロイ記述子を解析、変更する方法を示したサンプルコードとスクリプトが含まれています。

WebLogicドメインにデプロイや再デプロイを行うと、予期しない例外が発生することがよくあります。BEA Support Patternsサイトには、デプロイに失敗したときのトラブルシューティングに 関するセクションがあり、アプリケーションのデプロイ時や再デプロイ時に発生しやすい例外が多数紹介されています。多くの場合、推奨されている救済策は、 デプロイや再デプロイの前に追加の手順を実行することで、その追加の手順をアプリケーションのデプロイスクリプトに設定する必要があります。

アクセス制御の影響

制御された環境に特有の重要な特徴は、環境へのアクセスがポリシーによって規定されていることです。通常、環境が実運用環境に近付くほど、そのポリ シーは厳格になります。この点をわかりやすく示すため、表2では、表1と同じ環境を並べ、それぞれに想定されるアクセス制限を列記しました。

機能テスト	開発者がプロビジョニングのスクリプトを実行 開発者が環境を削除 運用担当者と開発者の両方が実行時の管理ツールと監視ツールを実行可能 開発者がプロビジョニングとデプロイのスクリプトを変更 開発者がデプロイのスクリプトを実行して新しいアプリケーションバージョンをデプロイ 開発者がテストを開始／中止
システムテスト	デプロイチームがプロビジョニングのスクリプトを実行 デプロイチームが環境を削除 運用担当者は実行時の管理ツールを実行可能 運用担当者と開発者は実行時の監視ツールを実行可能 デプロイチームがプロビジョニングとデプロイのスクリプトを変更可能 開発者がスクリプトを実行して新しいアプリケーションバージョンをデプロイ テストチームがテストを開始／中止
パフォーマンス	デプロイチームがプロビジョニングのスクリプトを実行 デプロイチームが環境を削除 運用担当者は実行時の管理ツールを実行可能 運用担当者と開発者は実行時の監視ツールを実行可能 デプロイチームがプロビジョニングとデプロイのスクリプトを変更可能 開発者がスクリプトを実行して新しいアプリケーションバージョンをデプロイ テストチームがテストを開始／中止
ユーザ受け入れテスト	デプロイチームがプロビジョニングのスクリプトを実行 デプロイチームが環境を削除 運用担当者は実行時の管理ツールと監視ツールを実行可能 デプロイチームがプロビジョニングとデプロイのスクリプトを変更 開発者がスクリプトを実行して新しいアプリケーションバージョンをデプロイ ユーザの代表がテストを開始

表2：テスト環境ポリシーの例

当然ながら、この表は大幅に省略されたものです。プロジェクトを成功させるためには、さまざまなチームが数多くの点で協力できる必要があります。例 えば、管理ツールをパフォーマンステスト環境で使用してシステムを調整する場合などは、運用スタッフに責任が割り当てられていますが、実際にはシステム アーキテクト、アプリケーション設計者、プラットフォームスペシャリストと協力して実施するのが適切な方法と考えられます。コラボレイティブなアプローチ によってチーム間で変更内容が討議され、同意に至っているとしても、特定のタスクを誰が実際に実施するかはポリシーに従います。

プロモーションを自動化するスクリプト

ここまで、ウィザードの代わりにスクリプトを使用した環境のプロビジョニングと、スクリプトを使用して自動化を促進する方法について説明しました。 ここからは、BEA WebLogic Platformのプロビジョニングの自動化を例として取り上げ、実際にはどのようなことを行うのかを説明します。また、これまでスクリプトを使用した環 境構築の経験のないユーザのために、サンプルスクリプトをいくつか紹介します。

BEA WebLogic Platformのスクリプト作成用の言語とツール

ここでは、環境構成用の スクリプト作成ツールを使用して自動化を進めます。これ以外にプロビジョニングの 仮想化を用いる方法もありますが、これは広く利用できるソリューションではありません。利用できる場合には、仮想化はスクリプト作成に代わる迅速なプロビジョニング方法になります。これについては、今後書かれるであろう別の記事に譲ります。

プロビジョニングを全体的に把握するためには、WebLogicドメインのコンフィグレーションだけでなく、次のような他の多くのシステムコンポーネントのコンフィグレーションについても取り扱う必要があります。

• ネットワークインフラストラクチャ
• ファイアウォール
• オペレーティングシステムのパッチ
• ハードウェアのロードバランサ
• コンテンツスイッチ
• データベース管理
• コンテンツ管理システム
• セキュリティサービスの統合
• バックエンドシステムの接続

ここでは、上記のすべてのインストールとコンフィグレーションについて何から何まで説明するスペースはないので、WebLogic Platformに範囲を絞り、Webサーバとデータベースサーバへの拡張について追加で少し触れることにします。この点に触れるのは、必要な場合には同 様のテクニックを使用して他の関連するシステムコンポーネントのプロビジョニングを行い、 同じプロビジョニングデータを共有できることを示すためです。関連するコンポーネント間でプロビジョニングデータを共有すると、プロビジョニングの際に発生する可能性のある多くのエラーを防止できます。

自動化の際に役立つスクリプト作成ツールは数多くありますが、この記事はツールの比較を行うことが目的ではありません。ここではWebLogic Platformのプロビジョニングが検討対象なので、主要なスクリプト作成ツールとしてWLSTを使用するものとします。WLSTは、Jythonスク リプト言語を使用するコマンドラインツールであり、Jythonはそれ自体がPythonスクリプト言語のJavaバインディングです。

WebLogic Platform 8.1には、WLSTの2つのバージョンが付属しています。 オフラインバージョン（単にWLSTと呼ばれます）はWebLogicドメインコンテンツの構築に使用し、もう1つの オンラインバー ジョン（WLSTOnline）は実行ドメインのコンフィグレーションの監視または変更に使用します。WebLogic Platform 9では、単一のWLSTツール（WLST）がオフラインモードでもオンラインモードでも動作します。説明をわかりやすくするため、ここからはオフライン モードでもオンラインモードでも動作するWLSTを使用しているものとして話を進めます。WebLogic Platform 8.1をお使いのユーザは、それぞれWLST（オフラインモード）またはWLSTOnline（オンラインモード）と読み替えてください。

オフラインモードのWLSTでは、ドメインの設定ウィザードと同等の機能をスクリプトによって実現できます。つまり、ドメインテンプレートに基づい てドメインを構築した後、段階的にドメインをカスタマイズしていくことができます。BEAでは、WLSTで使用できるデフォルトの汎用テンプレートを多数 用意しています。また、構成済みドメインからカスタムテンプレートを抽出できるテンプレート構築ツールも提供しています。WLSTではカスタムテンプレー トを使用して、テンプレートの元となったドメインと似た新しいドメインを作成できます。オフラインモードのWLSTでは、ドメインのディレクトリ構造を構 築してファイルストアに書き込むことができます。制御された環境をプロビジョニングする際には、ファイアウォールや他のアクセス制御にさえぎられて、ドメ インサーバがホストされたマシンにドメインディレクトリを直接書き込めない場合があります。アクセス制御に対応する方法については、また後ほど説明しま す。

オンラインモードのWLSTでは、WebLogic管理コンソールWebアプリケーションとほぼ同等の機能をスクリプトによって実現できます。つま り、実行時の状態を監視できるだけでなく、アクティブドメインのコンフィグレーションを検査および変更することができます。オンラインで動作している場 合、WLSTは常に既存のアクティブドメイン上で動作するため、テンプレートに依存しません。オンラインモードのWLSTは、JMXを使用して管理サーバ と通信します（管理対象のサーバとも通信しますが、通常プロビジョニング時には行いません）。この点が、オフラインモードのWLSTがディレクトリ階層を 書き込むだけであるのと大きく異なります。JMXに対するアクセス制御が設定されている場合、管理サーバJMXインタフェースにアクセスできる方法は限定 されます。プロビジョニングのスクリプトは、このような制約に対応できる必要があります。

適応可能なスクリプトの作成

プロビジョニングを自動化する主なメリットは、すでに説明したとおり、1つの環境に対するプロビジョニングスクリプトを他の環境のためのプロトタイ プとして利用できることです。このように利用するためには、スクリプトの動作が特定の環境要件に適応するようにプロビジョニングのスクリプトを作成する必 要があります。真に適応可能なスクリプトを実装するには、高度なスクリプト言語が必要です。幸いなことに、JythonおよびPythonはこのような要 請にぴったりです。

WLSTを使用すると、プロビジョニングのスクリプトはJython言語で記述されます。WLSTを起動してそのスクリプトを実行すると、実際には WLSTツールに組み込まれたJythonインタプリタが実行されます。また、Jythonインタプリタを起動し、それにWLSTをロードして、作成した Jythonスクリプト内でWLSTコマンドを実行することもできます。このいずれかの方法で、Jython言語の能力をフルに活用できます。

以下は、環境プロビジョニングのスクリプト（WLSTオフラインスクリプト）の抜粋です。

weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])




hostnames = profile[ 'managed.server.hosts' ]




managed_server_count = len( hostnames )







for idx in range( managed_server_count ) :




listen_address = hostnames[idx]




interface_address = listen_address




managedServer = create( managedServerName, 'Server')




managedServer.setInterfaceAddress( interface_address )




managedServer.setListenAddress( interface_address )




managedServer.setListenPort( weblogic_listen_port )

ここでは作成方法は説明しませんでしたが、 profileはPythonの辞書オブジェクトであり、プロビジョニング対 象の特定の環境ごとに変数を定義するキーと値のペアが格納されています。これらの値は、1つ以上の外部のプロパティファイルからロードすることも、最初に 別のJythonスクリプトをインポートし、そのスクリプトを使用して設定することもできます。以下は、Jythonインポートファイルの外観を示した、 同様に簡単な例です。

def getProfile () : 




env = {} 




env['managed.server.listen.port'] = 7001 




env['managed.server.hosts'] = \




[ "hostname_1", "hostname_2", "hostname_3" ] 


return env

これが例えば、 environment.pyという名前のJythonファイル内にある場合、以下の2行を使用すれば profileオブジェクトを初期化することができます。

import environment


profile = environment.getProfile()

Jythonの機能を使用したことによって必要なエントリ数がどれだけ減っているかに注意してください。環境内に存在する管理対象サーバの数は、必ずしも明示的に定義する必要はありません。 managed.server.hosts要素の内容から黙示的に取得できるからです。

上に示したのは極めて簡単な例ですが、適応可能な重要なテクニックがいくつか示されています。

• プロビジョニングの変数部分が、プロビジョニングスクリプトにインポートされています。この例では、変数はプロパティファイルからロードされていますが、別のJythonスクリプトからでも同じようにインポートできます。
• スクリプトは拡張可能です。管理対象サーバ1台分のコンフィグレーションにも、膨大な台数のサーバのコンフィグレーションにもこのスクリプトは動作します。スクリプトを変更する必要はありません。
• スクリプトで必須パターンが利用されています。このパターンはすべての環境に対して共通です。この例で言う と、すべての管理対象サーバがリスンインタフェースと同じインタフェースアドレスを使用することと、すべての管理対象サーバが同じリスンポートを使用する ことがパターンです。また、各管理対象サーバの一意のサーバ名は <basename><index> という形式で表わされていますが、ここで <basename>は、すべてのサーバに共通しています。この例では、 <basename>は managedServerNameRootというキー値を持つ辞書要素から取得され、 indexには1から順に値が入ります。このようなコンフィグレーションのパターンは、大規模な環境によく見られるものです。

ではここで、上の管理対象サーバは常にクラスタの一部だと考えてください。クラスタを構成するには、クラスタアドレスを設定する必要があります。ク ラスタアドレスは、DNS名に設定することも、サーバIPアドレスとポート番号のカンマ区切りのリストにすることもできます。テスト環境の段階が進んでか らやっとDNSサーバが構成されるというのはよくあることです。それでは、このコードの抜粋に少しばかり行を追加しましょう（Jythonのインポートに も同様に追加します）。

import environment


profile = environment.getProfile()



weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])
hostnames = profile[ 'managed.server.hosts' ]
managed_server_count = len( hostnames )
cluster_list = ''

for idx in range( managed_server_count ) :


listen_address = hostnames[idx]


interface_address = listen_address


managedServer = create( managedServerName, 'Server' )


managedServer.setInterfaceAddress( interface_address )


managedServer.setListenAddress( interface_address )


managedServer.setListenPort( weblogic_listen_port )


cluster_list = \


cluster_list + listen_address + ":" + str(weblogic_listen_port)



if 'cluster.dns.name' in profile :


cluster.setClusterAddress( profile['cluster.dns.name'] )


else :




cluster.setClusterAddress( cluster_list )

この変更された抜粋では、サーバのリスンアドレスとリスンポートのカンマ区切りのリストが累積されています。DNS名がプロファイル内で提供されて いる場合（この例はそうではありません）、そちらをクラスタアドレスとして使用できますが、デフォルトでは累積されたアドレスとポートのリストが使用され ます。

エンドツーエンドのプロビジョニング：コンフィグレーションデータの共有

ほとんどのテスト環境では、WebLogicドメイン以外にもプロビジョニングが必要です。例えば、Apache Webサーバを使用して静的HTTPコンテンツにサービスを提供し、クラスタ内の管理対象サーバに対するHTTP要求の負荷分散も行う場合、このような他 の環境コンポーネントのコンフィグレーションもプロビジョニングスクリプトで実装できます。以下は、Apache Webサーバ用のコンフィグレーション値を追加して若干拡張したenvironment.pyを示したものです。

def getProfile () : 




env = {} 


env['managed.server.listen.port'] = 7001 


env['managed.server.hosts'] = \


[ "hostname_1", "hostname_2", "hostname_3" ]


env['apache.listen.port'] = 8080


return env

これを利用するには、プロビジョニングスクリプトに数行を追加します（新しい行は抜粋の末尾に追加されています）。

import environment
                          


profile = environment.getProfile()  
                          


                           


weblogic_listen_port = int(profile[ 'managed.server.listen.port' ])
                          


hostnames = profile[ 'managed.server.hosts' ]
                          


managed_server_count = len( hostnames )
                          


cluster_list = ''
                          


                           


for idx in range( managed_server_count ) :
                          


  listen_address = hostnames[idx]
                          


  interface_address = listen_address
                          


  managedServer = create( managedServerName, 'Server' )
                          


  managedServer.setInterfaceAddress( interface_address )
                          


  managedServer.setListenAddress( interface_address )
                          


  cluster_list = \
                          


  cluster_list + listen_address + ":" + str(weblogic_listen_port)
                          


                           


if 'cluster.dns.name' in profile :
                          


  cluster.setClusterAddress( profile['cluster.dns.name'] )
                          


  else :
                          


  cluster.setClusterAddress( cluster_list )
                          


                           


f = open('weblogic.conf', 'w')
                          


f.write('<IfModule mod_weblogic.c>\n')
                          


f.write(' WebLogicCluster ')
                          


f.write(cluster_list)
                          


f.write('\n')
                          


f.write(' MatchExpression *.jsp\n')
                          


f.write('</IfModule>\n')
                          


f.close()
                          


f = None
                          


                           


f = open('httpd.conf', 'w')
                          


f.write('Listen = ')
                          


f.write( str( profile[ 'apache.listen.port' ] ) )
                          


f.write('\n')
                          


f.write('LoadModule weblogic_module modules/mod_wl_20.so\n')
                          


f.write('<IfModule mod_weblogic.c>\n')
                          


f.write(' Include conf/weblogic.conf\n')
                          


f.write('</IfModule>\n')
                          


f.close()
                          


 
                        

末尾に追加された行により、Apache WebサーバとWebLogicプラグインそれぞれのコンフィグレーションを行う httpd.confと weblogic.confが作成されます。 httpd.confとして以下が出力されます。

Listen = 8080
LoadModule weblogic_module = modules/mod_wl_20.so
Include conf/weblogic.conf

また、以下は environment.pyから生成される weblogic.confです。

<IfModule mod_weblogic.c>
                          


WebLogicCluster hostname_1:7001,hostname_2:7001,hostname_3:7001
                          


MatchExpression *.jsp
                          


</IfModule> 
                        

httpd.confのコンフィグレーションのために、先ほどの environment.pyファイルから取得されたキー値 apache.listen.portが 使用されます。ただし、プラグインのコンフィグレーションには、WebLogicクラスタ自体のコンフィグレーションの副産物として累積されたデータが使 用されることに注意してください。WebLogicドメインのコンフィグレーションデータは、それに関連する別のコンポーネントのコンフィグレーションに も使用されています。このようにコンフィグレーションデータを共有することで、相互に依存するコンポーネントのコンフィグレーション間に発生する多くの不 一致を防止することができます。

もっとも、Jythonで直接コンフィグレーションファイルを書き込む点に関して言えば、ここで使用しているテクニックは、コンフィグレーション ファイルのサイズが非常に小さい場合以外、あまりお勧めできません。実際には、Apache Webサーバを含めて多くのコンフィグレーションファイルはサイズが大きすぎるため、このように単純に処理することはできません。このような場合、 Jythonを使用してコンフィグレーション値を持つプロパティファイルを出力してから、 Antによってそのプロパティファイ ルをインポートし、コンフィグレーション ファイル テンプレートのトークンを置き換えるほうが適切です。BEAでは、WebLogic Platform 8.1および9.xのインストールでAntを実行するJythonスクリプトを含めているため、WLSTスクリプト内からAntを使用することは簡単で す。

過剰なパラメータ化に注意

ここまで、複数の環境に使用できる適応可能なスクリプトのメリットを紹介してきましたが、過剰なパラメータ化には用心する必要があります。たとえス クリプトでデフォルト値を自動的に設定できるとしても、環境間で変化しない属性や値のパラメータは作成しないようにしてください。不要なパラメータがある とスクリプトが複雑でわかりにくくなります。ここで作成しようとしているのは、プロジェクトが終了して担当者が別のプロジェクトに移ってしまった後でも、 他の担当者が再利用できるようなスクリプトです。不要なパラメータを定義すると、後でそれを再利用しようとする担当者が、「すべての環境に同じ値を適用す るのにこの設定はどうして変数になっているのだろう。何か足りないのだろうか」と疑問に思う可能性があります。その担当者があなたのメールアドレスなり電 話番号なりを知っていて、すっかり忘れてしまっているに違いないプロジェクトについて説明を求めてくるかもしれないことを覚えておいてください。

まとめ

BEA WebLogic Platformのインストールには、WLST、Jython、Antという3つの強力なスクリプト作成ツールが付属しています。これらのスクリプト作成 ツールを使用して適応性とメンテナンス性に優れた強力なプロビジョニングとデプロイのスクリプトを構築すれば、アプリケーションがそれぞれの要件に準拠し ていることを確認する必要があるプロジェクトで、あらゆる環境にそのスクリプトを適用することができます。スクリプトを利用すると、構築される環境の間の 一貫性を向上できるだけでなく労力の削減にもつながるため、2倍のメリットが得られます。

Paul Nixon氏は、Orbism Ltd.のテクニカルディレクタです。同社は、BEA Platformソリューションのデプロイおよびシステム管理の自動化を専門とするコンサルタント企業であり、Nixon氏は、17の業種を対象に30年以上の経験を積んでいます。