Amazon Web Services環境におけるWebOTX Application Server導入ガイド (Windows)

Transcription

1 Amazon Web Services 環境における AWS CloudFormation と Chef を用いた WebOTX Application Server 環境構築ガイド (Linux 版 ) 2017 年 4 月 第 5 版 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. はじめに 対象読者と目的 用語一覧 最新情報の入手先 お問い合わせ方法 概要 AWS CloudFormation の概要 Chef の概要 WebOTX AS 環境構築のための AWS CloudFormation / Chef サンプル 利用手順 CloudFormation と Chef によるスタック作成手順 動作確認 EC2 インスタンスへの接続 スタックの削除 構成のカスタマイズ カスタマイズしたクックブックの使用 配備するアプリケーションの変更 WebOTX AS のチューニング

4 1. はじめに 1.1. 対象読者と目的 本書では Amazon Web Services( 以下 AWS) 上に WebOTX Application Server Express V9.2 と Amazon RDS for PostgreSQL を利用した人事管理のサンプルシステムを AWS CloudFormation と Chef を使用して構築する方法を説明します また 本書と合わせて提供している AWS CloudFormation テンプレートと Chef のレシピ ( 以後 レシピ ) のサンプルのカスタマイズ方法を解説します 本書を理解することで AWS 上に用途に応じた任意の構成のシステムを構築する方法を習得することができます 3. 利用手順 までの対象読者は 以下に該当する方です EC2 インスタンスの前提知識を有しており かつ以下の権限が与えられている IAM ユーザ AWS Management Console にログインする権限が与えられている EC2 インスタンスを生成する権限が与えられている 4. 構成のカスタマイズ 以降の対象読者は以下に該当し システム構成やパラメータ アプリケーションを変更し 任意の構成のシステムを構築する方法を習得する必要がある方です JSON Ruby の記述方法を習得している もしくはマニュアルなどを参照して理解することができる スタックに追加する AWS サービスの基本的な知識を有している もしくはマニュアルなどを参照して理解することができる アプリケーションサーバや OSS に関する基本的な知識を有している もしくはマニュアルなどを参照して理解することができる WebOTX AS の運用管理コマンドを使うことができる もしくはマニュアルなどを参照して理解することができる 1.2. 用語一覧 AWS の用語一覧 詳細は AWS の Web サイト ( を参照してください 用語 AWS Management Console Amazon EC2 EC2 インスタンス AMI キーペア AWS RDS RDS インスタンス AWS S3 Amazon VPC バケットセキュリティグループ 説明 ウェブベースのユーザインターフェイスで AWS にアクセスして管理するコンソールです Amazon が提供する計算資源を用いてアプリケーションを実行する商用ウェブサービスです OS がセットアップされた AWS 上の仮想サーバです Amazon Machine Image の略で ソフトウェア構成 (OS アプリケーションサーバ アプリケーションなど ) を記録したテンプレートです AMI から AMI のコピーである EC2 インスタンスを起動します Amazon EC2 はパブリックキー暗号を使用して ログイン情報の暗号化と復号化を行います パブリックキー暗号は パブリックキーを使用してパスワードなどのデータを暗号化し 受信者はプライベートキーを使用してデータを復号化します パブリックキーとプライベートキーは キーペアと呼ばれます EC2 インスタンスにログインするには キーペアを作成し EC2 インスタンスを起動するときにキーペアの名前を指定して EC2 インスタンスに接続するときにプライベートキーを指定する必要があります AWS でのリレーショナルデータベースのセットアップ 運用 およびスケーリングを容易に行えるようにするサービスです リレーショナルデータベースがセットアップされた AWS 上の仮想サーバです AWS で提供されているストレージサービスです AWS が提供する仮想ネットワークサービスです 独自の VPC を定義して 各環境を分離したネットワーク上に配置することが出来ます S3 に格納されるオブジェクト ( ファイル ) のコンテナです すべてのオブジェクトはバケット内に格納されます AWS 上の EC2 インスタンス RDS インスタンスのアクセスを制御するファイアウォールです 4

5 WebOTX Application Server の用語一覧 用語 ドメイン 説明 WebOTX Application Server の基本的な構成単位をドメインと呼びます ドメインは WebOTX Application Server で管理するリソースやサービス群を論理的にグルーピングしています ドメインは独立して運用され コンフィグレーション情報など構成情報はドメイン単位で独立したディレクトリに管理されます その他の用語については WebOTX マニュアル ( の用語集 ( を参照してください AWS CloudFormation の用語一覧 詳細は AWS CloudFormation の Web サイト ( を参照してください 用語 スタック テンプレート 説明 AWS サービスの集合のことをスタックといいます AWS CloudFormation ではスタック単位で AWS サービスの集合を管理します 例えば スタックの破棄を実行すると スタックに紐づくすべてのリソースが破棄されます スタックの構成を JSON 形式で記述したものです AWS CloudFormation ではテンプレートの内容を元にスタックを構築します Chef の用語一覧 詳細は Chef の Web サイト ( を参照してください 用語 クックブック レシピ 説明 Chef によるサーバインフラストラクチャの情報をまとめた単位です クックブックは必ず目的を持ち ( 例えば MySQL をインストールして利用可能な状態にするなど ) その目的を達成するために必要なレシピや属性ファイルなどを持ちます クックブックを構成する要素の 1 つで 開発やテストで構築するサーバのインフラストラクチャのあるべき姿を定義した仕様書です Chef はレシピの定義に従ってインフラストラクチャの構築を行います レシピの定義は Ruby の文法で記述します 1.3. 最新情報の入手先 最新の製品情報については 以下の Web サイトを参照ください お問い合わせ方法 本ガイド記載事項における各種問い合わせにつきましては 以下のメールアドレスへ電子メールでお問い合わせください info-webotx@isd.jp.nec.com 5

6 2. 概要 2.1. AWS CloudFormation の概要 AWS CloudFormation とは AWS CloudFormation( 以下 CloudFormation) とは AWS サービスを組み合わせたスタックの構成を JSON 形式で記述して その構成の作成 管理を容易にする AWS のサービスです ユーザは独自のテンプレートを作成して自由なスタック構築を行うことが可能です あるいは CloudFormation で既に用意されているサンプルテンプレートを利用してスタック構築を行うことも可能です CloudFormation は追加料金なし (2016 年 3 月時点 ) で利用でき テンプレートに従って構築された各 AWS サービスに対しての課金のみが発生します CloudFormation の主な特長は以下です 容易な環境構築が可能テンプレートを作成しておけば 短時間でスタックを構築できます 起動時にパラメータを渡すことができるので さまざまな設定値によるスタックを単一のテンプレートで行うことが可能です また反対に パラメータを変更しなければ 同様のスタックを繰り返し構築することができます 一般的な形式によるテンプレート記述が可能 CloudFormation テンプレートは JSON 形式のテキストファイルです リソースの調査が可能 CloudFormation にテンプレートのコピーが保持されるので スタック作成時に適用した正確なリソース設定を必要に応じて見返すことができます 2.2. Chef の概要 Chef とは 本ドキュメントでは構成管理ツール Chef を用いて WebOTX AS の設定を行う方法を紹介します Chef は AWS インスタンス起動時に自動で実行されますので 試しに環境設定済みの WebOTX AS を AWS インスタンス上で操作してみたい方は Chef の存在を意識する必要はありません しかし Chef を使って WebOTX AS の設定変更を行いたい場合は本章の内容を理解しておく必要があります 本章は Chef を使用したことがないという方を対象に Chef とは何か 何が出来るのか どのような用途で使用するのかを説明します Chef はサーバインフラストラクチャを自動で構築してくれるソフトウェアです ここでいう環境にハードウェアは含まれません あくまでソフトウェアやファイル ネットワーク設定などの OS 上の環境構築を行います Chef ではサーバインフラストラクチャの構築に環境情報を記述したコードを用います インフラストラクチャのあるべき状態をコードで定義しておけば そのコードが表す状態のサーバ設定を Chef コマンドひとつで作成することができます 例えば Chef を使って nginx のような Web サーバと PostgreSQL のような RDBMS がインストールされて そこに Web ページが配備された環境を作ることができます また よりプライベートな使い道として よく使用するアプリケーションを定義しておき PC をリプレースする際にそれらを一括でインストールすることもできます これにより 今まで手作業で行っていた環境構築作業を短時間でより正確に実施することができます 6

7 Chef ソフトウェア体系 Chef は Chef 社 ( 旧名 Opscode 社 ) が開発し 2009 年に初めて発表しました その後 Chef の開発は継続的に進められ 2016 年 3 月現在 Chef 社は Chef の名を冠した製品を複数リリースしています それぞれどのような製品なのかを簡単に紹介します ソフトウェア Chef Client Chef Server Chef Development Kit 説明 最も基本的な Chef 製品です クックブックを実行してローカルマシンに開発やテストで作成するサーバのインフラストラクチャを構築します その名の通りクライアントとして動作し Chef Client をインストールした複数のマシンを 1 台の Chef Server インストールマシンから管理することができます また Chef Server と連携せずに単体で使用することもできます Chef Client をインストールしたマシンを管理するソフトウェアです マシンを複数台使用するシステムにおけるサーバの構築に使用します Chef Server を使用する場合には Chef Server をインストールする専用サーバマシンが必要になります そのためマシン台数が十台を超える大規模なシステム開発で使用されることが多いです Chef のクックブック作成に有用な開発者用のツールをまとめたパッケージです これらのソフトウェアは 2016 年 3 月現在 以下のページから入手が可能です なお 本ドキュメントでは Chef Client のみを使用します 2.3. WebOTX AS 環境構築のための AWS CloudFormation / Chef サンプル AWS CloudFormation / Chef サンプル提供の背景 近年 クラウドコンピューティングサービスとして AWS が急速な普及を進めています また Chef も近年の開発プロセスの変化に伴い 開発者の間で急速な広まりを見せています 開発プロセスの一例としてアジャイル型開発技法を挙げると アジャイル型開発技法では計画 設計 実装 テストを細かく分割して繰り返し実行するのですが テストを行うための環境を構築する作業を繰り返し行う必要があり これが開発の負担になってしまいます この問題を AWS CloudFormation と Chef を活用することで 解決することができます CloudFormation を用いることで テンプレートから AWS のスタックを短時間で作成することができ これに加えて Chef を用いることで OS 上のテスト環境を短時間で作成することができます しかもソフトウェアによる環境構築なので 手作業での環境構築と比較しヒューマンエラーを軽減することができます このように 開発プロセスの変化に伴い CloudFormation や Chef の重要性が増してきています 開発プロセスの変化に柔軟に対応するため CloudFormation と Chef を用いて AWS 上に WebOTX AS の環境を構築するためのサンプルを提供します 7

8 WebOTX AS 環境構築サンプル構成 提供する CloudFormation テンプレートからのスタック作成動作について簡単に説明します [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] RDS インスタンス作成 起動 PostgreSQL がセットアップされた RDS インスタンス ( 図中 PostgreSQL) の作成と起動を行います [B-3] セキュリティグループ設定 EC2 インスタンス RDS インスタンスへのアクセスを制御するファイアウォールであるセキュリティグループは EC2 インスタンスには EC2SecurityGroup RDS インスタンスには RDSSecurityGroup と それぞれ異なるものが設定されます また アプリケーションは EC2 インスタンス上で動作するため アプリケーション利用ユーザは EC2 インスタンスへのアクセスは許可されていますが RDS インスタンスへの直接のアクセスは許可されていません 8

9 [B-4] クックブックのダウンロードと Chef-Solo 実行 Chef のクックブックをダウンロードして Chef-Solo コマンドを 1) で作成した EC2 インスタンス上で実行します Chef-Solo コマンドはクックブックをクライアント上で実行する Chef Client のコマンドです Chef-Solo 実行により クックブックに定義されている下記の手順 C) の処理が実行されます [C] Chef がアプリケーション動作環境の設定 構築 [C-1] サンプルアプリケーションのダウンロードと配備 [C-2] RDS に対して サンプルアプリケーション用のテーブル作成とデータ挿入 作成されるスタックの構成を以下に示します スタック情報 EC2 インスタンス ( 図中 EC2 Instance) RDS インスタンス ( 図中 PostgreSQL) EC2SecurityGroup RDSSecurityGroup 補足 WebOTX Application Server V9.2 Express がインストールされています Chef Client がインストールされており chef-solo の実行により WebOTX AS の設定とサンプルアプリケーション FindEmployeeWeb の配備が実施された状態です EC2SecurityGroup が設定されています PostgreSQL のデータベースがセットアップされており サンプルアプリケーション FindEmployeeWeb で使用するテーブルが作成され 必要なデータが挿入されています RDSSecurityGroup が設定されています 80 番ポート (HTTP) へのアクセスのみを許可しています EC2SecurityGroup が設定されているインスタンスからの 5432 番ポートへのアクセスのみを許可しています EC2 に設定されている EC2SecurityGroup が 80 番ポート以外のアクセスを許可していないので EC2 インスタンスに SSH 接続する場合は 3.3 EC2 インスタンスへの接続 を参照してください 本スタックに含まれる EC2 インスタンスには EC2SecurityGroup が RDS インスタンスには RDSSecurityGroup が設定されているので EC2 インスタンスから RDS インスタンスの 5432 番ポートへのアクセスが可能です 同様に 利用者が作成したインスタンス (AWS 上の仮想サーバ ) に対して RDSSecurityGroup を設定すると 作成したインスタンスから RDS の 5432 番ポートへのアクセスが許可されるのでご注意ください 9

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

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

12 3.2. 動作確認 提供する CloudFormation テンプレート クックブックから作成されるスタックに含まれる EC2 インスタンスには あらかじめサンプルアプリケーション FindEmployeeWeb が配備されており 以下の手順で動作を確認できます サンプルアプリケーションの URL 確認 提供する CloudFormation テンプレートは サンプルアプリケーションの URL を保持するように定義されています 以下の手順で URL を確認します 1.CloudFormation メニューのスタック一覧からスタック名が WebOTX-Stack のスタックを選択します 2. Output タブを選択します Key: WebsiteURL に対応する値を確認します Note EC2 インスタンスの Public DNS の値はインスタンスを停止するたびに変更されます の手順で確認できる URL は EC2 インスタンスの Public DNS を含むので インスタンスの再起動を行った場合は上記の手順では正しい URL を確認できません スタック作成後にインスタンスの再起動を行った場合や でページの表示に失敗する場合は EC2 メニューで対象の EC2 インスタンスを選択して表示される Public DNS を確認して DNS>/FindEmployeeWeb を URL としてください 設定により EC2 インスタンスに静的な DNS を割り当てて 停止しても Public DNS を変更しないようにすることも可能です 詳細は下記をご参照ください 動作確認 ブラウザを開き アドレスバーに で確認した URL を入力します [ 人事管理システム ] 画面が表示されます 例として 各項目に以下の値を設定し 検索 を押します 検索キー : 開発部 検索条件 : 部署 ( 完全一致 ) 12

13 以下のように表示されることを確認してください 以上で動作確認は終了です サンプルアプリケーションがうまく動作しない場合は WebOTX マニュアル ( のスタートアップガイド ( の [ 動作しない場合の確認項目 ] を参照してください 3.3. EC2 インスタンスへの接続 以下では EC2 インスタンスに ssh 接続する方法を説明します WebOTX AS の設定変更などのために EC2 インスタンスに接続する必要がある場合に参照してください 1. セキュリティグループの設定 提供している CloudFormation テンプレートで作成される EC2 インスタンスには 80 番ポート以外へのアクセスをブロックするセキュリティグループが設定されています したがって EC2 インスタンスへの接続を行うために 22 番ポートへのアクセスを許可する設定を追加する必要があります 以下の手順で セキュリティグループの設定を変更します 1) EC2 メニューのナビゲーションペインから Security Groups を選択し セキュリティグループの一覧を表示させます 2) 検索ボックスに WebOTX-Stack-EC2SecurityGroup と入力して検索を行い EC2 インスタンスに設定されているセキュリティグループを表示させます 3) 表示されたセキュリティグループの Inbound に 22 番ポートへのアクセスを許可する設定を追加します 2.ssh 接続で EC2 インスタンスへ接続します 以下のコマンドを実行して EC2 インスタンスの ec2-user ユー ザにログインします chmod 400 WebOTX-Key.pem ssh WebOTX-Key.pem <EC2 インスタンスの Public DNS> 13

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

15 2) 左ペインの Your VPCs を選択して VPC 一覧を表示させ Default VPC が Yes である VPC の VPC ID と VPC CIDR の値をメモします 3) EC2 メニューの左ペインから Security Groups を選択し Create Security Group を押してセキュリティグループを作成します 4) VPC で 2) で調べた VPC ID を選択します 5) Inbound タブを選択して Add Rule を押して 下記 2 件のルールを追加します Create を押してセキュリティグループを作成します カスタマイズファイル用インスタンスに ssh 接続する端末から 22 番ポートへのアクセスを許可するルール Port Range に 80 番を Source に 2) で調べた VPC CIDR の値を設定したルール 2. カスタマイズファイル用インスタンス作成 ここでは 公開済みの AMI を利用して 下記の手順でカスタマイズファイル用インスタンスの作成を行います 1) EC2 サービスメニュー左側のナビゲーションペインで [AMIs] を選択し AMI の一覧を表示させます 2) Filter の Owned by me を Public images に変更します Public images に変更すると すべての AWS アカウントに公開されている AMI が表示されます 3) 検索ボックスに ami-f3bb9a94 を入力して検索を行います 表示される AMI を選択して Launch ボタンを押します 4) 作成するインスタンスの設定は基本的に規定値を選択します ただし以下の 3 点については設定を行います Step 5: Tag Instance で Key 名 Name に対応する Value の値を Upload-Instance とします Step 6: Configure Security Group で 手順 1 で作成したセキュリティグループを選択します Select a key pair で あらかじめ作成しておいた WebOTX-Key を選択します Note EC2 インスタンス作成方法の詳細は Amazon Web Services 環境における WebOTX Application Server 導入ガイド (Linux) ( の 2 章を参照し てください 3. ファイルのアップロード 手元のファイルをカスタマイズファイル用インスタンスの /opt/webotx/domains/domain1/docroot 配下にアップロードする手順を示します 1) カスタマイズファイル用インスタンスにファイルをアップロードします ファイル転送はカスタマイズファイル用インスタンスの ec2-user ユーザが行いますので まずは ec2-user ユーザがファイルを追加することができる ec2-user のホームディレクトリ (/home/ec2-user) にファイルをアップロードします 作業環境 ( ローカルマシン ) が Linux の場合 以下のコマンドを実行して ファイルをカスタマイズファイル用インスタンスの /home/ec2-user にファイルを転送します scp i WebOTX-Key.pem < ファイル名 > < カスタマイズファイル用インスタンスの Public DNS>:~ 15

16 作業環境 ( ローカルマシン ) が Windows の場合 ファイル転送ツールを用いて ファイルをカスタマイズファイル用インスタンスの /home/ec2-user にファイルを転送します Windows の場合 AWS のドキュメントに 一例として WinSCP というツールを使用した Linux インスタンスへのファイルの転送手順が記載されています ( 詳細は本 URL の WinSCP を使用した Linux インスタンスへのファイルの転送 を参照してください 2) カスタマイズファイル用インスタンスに SSH で接続します 接続手順については 3.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 カスタマイズファイル用インスタンスの Public DNS>/< アップロードしたファイル名 > 作業環境 ( ローカルマシン ) が Windows の場合 ブラウザのアドレスバーに以下を入力します カスタマイズファイル用インスタンスの Public DNS>/< アップロードしたファイル名 > 16

17 CloudFormation テンプレートの修正 スタックにアップロードしたクックブックの内容を反映するには スタック作成時に使用する CloudFormation テンプレートを修正する必要があります 本節では CloudFormation テンプレートの修正方法を説明します 修正した CloudFormation テンプレートを利用してスタックを作成する手順は 3 章を参照してください 1. CloudFormation テンプレートのダウンロード 以下の URL から CloudFormation テンプレートをダウンロードします 2. CloudFormation テンプレートの修正 ダウンロードした CloudFormation テンプレートには スタック作成時にクックブックをインターネット上からダウンロードするスクリプトが組まれています スクリプトが記載されている [Resources] -> [WebAPServer] -> [Properties] -> [UserData] 要素を探し スクリプト内のクックブックダウンロード URL を 自身でアップロードしたものに変更してください Linux 版テンプレートと Windows 版テンプレートのそれぞれについて ダウンロード URL を に変更した場合の CloudFormation テンプレート以下に示します Linux_WebOTX_AS_Exp_On_EC2_And_RDS.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", 17

