Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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 compliance value 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 cleanDeployment option 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 compliance value 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.
Report a bug
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat