Amazon Web Services 環境における WebOTX Enterprise Service Bus 環境構築ガイド (Linux 版 ) 2015 年 9 月第 1 版 NEC

Transcription

1 Amazon Web Services 環境における WebOTX Enterprise Service Bus 環境構築ガイド (Linux 版 ) 2015 年 9 月第 1 版 NEC

2 Copyright NEC Corporation All rights reserved. 免責事項本書の内容は 予告なしに変更されることがあります 日本電気株式会社は 本書の技術的もしくは編集上の間違い 欠落について 一切責任をおいません また お客様が期待される効果を得るために 本書に従った導入 使用および使用効果につきましては お客様の責任とさせていただきます 本書に記載されている内容の著作権は 日本電気株式会社に帰属します 本書の内容の一部または全部を日本電気株式会社の許諾なしに複製 改変 および翻訳することは禁止されています 本書で利用するサンプルには Oracle Java Platform, Standard Edition(Java SE) を含みます Java SE のご利用に際しては Oracle バイナリ コード ライセンス ( ) に同意の上ご利用ください ( 商標について WebOTXは日本電気株式会社の登録商標です Microsoft Windows Internet Explorer は 米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です Windows の正式名称は Microsoft Windows Operating System です Linuxは Linus Torvaldsの米国およびその他の国における商標または登録商標です MySQLは Oracle Corporation 及びその子会社, 関連会社の米国及びその他の国における登録商標です JavaおよびすべてのJava 関連の商標は Oracle Corporation 及びその子会社, 関連会社の米国及びその他の国における登録商標です PostgreSQLは PostgreSQLの米国およびその他の国における商標です Amazon Web ServicesおよびすべてのAmazon Web Services 関連の商標 ならびにその他のAmazon Web Servicesのグラフィック ロゴ ページヘッダー ボタンアイコン サービス名は 米国および / またはその他の国における Amazon Web Servicesの商標 登録商標またはトレードドレスです その他 記載されている会社名 製品名は 各社の登録商標または商標です 2

3 目次 1. はじめに 対象読者と目的 用語一覧 最新情報の入手先 お問い合わせ方法 導入手順 EC2 インスタンスの作成 動作確認 ESB 環境の自動構築概要 背景 AWS CloudFormation の概要 Chef の概要 WebOTX ESB 環境構築のための AWS CloudFormation / Chef サンプル ESB 環境の自動構築手順 CloudFormation と Chef によるスタック作成手順 動作確認 EC2 インスタンスへの接続 スタックの削除 構成のカスタマイズ カスタマイズしたクックブックの使用 配備するアプリケーションの変更 WebOTX AS/ESB のチューニング

4 1. はじめに 1.1. 対象読者と目的 本書では Amazon Web Services( 以下 AWS) 上に WebOTX Enterprise Service Bus( 以下 ESB) V9.2 環境を構築する方法を説明します 本書を理解することで AWS 上に用途に応じた任意の構成のシステムを構築する方法を習得することができます 2 章ではあらかじめ ESB がインストールされた AMI を用いて AWS 上に ESB 環境を構築する方法を説明します 3 章 4 章では事前に定義した構成ファイルを用いて ESB を利用した HTTP SOAP バインディングのサンプルシステムを自動構築する方法を説明します ここでは 構成ファイルとして AWS CloudFormation テンプレートと Chef クックブックを使用します 5 章では本書と合わせて提供している AWS CloudFormation テンプレートと Chef クックブックのサンプルをカスタマイズして独自の環境を構築する方法を解説します 4. ESB 環境の自動構築手順 までの対象読者は 以下に該当する方です EC2 インスタンスの前提知識を有しており かつ以下の権限が与えられている IAM ユーザ AWS Management Console にログインする権限が与えられている EC2 インスタンスを生成する権限が与えられている 5. 構成のカスタマイズ 以降の対象読者は以下に該当し システム構成やパラメータ アプリケーションを変更し 任意の構成のシステムを構築する方法を習得する必要がある方です JSON Ruby の記述方法を習得している もしくはマニュアルなどを参照して理解することができる スタックに追加する AWS サービスの基本的な知識を有している もしくはマニュアルなどを参照して理解することができる アプリケーションサーバや OSS に関する基本的な知識を有している もしくはマニュアルなどを参照して理解することができる WebOTX Application Server および WebOTX ESB の運用管理コマンドを使うことができる もしくはマニュアルなどを参照して理解することができる 1.2. 用語一覧 WebOTX Enterprise Service Bus の用語一覧 用語 ESB(Enterprise Service Bus) ドメイン サービスアセンブリ BC( バインディングコンポーネント ) サービスエンジン サービスユニット Inbound 説明 SOA に基づいたシステムのメッセージング基盤となるソフトウェアです 主にルーティング プロトコル変換 メッセージ変換を備えます WebOTX Application Server の基本的な構成単位をドメインと呼びます ドメインは WebOTX Application Server で管理するリソースやサービス群を論理的にグルーピングしています ドメインは独立して運用され コンフィグレーション情報など構成情報はドメイン単位で独立したディレクトリに管理されます サービスユニットを一つ以上まとめてパッケージしたものです サービスアセンブリ単位で配備やライフサイクル管理等の運用を行います 様々なプロトコルで ESB 外部のサービスやシステムと通信するモジュールです メッセージ変換やシーケンス制御など ESB 内部で処理を行うモジュールです バインディングコンポーネントやサービスエンジンのコンポーネントに関する設定情報をパッケージしたものです 外部のサービスからリクエストメッセージを受け取って NMR へ送信し さらにそのレスポンスを受信して外部のサービスへ返却するコンシューマ機能です 4

5 Outbound NMR(Normalized Message Router) NMR から送られてきたリクエストメッセージを外部のサービスに送信し さらにそのレスポンスを受信し NMR へ返却するプロバイダ機能です ESB 内部でバインディングコンポーネントやサービスエンジン間でメッセージを送受信する機能です その他の用語については WebOTX マニュアル ( の用語集 ( を参照してください AWS の用語一覧 詳細は AWS の Web サイト ( を参照してください 用語 説明 AWS Management Console ウェブベースのユーザインターフェイスで AWS にアクセスして管理するコンソールです Amazon EC2 EC2 インスタンス AMI キーペア Amazon VPC セキュリティグループ Amazon が提供する計算資源を用いてアプリケーションを実行する商用ウェブサービスです OS がセットアップされた AWS 上の仮想サーバです Amazon Machine Image の略で ソフトウェア構成 (OS アプリケーションサーバ アプリケーションなど ) を記録したテンプレートです AMI から AMI のコピーである EC2 インスタンスを起動します Amazon EC2 はパブリックキー暗号を使用して ログイン情報の暗号化と復号化を行います パブリックキー暗号は パブリックキーを使用してパスワードなどのデータを暗号化し 受信者はプライベートキーを使用してデータを復号化します パブリックキーとプライベートキーは キーペアと呼ばれます EC2 インスタンスにログインするには キーペアを作成し EC2 インスタンスを起動するときにキーペアの名前を指定して EC2 インスタンスに接続するときにプライベートキーを指定する必要があります AWS が提供する仮想ネットワークサービスです 独自の VPC を定義して 各環境を分離したネットワーク上に配置することが出来ます AWS 上の EC2 インスタンスのアクセスを制御するファイアウォールです AWS CloudFormation の用語一覧 詳細は AWS CloudFormation( 以下 CloudFormation) の Web サイト ( を参照してください 用語 スタック テンプレート 説明 AWS サービスの集合のことをスタックといいます AWS CloudFormation ではスタック単位で AWS サービスの集合を管理します 例えば スタックの破棄を実行すると スタックに紐づくすべてのリソースが破棄されます スタックの構成を JSON 形式で記述したものです AWS CloudFormation ではテンプレートの内容を元にスタックを構築します Chef の用語一覧 詳細は Chef の Web サイト ( を参照してください 用語 クックブック レシピ 説明 Chef によるサーバインフラストラクチャの情報をまとめた単位です クックブックは必ず目的を持ち ( 例えば MySQL をインストールして利用可能な状態にするなど ) その目的を達成するために必要なレシピや属性ファイルなどを持ちます クックブックを構成する要素の 1 つで 開発やテストで構築するサーバのインフラストラクチャのあるべき姿を定義した仕様書です Chef はレシピの定義に従ってインフラストラクチャの構築を行います レシピの定義は Ruby の文法で記述します 5

6 1.3. 最新情報の入手先 最新の製品情報については 以下の Web サイトを参照ください お問い合わせ方法 本ガイド記載事項における各種問い合わせにつきましては 以下のメールアドレスへお問い合わせください 6

7 2. 導入手順 本章では 以下の AMI を使用して AWS 上に WebOTX Enterprise Service Bus が導入された EC2 インスタンスを作成する手順を説明します AMI 情報 Region AMI Name AMI ID Tokyo WebOTX-ESB-RHEL6.5_x ami-862bf586 OS Red Hat Enterprise Linux 6.5 Java Java7u80 (Linux x64) WebOTX Application Server WebOTX Enterprise Service Bus 補足 WebOTX Application Server V9.2 Express ( ライセンス期限 2016/06/08 まで ) WebOTX Enterprise Service Bus V9.2 ( ライセンス期限 2016/06/08 まで ) Web サーバとして WebOTX Web Server 2.2(Apache HTTP Server 2.2 ベース ) を使用しています WebOTXAdmin ドメインと domain1 ドメインが作成されており domain1 には ESB の機能が追加された状態です 作業は AWS Management Console 上で行います リージョンを以下のように AWS Management Console 上部のナビゲーションバーで アジアパシフィック ( 東京 ) に変更した上で実施してください 7

8 2.1. EC2 インスタンスの作成 EC2 インスタンス作成前の作業 下記の手順は AWS Management Console で EC2 サービスのメニューから実施してください 1. キーペア ( ) の作成 1) EC2 サービスメニュー左側のナビゲーションペインで キーペア をクリックします 2) キーペアの作成 をクリックします 3) キーペアの作成 ダイアログボックスの キーペア名 フィールドに 新しいキーペアの名前を例として WebOTX-Key と入力し 作成 をクリックします 4) プライベートキーファイル (WebOTX-Key.pem) のダウンロードが始まります このファイルはインスタンスのログイン認証の際に必要なファイルです 外部に漏洩することの無い安全な場所に保存してください ( ) AWS の用語一覧 参照 AMI からの EC2 インスタンス作成 1. AMI の選択 1) EC2 サービスメニュー左側のナビゲーションペインで AMI を選択し AMI の一覧を表示させます 2) Filter の 自己所有 を パブリックイメージ に変更します パブリックイメージ に変更すると すべての AWS アカウントに公開されている AMI が表示されます 3) 2 導入手順 の冒頭の情報を参照し 検索ボックスに AMI Name あるいは AMI ID を入力して検索を行います 表示される AMI を選択して 作成 ボタンを押下します なお 利用環境によっては AMI の検索に時間がかかることがあります 2. インスタンスタイプの選択 EC2 インスタンスのインスタンスタイプを選択します 無料利用枠として利用可能な t2.micro を選択して 次の手順 : インスタンス詳細の設定 ボタンを押下します 8