18 4.2. 配備するアプリケーションの変更 3 章の手順により作成した EC2 インスタンスには Web アプリケーションのサンプルである FindEmployeeWeb が配備されています 本節では 配備アプリケーションを任意のアプリケーションに変更する方法を説明します 以下の 3 点から CloudFormation テンプレートファイルを編集することで配備するアプリケーションを変更することができます アプリケーションを配備する処理は webotx-samples クックブックの recipes/default.rb に記載されていますが 配備するアプリケーションの設定情報は全て attributes で定義されています attributes の値は roles/webotx-as-sample-windows.json ファイルの定義で上書きできます のカスタマイズ手順で使用する CloudFormation テンプレート (4.1.2 節参照 ) では Chef レシピに RDS インスタンスへの接続情報を渡すために roles/webotx-as-sample-linux.json ファイルを作成します 配備するアプリケーションを変更する CloudFormation テンプレートの編集後の例は以下のとおりです Linux_WebOTX_AS_Exp_On_EC2_And_RDS.template "cat <<EOF > roles/webotx-as-sample-linux.json n", "{ n", " "name ": "webotx-as-sample-linux ", n", " "default_attributes ": { }, n", " "override_attributes ": { n", " "db " : { n", " "user ": "", { "Ref" : "DBUser" }, " ", n", " "password ": "", { "Ref" : "DBPassword" }, " ", n", " "url ": "jdbc:postgresql://", { "Fn::GetAtt" : [ "DBInstance", "Endpoint.Address" ]}, ":", { "Fn::GetAtt" : [ "DBInstance", "Endpoint.Port" ]}, "/", { "Ref" : "DBName" }, " " n", " }, n", " "apps " : { n", " "list ": [ "app1 ", "app2 "] n", " }, n", " "app1 " : { n", " "url ": " 0_webdk_sample/FileUploadSample.war " n", " }, n", " "app2 " : { n", " "url ": " _webdk_sample/jta-sample.war " 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-sample::linux] " n", " ] n", "} n", "EOF n", 18

