Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

27.3. 拡張例： アプリケーションを JBoss EAP サーバーへのプロビジョニング（計画）

設定

Tim the IT Guy at Example Co. は、Example のオンライン帯域管理アプリケーションである──App の完全なアプリケーションライフサイクルを管理する必要があります。QA には 2 つの環境があり、もう 1 つはライブサイト用です。どちらの環境にも、Windows サーバーと Linux サーバーが混在しています。

Tim は、開発の GIT リポジトリーで最新のビルドに基づいて、週に最新の開発バージョンを QA 環境にデプロイすることを希望しています。静的パッケージに基づいて、最も安定したバージョンのアプリケーションを実稼働環境にデプロイすることを希望します。

操作方法

Tim にとって最適な計画は、自分の理想的な QA と実稼働環境の設定を希望する方法から、後方作業を行うことです。

Tim の最初のステップは、その環境に基づいて目的のある目的を特定することです。2 つの環境があるため、独立したグループを 2 つ作成します。1 つ目は QA と実稼働環境用です。✓App は JBoss サーバー上で実行されるため、プラットフォームではなく JBoss AS/EAP リソース用の互換性のあるグループになります。
また、各環境に対するニーズは異なります。
  • QA 環境が必要...
    • 新規ビルドは、週ごとに GIT リポジトリーから直接作成します。
    • すべてのデプロイメントから開始する完全にクリーンなディレクトリー。
    • サンプル Co. の web アプリケーションにはそれぞれ個別の QA 環境があるため、特定のサーバーで実行している唯一のアプリケーションになります。
  • 実稼働環境では必要なもの
    • JBoss ON で安全に保存できる安定したビルド。
    • 履歴データを保存するには、以下を実行します。実稼働環境には、ログディレクトリーとユーザー提供のデータディレクトリーの両方があり、アプリケーションのアップグレード後も維持する必要があります。
    • 同じ実稼働サーバーで複数の異なる Web アプリケーションが実行されます。
アプリケーション自体は両方の環境で同じです。インスタンス固有の設定（ポート番号、アプリケーション名、マシン IP アドレス）は、アプリケーションがデプロイされる際に有効なトークンに基づいています。バンドルに含まれる JAR ファイルは、アプリケーションがデプロイされるときに抽出する必要があります。ただし、ローカルにインストールするか、または起動できるクライアントが 1 つのクライアントを除きます。
Tim は、同じバンドルの異なるバージョンを使用することを決定し、QA バージョンに devel と production バージョンのラベルを付け ます。
devel と安定したバンドルレシピにはいくつかの類似点があります。
  • deploy/ ディレクトリーにデプロイする必要がありますが、実行するアプリケーションではないので、独自の webapp コンテキストサブディレクトリーを持ちます。これは、devel 環境では必須ではありませんが（⋮App が唯一のアプリケーションである場合）、最終的なデプロイメント先との一貫性を維持します。
  • どちらのレシピも MusicApp.jar、アプリケーション JAR ファイルのデプロイ時に展開されるように設定します。
  • クライアントアーカイブファイルは展開さ MyMusic.jarれません(<rhq:file ... exploded="false">)。
  • トークンは、raw 設定ファイルとポート番号、IP アドレス、およびアプリケーション名のレシピで定義されます。
また、レシピには、devel および stable のバージョンが既存のファイルを処理する方法との違いがあります。
  • QA 環境には、常にプルーニングのデプロイメントが必要です。これには 3 つの設定が必要です。
    • この compliance 値は常に 満杯 になるため、初回のデプロイメント時に既存のファイルは保持されません。
    • <rhq:ignore> 要素は設定されないため、アップグレード中に生成されたファイルは保持されません。
    • cleanDeployment オプションは、デプロイメントを自動化する JBoss ON CLI スクリプトで常に設定されます。これにより、新規バンドルをデプロイする前に、ディレクトリー内のバンドルに関連付けられたファイルがすべて削除されます。
  • 実稼働環境では、アップグレード間で既存のデータを保持する必要があります。これには 2 つの設定が必要です。
    • この compliance 値は常に filesAndDirectories で 、 初回のデプロイメント時に既存のファイルを保存します。
    • 2 つの <rhq:ignore> 要素は、ログディレクトリー用と、サイトメンバーのアップロードを含むデータディレクトリー用に設定されます。
最後の重要なアクションは、バンドルが実際に JBoss ON にアップロードされると発生します。
アプリケーションのバージョン 1 はすでに安定していて完了したため、Tim は安定したバージョンとして最初のバンドルを作成します。ZIP ファイルで他のアプリケーションファイル deploy.xml とともにパッケージ化し、バンドル全体を JBoss ON ON に直接アップロードするため、JBoss ON データベースに保存されます。
バージョン 2 は devel バージョンです。QA 環境には、GIT の最新ビルドに基づく更新が頻繁に必要になります。Tim は deploy.xml 個別にアップロードしますが、関連するすべてのパッケージの GIT URL にプロビジョニングウィザードをポイントします。バンドルがデプロイされると、JBoss ON はリポジトリーからパッケージを取得します。

結果

Tim はバンドルのバンドル 1 を本番環境にデプロイし、バージョン 2 を QA 環境にデプロイしました。

つまり、Tim が、異なるソースからプルされた同じアプリケーションの異なるバージョンを、異なるリソースにデプロイしたことを意味します。実稼働サーバーに問題が発生した場合、最後の安定したバージョンに戻すことができます。
さらに、QA 環境へのバンドルデプロイメントをスクリプト化できるため、テストを完全に自動化できます。
バグを報告します。