9 Note EC2 インスタンスの起動には インスタンスのタイプ 起動時間 データ転送量 EBS の容量等に応じて利用料金が発生します AMI から EC2 インスタンスを作成する際には AWS の Web サイトの料金表を確認してください 3. EC2 インスタンスの詳細設定 EC2 インスタンスの詳細設定については既定値を変更せずに 次の手順 : ストレージの追加 ボタンを押下して次に進みます 4. ストレージの追加 既存のストレージの設定変更 ストレージの追加は行わず 次の手順 : インスタンスのタグ付け ボタンを押下して次の設定に進みます 5. タグの設定 EC2 インスタンスのタグとして Key と Value の組み合わせで設定を行うことができます ここではキーの Name に対応する値を 例として WebOTX-ESB-Instance と設定します これにより 作成される EC2 インスタンスの Instance Name(EC2 インスタンスの EC2 インスタンス名 ) が WebOTX-ESB-Instance になります 設定が終わったら 次の手順 : セキュリティグループの設定 ボタンを押下して次の設定に進みます 6. セキュリティグループの設定 WebOTX が提供する AMI から作成される EC2 インスタンスは 利便性を高めるために OS のファイアウォールの設定が解除されています したがって 適切なセキュリティグループの設定を行う必要があります あらかじめ作成済の 22 番ポートと 80 番ポートへのアクセスを許可するセキュリティグループを選択し 確認と作成 ボタンを押下して次の設定に進みます 7. 起動する EC2 インスタンスの設定確認 作成する EC2 インスタンスの設定値が表示されます 作成 ボタンを押下します 8. キーペアの設定 キーペアの選択を行います あらかじめ作成しておいたキーペアである WebOTX-Key を キーペアの選択 で選択します EC2 インスタンスへのログインはここで指定したキーペアを使用して SSH によって行います インスタンスの作成 ボタンを押下すると EC2 インスタンスの作成が開始されます EC2 インスタンスの作成にはしばらく時間がかかります 手順 5 タグの設定 で前述した通り 作成される EC2 インスタンスの名前は WebOTX-ESB-Instance です 作成した EC2 インスタンスへの接続 1. ナビゲーションペインから インスタンス を選択し EC2 インスタンスの一覧を表示させます 9