19 この CloudFormation テンプレートでは EC2 インスタンスの初回起動時に roles/webotx-as-sample-linux.json を生成しています CloudFormation テンプレートが生成する webotx-as-sample-linux.json は以下のようになります roles/webotx-as-sample-linux.json { "name": "webotx-as-sample-linux", "default_attributes": { }, "override_attributes": { "db" : { "user": ( スタック作成時に入力する DBUser の値 ), "password": ( スタック作成時に入力する DBPassword の値 ), "url": (RDS への接続 URL) }, "apps" : { "list": ["app1", "app2"] }, "app1" : { "url":" }, "app2" : { "url":" } }, "json_class": "Chef::Role", "description": "This is just a sample role.", "chef_type": "role", "run_list": [ "recipe[webotx-sample::linux]" ] } 配備するアプリケーションの設定は override_attributes->apps->list と override_attribute->app1, override_attributes->app2 に記述します app1 app2 の要素名は override_attributes->apps->list に定義した属性の値と一致しており 任意の名前を設定可能です 各属性の詳細を以下の表に示します 要素名 override_attributes ->apps ->list override_attributes ->* override_attributes ->* ->url 説明 配備するアプリケーションの一覧を定義する属性です 配備するアプリケーションに関する情報を定義する属性です 具体的な情報 ( 配備するアプリケーションの取得元の URL) はこの属性の子要素に定義します この属性の名前は override_attributes->apps->list で定義した要素に一致させる必要があります 配備するアプリケーションの取得元の URL です 従って 上記の記入例の場合は WebOTX のマニュアルサイトから 2 つのサンプルアプリケーション FileUploadSample.war と jta-sample.war をダウンロードして ドメインに配備します 19

