このコンテンツは選択した言語では利用できません。
27.3. Extended Example: Provisioning Applications to a JBoss EAP Server (Planning)
The Setup
Tim the IT Guy at Example Co. has to manage the full application lifecycle for Example Music's online band management application, MusicApp. There are two environments: one for QA and one for the live site. Both environments contain a mix of Windows and Linux servers.
Tim wants to deploy the latest development version weekly to the QA environment, based on the most current build in their development GIT repo. He wants the most stable version of the application to be deployed to the production environment, based on a static package.
What to Do
The best plan for Tim is to work backwards, starting with the way he wants his ideal QA and production environments to be configured.
Tim's first step is to identify his destinations, based on his environments. Because he has two separate environments, he wants to create two separate groups, one for QA and one for production. MusicApp runs on a JBoss server, so his compatible groups will be for the JBoss AS/EAP resources rather than platforms.
Additionally, the needs for each of his environments is different:
- The QA environment needs ...
- New builds directly from the GIT repository, every week.
- A completely clean directory to begin from with every deployment.
- There is a separate QA environment for each of Example Co.'s web applications, so MusicApp is the only application running on those specific servers.
- The production environment needs ...
- A stable build that can be safely stored in JBoss ON.
- To save historic data. The production environment has both log directories and user-supplied data directories that need to be preserved between application upgrades.
- A couple of different web applications run on the same production servers.
The application itself is the same for both environments. Instance-specific configuration — port numbers, the application name, the machine IP address — are based on tokens that are realized when the application is deployed. The JAR files contained in the bundle should be extracted at the time the application is deployed, with the exception of one client which site members can either install or launch locally.
Tim decides to use different versions of the same bundle, labeling the QA versions as devel and the production versions as stable.
There are some similarities between the devel and stable bundle recipes:
- MusicApp should be deployed to the
deploy/directory, but because it is not the only application that they run, it will have its own webapp context subdirectory. While this is not strictly necessary in the devel environment (where MusicApp is the only application), this maintains consistency with the final deployment destination. - Both recipes will configure the application JAR file,
MusicApp.jar, to be exploded when it is deployed. - The client archive file,
MyMusic.jar, will not be exploded (<rhq:file ... exploded="false">). - Tokens are defined in the raw configuration files and the recipe for the port numbers, IP addresses, and application names.
And then there are differences in the recipes, related to how the devel and stable versions should handle existing files.
- The QA environment always requires a pristine deployment. This requires three settings:
- The
compliancevalue is always full, so no existing files are preserved during the initial deployment. - No
<rhq:ignore>elements are set, so no generated files are preserved during an upgrade. - The
cleanDeploymentoption is always set in the JBoss ON CLI script that automates deployments. This removes all bundle-associated files in the directory before deploying the new bundle.
- The production environment needs to preserve its existing data between upgrades, which requires two settings:
- The
compliancevalue is always filesAndDirectories, which preserves existing files during the initial deployment. - Two
<rhq:ignore>elements are set, one for the log directory and one for the data directory containing the site member uploads.
The last significant action comes when the bundles are actually uploaded to JBoss ON.
Version 1 of the application is already stable and complete, so Tim creates the first bundle as a stable version. He packages the
deploy.xml with the other application files in a ZIP file and uploads the entire bundle directly to JBoss ON, so it is stored in the JBoss ON database.
Version 2 is a devel version. The QA environment requires frequent updates based on the latest build in GIT. Tim uploads the
deploy.xml separately, but he points the provisioning wizard to the GIT URL for all of the associated packages. When the bundle is deployed, JBoss ON takes the packages from the repository.
The Results
Tim deployed version 1 of the bundle to the production environment, and he deployed version 2 to the QA environment.
This means that Tim has deployed different versions of the same application, pulled from different sources, to different resources. If he ever has a problem with the production server, he can simply revert it to the last stable version.
Additionally, he can script bundle deployments to the QA environment, so his tests can be fully automated.