10 2. 検索ボックスに WebOTX-ESB-Instance と入力して検索を行い 接続する EC2 インスタンスを表示します 3. 接続する EC2 インスタンスが Instance State が running となっていることを確認します Instance State が stopped の場合は 接続する EC2 インスタンスを選択し Actions Start を押下し Instance State が running となるまで待ちます 4. 接続する EC2 インスタンスの Public DNS を確認します 接続する EC2 インスタンスを選択し 下ペインの Public DNS の値を確認します 10

11 Note Public DNS の値は EC2 インスタンスを停止するたびに変更されます 設定により EC2 インスタンスに静的な DNS を割り当てて 停止しても Public DNS を変更しないようにすることも可能です 詳細は下記をご参照ください 5. ssh 接続で EC2 インスタンスへ接続します 以下のコマンドを実行して EC2 インスタンスの ec2-user ユーザにログインします chmod 400 <WebOTX-Key.pem> ssh -i <WebOTX-Key.pem> < 手順 4 で調べた Public DNS> 2.2. 動作確認 以下の動作確認は 接続した EC2 インスタンス上で実施してください WebOTX Application Server の起動確認 以下のコマンドを実行して WebOTX Application Server が起動していることを確認します /opt/webotx/bin/otxadmin list-domains 以下のように出力されれば 正常に WebOTX Application Server が起動しています WebOTXAdmin running domain1 running domain1 が起動していない場合は 以下のコマンドを実行します sudo /opt/webotx/bin/otxadmin start-domain domain1 ドメイン起動コマンドを実行したら 上記の list-domains でドメインが動作していることを確認してください 11

12 3.ESB 環境の自動構築概要 本章では 2 章で使用した AMI をベースに 任意のサービスアセンブリが配備された WebOTX Enterprise Service Bus の EC2 インスタンスを自動作成する手順を説明します 3.1. 背景 AWS CloudFormation / Chef サンプル提供の背景 近年 クラウドコンピューティングサービスとして AWS が急速な普及を進めています また Chef も近年の開発プロセスの変化に伴い 開発者の間で急速な広まりを見せています 開発プロセスの一例としてアジャイル型開発技法を挙げると アジャイル型開発技法では計画 設計 実装 テストを細かく分割して繰り返し実行するのですが テストを行うための環境を構築する作業を繰り返し行う必要があり これが開発の負担になってしまいます この問題を AWS CloudFormation と Chef を活用することで 解決することができます CloudFormation を用いることで テンプレートから AWS のスタックを短時間で作成することができ これに加えて Chef を用いることで OS 上のテスト環境を短時間で作成することができます しかもソフトウェアによる環境構築なので 手作業での環境構築と比較しヒューマンエラーを軽減することができます このように 開発プロセスの変化に伴い CloudFormation や Chef の重要性が増してきています 開発プロセスの変化に柔軟に対応するため CloudFormation と Chef を用いて AWS 上に WebOTX ESB の環境を構築するためのサンプルを提供します 3.2. AWS CloudFormation の概要 AWS CloudFormation とは AWS CloudFormation( 以下 CloudFormation) とは AWS サービスを組み合わせたスタックの構成を JSON 形式で記述して その構成の作成 管理を容易にする AWS のサービスです ユーザは独自のテンプレートを作成して自由なスタック構築を行うことが可能です あるいは CloudFormation で既に用意されているサンプルテンプレートを利用してスタック構築を行うことも可能です CloudFormation は追加料金なし (2015 年 6 月時点 ) で利用でき テンプレートに従って構築された各 AWS サービスに対しての課金のみが発生します CloudFormation の主な特長は以下です 容易な環境構築が可能 テンプレートを作成しておけば 短時間でスタックを構築できます 起動時にパラメータを渡すことができるので さまざまな設定値によるスタックを単一のテンプレートで行うことが可能です また パラメータを変更せずに 同様のスタックを繰り返し構築することもできます 一般的な形式によるテンプレート記述が可能 CloudFormation テンプレートは JSON 形式のテキストファイルです リソースの調査が可能 CloudFormation にテンプレートのコピーが保持されるので スタック作成時に適用した正確なリソース設定を必要に応じて見返すことができます 12