20 4.3. WebOTX AS のチューニング 本章ではクックブックのカスタマイズによる WebOTX AS のチューニング方法を説明します 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-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-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 リソースを記述していますので その execute リソースより手前の位置に otxadmin set コマンドを実行する execute リソースすることを推奨します 20

21 Note 本節で紹介した otxadmin コマンドについての詳細は WebOTX のマニュアルを参照下さい - Application Server - リファレンス集運用管理 設定編 - 4. 運用管理コマンドリファレンス Note 本節で紹介した execute リソースと service リソースについての詳細は Chef の Web ドキュメントを参照下さい - execute リソース - service リソース MO 属性名の調査方法 otxadmin set コマンドを使用してレシピから WebOTX AS のチューニングを行う場合 チューニング対象となる MO 属性名を明らかにする必要があります 本節では WebOTX 統合運用管理コンソールから任意の設定属性の MO 属性名を調べる方法を説明します 1. 設定項目の調査 ローカルマシンの Web ブラウザから インスタンスの Public DNS>:5858/manager にアクセスし WebOTX 統合運用管理コンソール上で設定を変更したい項目を調査します 5858 ポートで接続するので 接続の前にセキュリティグループや OS のファイアウォール設定で 5858 ポートへの接続を許可して下さい セキュリティグループの設定変更方法は 3.3 節の手順 1 を参照してください 今回は例としてドメイン名 ( 既定値は domain1)>> アプリケーションサーバ >>WebServer の 最大同時接続数 [1-4096] をチューニングの対象とします 21

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

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