27.3. Extended Example: Provisioning Applications to a JBoss EAP Server (Planning)
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.
The best plan for Tim is to work backwards, starting with the way he wants his ideal QA and production environments to be configured.
- 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.
- 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.
- The QA environment always requires a pristine deployment. This requires three settings:
compliancevalue is always full, so no existing files are preserved during the initial deployment.
<rhq:ignore>elements are set, so no generated files are preserved during an upgrade.
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:
compliancevalue is always filesAndDirectories, which preserves existing files during the initial deployment.
<rhq:ignore>elements are set, one for the log directory and one for the data directory containing the site member uploads.
deploy.xmlwith 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.
deploy.xmlseparately, 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.
Tim deployed version 1 of the bundle to the production environment, and he deployed version 2 to the QA environment.