13 3.3. Chef の概要 本ドキュメントでは構成管理ツール Chef を用いて WebOTX AS の設定を行う方法を紹介します Chef は AWS インスタンス起動時に自動で実行されますので 試しに環境設定済みの WebOTX ESB を AWS インスタンス上で操作してみたい方は Chef の存在を意識する必要はありません しかし Chef を使って WebOTX ESB の設定変更を行いたい場合は本章の内容を理解しておく必要があります 本章は Chef を使用したことがないという方を対象に Chef とは何か 何が出来るのか どのような用途で使用するのかを説明します Chef とは Chef はサーバインフラストラクチャを自動で構築してくれるソフトウェアです ここでいう環境にハードウェアは含まれません あくまでソフトウェアやファイル ネットワーク設定などの OS 上の環境構築を行います Chef ではサーバインフラストラクチャの構築に環境情報を記述したコードを用います インフラストラクチャのあるべき状態をコードで定義しておけば そのコードが表す状態のサーバ設定を Chef コマンドひとつで作成することができます 例えば Chef を使って nginx のような Web サーバと PostgreSQL のような RDBMS がインストールされて そこに Web ページが配備された環境を作ることができます また よりプライベートな使い道として よく使用するアプリケーションを定義しておき PC をリプレースする際にそれらを一括でインストールすることもできます これにより 今まで手作業で行っていた環境構築作業を短時間でより正確に実施することができます Chef ソフトウェア体系 Chef は Chef 社 ( 旧名 Opscode 社 ) が開発し 2009 年に初めて発表しました その後 Chef の開発は継続的に進められ 2015 年 9 月現在 Chef 社は Chef の名を冠した製品を複数リリースしています それぞれどのような製品なのかを簡単に紹介します ソフトウェア Chef Client Chef Server Chef Development Kit 説明 最も基本的な Chef 製品です クックブックを実行してローカルマシンに開発やテストで作成するサーバのインフラストラクチャを構築します その名の通りクライアントとして動作し Chef Client をインストールした複数のマシンを 1 台の Chef Server インストールマシンから管理することができます また Chef Server と連携せずに単体で使用することもできます Chef Client をインストールしたマシンを管理するソフトウェアです マシンを複数台使用するシステムにおけるサーバの構築に使用します Chef Server を使用する場合には Chef Server をインストールする専用サーバマシンが必要になります そのためマシン台数が十台を超える大規模なシステム開発で使用されることが多いです Chef のクックブック作成に有用な開発者用のツールをまとめたパッケージです これらのソフトウェアは 2015 年 9 月現在 以下のページから入手が可能です なお 本ドキュメントでは Chef Client のみを使用します 3.4. WebOTX ESB 環境構築のための AWS CloudFormation / Chef サンプル WebOTX ESB 環境構築サンプル構成 提供する CloudFormation テンプレートからのスタック作成動作について説明します 13

14 [A] CloudFormation の実行を開始 スタック作成ユーザが AWS Management Console の CloudFormation メニューから CloudFormation テンプレートを用いてスタック作成を開始します [B] CloudFormation が以下の処理を行うことでスタックを作成 [B-1] EC2 インスタンス作成 起動 CloudFormation テンプレートで指定されている AMI から EC2 インスタンス ( 図中 EC2 Instance) の作成と起動を行います この AMI は WebOTX AS インストール済みの公開 AMI です したがって 作成される EC2 インスタンスにはすでに WebOTX AS がインストールされています 公開 AMI についての詳細は次の Web ページの クラウド上の評価環境のご案内 を参照してください [B-2] セキュリティグループ設定 EC2 インスタンスに対して アクセスを制御するファイアウォールであるセキュリティグループを設定します セキュリティグループの名前は EC2SecurityGroup です このセキュリティグループは EC2 インスタンスに対する HTTP(80 番ポート ) 以外のアクセスを全て遮断します [B-3] クックブックのダウンロードと Chef-Client 実行 Chef のクックブックをダウンロードして chef-client コマンドを [B-1] で作成した EC2 インスタンス上で実行します chef-client コマンドはクックブックをクライアント上で実行する Chef Client のコマンドです chef-client 実行により クックブックに定義されている下記の手順 [C] の処理が実行されます [C] Chef がアプリケーション動作環境の設定 構築 14

15 [C-1] サンプルアプリケーション ( サービスアセンブリと Web アプリケーション ) のダウンロードと配備 作成されるスタックの構成を以下に示します スタック情報 EC2 インスタンス ( 図中 EC2 Instance) EC2SecurityGroup 備考 WebOTX Application Server V9.2 Express と WebOTX Enterprise Service Bus V9.2 がインストールされています Chef Client がインストールされており chef-client の実行により WebOTX AS WebOTX ESB の設定とサンプルアプリケーション HttpInbound_SoapOutbound SoapService が配備された状態です 外部からの不正なアクセスを防ぐため セキュリティグループの EC2SecurityGroup が設定されています 80 番ポート (HTTP) へのアクセスのみを許可しています EC2 に設定されている EC2SecurityGroup が 80 番ポート以外のアクセスを許可していないため ポート 22 番で接続する SSH を用いてインスタンスに接続することはできません EC2 インスタンスに SSH 接続する場合は 4.3 EC2 インスタンスへの接続 を参照の上 セキュリティグループの設定を変更してください 15

16 4.ESB 環境の自動構築手順 4.1. CloudFormation と Chef によるスタック作成手順 スタック作成前の作業 下記の手順は AWS Management Console で EC2 サービスのメニューから実施してください 1. キーペア ( ) の作成 節で既にキーペアを作成済みの場合は 本手順を行う必要はありません 1) EC2 サービスメニュー左側のナビゲーションペインで [ キーペア ] をクリックします 2) [ キーペアの作成 ] をクリックします 3) [ キーペアの作成 ] ダイアログボックスの [ キーペア名 ] フィールドに 新しいキーペアの名前を例として WebOTX-Key と入力し [ 作成 ] をクリックします 4) プライベートキーファイル (WebOTX-Key.pem) のダウンロードが始まります このファイルはインスタンスのログイン認証の際に必要なファイルです 外部に漏洩することの無い安全な場所に保存してください ( ) AWS の用語一覧 参照 2. CloudFormation テンプレートのダウンロード 以下の URL から CloudFormation テンプレートをダウンロードします なお クックブックは CloudFormation によるスタック作成時に自動的にダウンロードされますので 利用者によるダウンロードは不要です スタック作成 1. スタック作成 1) AWS Management Console で CloudFormation のメニューを選択します 16

17 2) Create a Stack を押してスタック作成画面に進みます 17

18 2. テンプレートの選択 (Select Template) 以下の操作を行った上で 右下の Next をクリックして次の画面に進みます Stack の Name に WebOTX-ESB-Stack と入力します ( これがスタックの名前になります この名前が CloudFormation メニューのスタック一覧の Stack Name に表示されます ) Template の Source で Upload a template to Amazon S3 を選択し ファイルを選択 を押し スタック作成前の作業として 節であらかじめダウンロードしておいた CloudFormation テンプレートを指定します 3. パラメータの指定 (Specify Parameters) 以下のそれぞれのパラメータに値を入力して Next をクリックして次の画面に進みます 項目名入力する値項目の説明 EC2SecurityGroup InboundSource /0 EC2 インスタンスに設定するセキュリティグループの 80 番ポートへのアクセスを許可する IP アドレスです 規定値の /0 を設定すると 80 番ポートへのアクセスに関して 接続元の IP アドレスによる制限を行いません InstanceType t2.micro EC2 インスタンスのインスタンスタイプです KeyName WebOTX-Key EC2 インスタンス用キーペアの名前です 4. オプション (Options) 何も入力せずに Next をクリックして次の画面に進みます 5. 確認およびスタック作成 (Review) Create をクリックして スタックの作成を開始します スタックの作成には時間がかかることがあります CloudFormation メニューのスタック一覧で Status が CREATE_COMPLETE と表示されれば スタックの作成は完了です 18

19 4.2. 動作確認 提供する CloudFormation テンプレート クックブックから作成されるスタックに含まれる EC2 インスタンスには あらかじめサンプルアプリケーション FindEmployeeWeb が配備されており 以下の手順で動作を確認できます サンプルアプリケーションのクライアントをダウンロード 提供する CloudFormation テンプレートは サンプルアプリケーションの動作確認用のスクリプトファイルのダウンロード URL を保持するように定義されています 以下の手順で URL を確認します 1.CloudFormation メニューのスタック一覧からスタック名が WebOTX-Stack のスタックを選択します 2. Output タブを選択すると OS 別の動作確認用スクリプトのダウンロード URL が表示されます Key: TestScriptForLinux が Linux 用のスクリプト Key: TestScriptForWindows が Windows 用のス クリプトです クライアントマシンの OS を確認した上で 対応スクリプトをダウンロードします Note EC2 インスタンスのパブリック DNS の値はインスタンスを停止するたびに変更されます の手順で確認できる URL は EC2 インスタンスのパブリック DNS を含むので インスタンスの再起動を行った場合は上記の手順では正しい URL を確認できません スタック作成後にインスタンスの再起動を行った場合や でページの表示に失敗する場合は EC2 メニューで対象の EC2 インスタンスを選択して表示されるパブリック DNS を確認して パブリック DNS>/test_linux.sh, パブリック DNS>/test_windows.vbs を URL としてください また ダウンロードしたスクリプトファイルにも URL が記載されていますので こちらも同じように URL を変更してください なお AWS の設定により EC2 インスタンスに静的な DNS を割り当てて 停止してもパブリック DNS を変更しないようにすることも可能です 詳細は下記をご参照ください 動作確認 Linux 環境の場合は test_linux.sh ファイルを Windows 環境の場合は test_windows.vbs ファイルを それぞれダウンロードして実行します スクリプトの実行により以下の結果が出力されることを確認します <?xml version="1.0" encoding="utf-8"?><ns2:opr_09_httpinbound_soapoutbound_002response xmlns:ns2=" xmlns:s=" apoutbound_002response> 以上で動作確認は終了です サンプルアプリケーションに関する詳細は WebOTX マニュアル ( を参照してください 4.3. EC2 インスタンスへの接続 以下では EC2 インスタンスに ssh 接続する方法を説明します WebOTX AS の設定変更などのために EC2 インスタンスに接続する必要がある場合に参照してください 1. セキュリティグループの設定 提供している CloudFormation テンプレートで作成される EC2 インスタンスには 80 番ポート以外へのアク 19

20 セスをブロックするセキュリティグループが設定されています したがって EC2 インスタンスへの接続を行うために 22 番ポートへのアクセスを許可する設定を追加する必要があります 以下の手順で セキュリティグループの設定を変更します 1) EC2 メニューのナビゲーションペインから セキュリティグループ を選択し セキュリティグループの一覧を表示させます 2) 検索ボックスに WebOTX-ESB-Stack-EC2SecurityGroup と入力して検索を行い EC2 インスタンスに設定されているセキュリティグループを表示させます 3) 表示されたセキュリティグループの インバウンド に 22 番ポートへのアクセスを許可する設定を追加します 2.ssh 接続で EC2 インスタンスへ接続します 以下のコマンドを実行して EC2 インスタンスの ec2-user ユー ザにログインします chmod 400 WebOTX-Key.pem ssh -i WebOTX-Key.pem <EC2 インスタンスのパブリック DNS> 20

21 4.4. スタックの削除 以下では 作成したスタックを削除する手順を説明します 1. スタックの削除 1) CloudFormation メニューのスタック一覧で削除するスタックを選択して Delete Stack を押します 2) Delete Stack というウィンドウが表示されますので Yes, Delete を押します 3) スタックの削除が開始されます スタック一覧から対象のスタックが消えればスタックの削除は完了です スタックの削除には時間がかかることがあります 5. 構成のカスタマイズ 5.1. カスタマイズしたクックブックの使用 カスタマイズしたクックブックを使用して EC2 インスタンス上の WebOTX AS の構成を変更する手順を説明します 具体的なクックブックのカスタマイズ方法は 4.2 節 4.3 節をご参照ください クックブックや配備アプリケーションのアップロード 4 章の利用手順では NEC の Web サイト上に公開されているクックブックやウェブアプリケーションを AWS CloudFormation や Chef から HTTP ダウンロードして利用しています ただし 利用者が独自にクックブックをカスタマイズして配備するアプリケーションの変更や WebOTX AS の設定変更を行いたい場合 クックブックやウェブアプリケーションを独自にダウンロード可能な状態にしておき CloudFormation や Chef でそれらをダウンロードする定義を行う必要があります 本節ではカスタマイズしたクックブックや配備アプリケーションをダウンロード可能な状態にする一例として あらかじめ EC2 インスタンス ( 本節では カスタマイズファイル用インスタンス ) を別途作成して Web サーバとして利用する手順を説明します 1. セキュリティグループの作成 提供するサンプルで作成する EC2 インスタンスは デフォルト VPC のサブネットワーク上に作成されます このサンプルによって作成する EC2 インスタンスから HTTP 経由での接続を可能にするため カスタマイズファイル用インスタンスにユーザのデフォルト VPC からの HTTP アクセスのみを許可するセキュリティグループを設定します 1) VPC メニューを選択します 21

22 2) 左ペインの VPC を選択して VPC 一覧を表示させ デフォルト VPC が はい となっている VPC の VPC ID と VPC CIDR の値をメモします 3) EC2 メニューの左ペインから セキュリティグループ を選択し セキュリティグループの作成 を押してセキュリティグループを作成します 4) VPC で 2) で調べた VPC ID を選択します 5) インバウンドルール タブを選択して 編集 を押して 下記 2 件のルールを追加します カスタマイズファイル用インスタンスに ssh 接続する端末から 22 番ポートへのアクセスを許可するルール ポート範囲 に 80 番を 送信元 に 2) で調べた VPC CIDR の値を設定したルール 2. カスタマイズファイル用インスタンス作成 ここでは 公開済みの AMI を利用して 下記の手順でカスタマイズファイル用インスタンスの作成を行います 1) EC2 サービスメニュー左側のナビゲーションペインで AMI を選択し AMI の一覧を表示させます 2) フィルターの 自己所有 を パブリックイメージ に変更します パブリックイメージに変更すると すべての AWS アカウントに公開されている AMI が表示されます 3) 検索ボックスに ami-e1c031e1 を入力して検索を行います 表示される AMI を選択して 作成 ボタンを押します 4) 作成するインスタンスの設定は基本的に規定値を選択します ただし以下の 3 点については設定を行います ステップ 5: インスタンスのタグ付け で キー名 Name に対応する値を Upload-Instance とします ステップ 6: セキュリティグループの設定 で 手順 1 で作成したセキュリティグループを選択します キーペアの選択 で あらかじめ作成しておいた WebOTX-Key を選択します 22

23 Note EC2 インスタンス作成方法の詳細は Amazon Web Services 環境における WebOTX Enterprise Service Bus 導入ガイド (Linux) ( の 2 章を参照し てください 3. ファイルのアップロード 手元のファイルをカスタマイズファイル用インスタンスの /opt/webotx/domains/domain1/docroot 配下にアップロードする手順を示します 1) カスタマイズファイル用インスタンスにファイルをアップロードします ファイル転送はカスタマイズファイル用インスタンスの ec2-user ユーザが行いますので まずは ec2-user ユーザがファイルを追加することができる ec2-user のホームディレクトリ (/home/ec2-user) にファイルをアップロードします 作業環境 ( ローカルマシン ) が Linux の場合 以下のコマンドを実行して ファイルをカスタマイズファイル用インスタンスの /home/ec2-user にファイルを転送します ( 実際には 1 行で実行する ) scp -i WebOTX-Key.pem < ファイル名 > ec2-user@< カスタマイズファイル用インスタンスのパブリック DNS>:~ 23

24 作業環境 ( ローカルマシン ) が Windows の場合 ファイル転送ツールを用いて ファイルをカスタマイズファイル用インスタンスの /home/ec2-user にファイルを転送します Windows の場合 AWS のドキュメントに 一例として WinSCP というツールを使用した Linux インスタンスへのファイルの転送手順が記載されています ( 詳細は本 URL の WinSCP を使用した Linux インスタンスへのファイルの転送 を参照してください 2) カスタマイズファイル用インスタンスに SSH で接続します 接続手順については 4.3 を参照してください 3) 手順 1) で /home/ec2-user にアップロードしたファイルを同じカスタマイズファイル用インスタンスの /opt/webotx/domains/domain1/docroot に移動し 以下のコマンドを実行します /opt/webotx/domains/domain1/docroot へのファイルの追加は root 権限が必要なため sudo コマンドを使って行います sudo mv < コマンドオプション > /home/ec2-user/< ファイル名 > /opt/webotx/domains/domain1/docroot 4. アップロードされたかどうかの確認 1) 以下の手順でファイルのダウンロードが開始されることを確認します 作業環境 ( ローカルマシン ) が Linux の場合 以下のコマンドを実行します curl L カスタマイズファイル用インスタンスのパブリック DNS>/< アップロードしたファイル名 > 作業環境 ( ローカルマシン ) が Windows の場合 ブラウザのアドレスバーに以下を入力します カスタマイズファイル用インスタンスのパブリック DNS>/< アップロードしたファイル名 > 24

25 CloudFormation テンプレートの修正 スタックにアップロードしたクックブックの内容を反映するには スタック作成時に使用する CloudFormation テンプレートを修正する必要があります 本節では CloudFormation テンプレートの修正方法を説明します 修正した CloudFormation テンプレートを利用してスタックを作成する手順は 3 章を参照してください 1. CloudFormation テンプレートのダウンロード 以下の URL から Linux 版の CloudFormation テンプレートをダウンロードします 2. CloudFormation テンプレートの修正 ダウンロードした CloudFormation テンプレートには スタック作成時にクックブックをインターネット上からダウンロードするスクリプトが組まれています スクリプトが記載されている [Resources] -> [WebAPServer] -> [Properties] -> [UserData] 要素を探し スクリプト内のクックブックダウンロード URL を 自身でアップロードしたものに変更してください Linux 版テンプレートのテンプレートについて ダウンロード URL を に変更した場合の CloudFormation テンプレート以下に示します Linux_WebOTX_ESB_On_EC2.template "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [ "#!/bin/bash x n", "cd /root n", "mkdir p cfn_work n", "cd cfn_work n", "exec > >(tee /root/cfn_work/cfn_userdata.log) 2>&1 n", "date n", "curl L bash n", "curl L > cookbooks.zip n", "unzip cookbooks.zip n", 25

26 5.2. 配備するアプリケーションの変更 4 章の手順により作成した EC2 インスタンスには Web アプリケーションのサンプルである FindEmployeeWeb が配備されています 本節では 配備アプリケーションを任意のアプリケーションに変更する方法を説明します 以下の 2 点から CloudFormation テンプレートファイルを編集することで 配備するアプリケーションとサービスアセンブリを変更することができます アプリケーションを配備する処理は webotx-esb-samples クックブックの recipes/default.rb に記載されていますが 配備するアプリケーションの設定情報は全て attributes で定義されています attributes の値は roles/webotx-esb-sample-linux.json ファイルの定義で上書きできます 配備するアプリケーションを変更する CloudFormation テンプレートの編集後の例は以下のとおりです Linux_WebOTX_ESB_On_EC2.template "unzip cookbooks.zip n", "cat <<EOF > roles/webotx esb sample linux.json n", "{ n", " "name ": "webotx esb sample linux ", n", " "default_attributes ": { }, n", " "override_attributes ": { n", " "apps " : { n", " "list ": [ "app1 ", "app2 "] n", " }, n", " "app1 " : { n", " "url ": " studio/dev_devstudio_esb/4.1_sample01/01_soapservice.war " n", " }, n", " "app2 " : { n", " "url ": " studio/dev_devstudio_esb/4.10_sample10/10_http_outbound_servlet.war " n", " }, n", " "esb_apps " : { n", " "list ": [ "esb_app1 ", "esb_app2 "] n", " }, n", " "esb_app1 " : { n", " "url ": " studio/dev_devstudio_esb/4.1_sample01/01_file_xslt_soap.zip " n", " }, n", " "esb_app2 " : { n", " "url ": " studio/dev_devstudio_esb/4.10_sample10/10_soapinbound_httpoutbound.zip " n", " } n", " }, n", " "json_class ": "Chef::Role ", n", " "description ": "This is just a sample role. ", n", " "chef_type ": "role ", n", " "run_list ": [ n", " "recipe[webotx esb sample::linux] " n", " ] n", "} n", "EOF n", "chef client z c solo.rb j init linux.json n", 26

27 この CloudFormation テンプレートでは EC2 インスタンスの初回起動時に roles/webotx-esb-sample-linux.json を生成しています CloudFormation テンプレートが生成する webotx-esb-sample-linux.json は以下のようになります roles/webotx-esb-sample-linux.json { "name": "webotx esb sample linux", "default_attributes": { }, "override_attributes": { "apps" : { "list": ["app1", "app2"] }, "app1" : { "url":" esb/4.1_sample01/01_soapservice.war" }, "app2" : { "url":" esb/4.10_sample10/10_http_outbound_servlet.war" }, "esb_apps" : { "list": ["esb_app1", "esb_app2"] }, "esb_app1" : { "url":" esb/4.1_sample01/01_file_xslt_soap.zip" }, "esb_app2" : { "url":" esb/4.10_sample10/10_soapinbound_httpoutbound.zip" } }, "json_class": "Chef::Role", "description": "This is just a sample role.", "chef_type": "role", "run_list": [ "recipe[webotx esb sample::linux]" ] } 上記の例では配備するアプリケーションの設定を override_attributes >apps >list と override_attribute >app1, override_attributes >app2 に記述します また 配備するサービスアセンブリの設定を override_attributes >esb_apps >list と override_attribute >esb_app1, override_attributes >esb_app2 に記述します 各属性の詳細を以下の表に示します 要素名 override_attributes >apps >list override_attributes >esb_apps >list override_attributes >* 説明 配備するアプリケーションの一覧を定義する属性です 配備するサービスアセンブリの一覧を定義する属性です 配備するアプリケーションに関する情報を定義する属性です 具体的な情報 ( 配備するアプリケーションの取得元の URL) はこの属性の子要素に定義します この属性の名前は override_attributes->apps->list で定義した要素に一致させる必要があります 27

28 override_attributes >* >url 配備するアプリケーションの取得元の URL です 従って 上記の記入例の場合は WebOTX のマニュアルサイトから 2 つのサンプルアプリケーション 01_SoapService.war 10_http_outbound_servlet.war と 2 つのサービスアセンブリ 01_File_XSLT_SOAP.zip 10_SoapInbound_HttpOutbound.zip をそれぞれダウンロードして ドメインに配備します 28

29 5.3. WebOTX AS/ESB のチューニング 本章ではクックブックのカスタマイズによる WebOTX ESB のチューニング方法を説明します otxadmin set サブコマンドによるチューニング WebOTX AS では自身の設定情報を変更して チューニングを行うための機能として otxadmin set コマンドが用意されています 例えば otxadmin set コマンドを使用してドメインの最大ヒープメモリサイズを 768M バイトに変更する場合 次のように実行します otxadmin set -u admin -w adminadmin server.java-config.max-heap-size=768m 最大ヒープメモリサイズの設定反映には ドメインの再起動が必要です -u はドメインの管理ユーザ名を指定するオプション -w は管理ユーザのパスワードを指定するオプション -u と -w は set コマンドを行う際の必須オプションです また server.java-config.max-heap-size はドメインのヒープサイズを指定する MO 属性です 属性名の調査方法は 節を参照してください otxadmin set コマンドの操作も Chef の execute リソースを使用してレシピに定義することができます 以下にレシピの記入例を示します cookbooks/webotx-esb-sample/recipes/linux.rb execute "set max heap size" do action :run command << EOH #{node['webotx']['otxadmin']} set u admin w adminadmin server.java config.max heap size=768m EOH end 上記のレシピの #{node['webotx']['otxadmin']} は otxadmin コマンドの実行パスを示す変数です attributes として下記のように定義されており Windows OS では otxadmin に それ以外の OS では /opt/webotx/bin/otxadmin に置換されます cookbooks/webotx-esb-sample/attributes/default.rb case node["platform"] when "windows" default['webotx']['installdir'] = "#{ENV['SYSTEMDRIVE']} WebOTX" default['webotx']['otxadmin'] = "otxadmin" else default['webotx']['installdir'] = "/opt/webotx" default['webotx']['otxadmin'] = "#{default['webotx']['installdir']}/bin/otxadmin" end otxadmin set コマンドで行う設定の一部には 設定を反映するためにドメインの再起動を必要とするものがあります そのため レシピでチューニングを行う際には otxadmin set コマンド実行後にドメインの再起動を行うように定義してください ドメインの再起動を行う execute リソースは以下になります 29

30 cookbooks/webotx-sample/recipes/windows.rb # Restarts "domain1". execute "stop_domain1" do action :run command << EOH #{node['webotx']['otxadmin']} stop domain domain1 EOH end execute "start_domain1" do action :run command << EOH #{node['webotx']['otxadmin']} start domain domain1 EOH notifies :run, "execute[wait startup]", :immediately end Note 本節で紹介した otxadmin コマンドについての詳細は WebOTX のマニュアルを参照下さい - Application Server - リファレンス集運用管理 設定編 - 4. 運用管理コマンドリファレンス Note 本節で紹介した execute リソースと service リソースについての詳細は Chef の Web ドキュメントを参照下さい - execute リソース - service リソース MO 属性名の調査方法 otxadmin set コマンドを使用してレシピから WebOTX AS のチューニングを行う場合 チューニング対象となる MO 属性名を明らかにする必要があります 本節では WebOTX 統合運用管理コンソールから任意の設定属性の MO 属性名を調べる方法を説明します ESB の MO 属性名の調査方法 ESB ではマニュアルに操作可能な MO 属性の一覧を記載しています Web ブラウザで にアクセスし 設定をしたい項目の MO 属性名と設定可能な値を調べてください AS の MO 属性名の調査方法 1. 設定項目の調査 ローカルマシンの Web ブラウザから インスタンスのパブリック DNS>:5858/manager にアクセスし WebOTX 統合運用管理コンソール上で設定を変更したい項目を調査します 5858 ポートで接続するので 接続の前にセキュリティグループや OS のファイアウォール設定で 5858 ポートへの接続を許可して下さい セキュリティグループの設定変更方法は 3.3 節の手順 1 を参照してください 今回は例としてドメイン名 ( 既定値は domain1)>> アプリケーションサーバ >>WebServer の 最大同時接続 30

31 数 [1-4096] をチューニングの対象とします 2.MO の DottedName の調査 チューニングしたい属性が決まったら WebOTX マニュアルで属性の MO 名を調べます にアクセスしマニュアルを開き Application Server > リファレンス集運用管理 設定編 > 2. MO 定義リファレンス > 2.3. 統合運用管理ツールの表示から検索 を開きます WebOTX 統合運用管理コンソール上の表示に対応して MO の DottedName の一覧が表示されますので 設定したい項目に対応する DottedName を調べます 本例の場合は WebServer に対応する server.webserver が MO の DottedName になります 31

32 32

33 3.MO の属性名の調査 調査対象の設定項目の DottedName が判明したら MO の属性名を調べます マニュアルページで設定したい項目に対応する Type 名を選択します 項目で設定可能な MO 属性の一覧が表示されますので 設定対象の属性をページ内から探し その属性名を調べます MO 属性名は 以上の作業により取得した値を合わせた < 手順 2 で調べた DottedName>.< 手順 3 で調べた属性名 > となります 今回の例の場合 WebServer の最大同時接続数を設定する MO 属性の属性名は MaxClients ですので 手順 2 で調べた DottedName と合わせて server.webserver.maxclients が MO 属性名になります 33