Chapter 20. Example: Deploying Applications Through Bundles (General)

Bundles are a very clean and easy way to deploy full applications, configuration files, or other content to resources. Whether a given resource type supports bundles is defined in its plug-in descriptor. By default, platform resources and JBoss AS 4, 5, and 6 resources all support bundles.
Bundles are convenient from an administrative perspective because all of the content is maintained in a single place that is resource-agnostic. The main bundle entry or bundle definition contains a set of versions of the actual bundle files and a set of destinations for where that content can be deployed. A destination is a combination of a compatible group, resource type, and directory path. When a version is actually deployed to a destination, it is saved as a specific deployment for that destination.
The bundles system maintains multiple versions of a given package and can deploy any of those versions to any destination. This is a great workflow for application lifecycles, since a stable version can be deployed to production servers while a development version can be deployed to test machines. Having each deployment represented as a different child of the destination makes it easy to revert changes; you can move from the live version to a previous version and know exactly what that previous deployment looked like.

20.1. Setting up Bundle Versions and Destinations

There are two parts to the bundle definition: the bundle version and the destination. Both of these parts are set up independently, and then saved into the final definition.
The bundles.js script in the cliRoot/rhq-remoting-cli-4.9.0.JON320GA/samples/modules/ directory defines a set of custom functions that quickly create a bundle version and definition. (The bundles.js script requires the util.js script.)
To create the destination, give the absolute path on the local system to the bundle archive to upload.
rhqadmin@localhost:7080$ var path = '/export/files/'
rhqadmin@localhost:7080$ createBundleVersion(path)
The createBundleVersion function in the bundles.js file uploads the files as a byte array.
function createBundleVersion(pathToBundleZipFile) {
        var bytes = getFileBytes(pathToBundleZipFile)
        return BundleManager.createBundleVersionViaByteArray(bytes)
The second part of the bundle definition is creating at least one destination where the bundle version could be deployed. Creating a destination requires two things to exist already:
  • A bundle version (which was just created with createBundleVersion)
  • A compatible group
A destination is a combination of a compatible group and the directory to deploy to. Each resource type defines its own available base directory, then a subdirectory beneath that root can be specified as the deployment directory.
The other configuration properties are details for the entry, such as the destination name and description.
rhqadmin@localhost:7080$ var destinationName = 'New Destination'
rhqadmin@localhost:7080$ var description = 'My new example destination'
rhqadmin@localhost:7080$ var bundleName = 'myApp'
rhqadmin@localhost:7080$ var groupName = 'Linux Group'
rhqadmin@localhost:7080$ var baseDirName = '/'
rhqadmin@localhost:7080$ var deployDir = 'var/www/html/'
rhqadmin@localhost:7080$ createBundleDestination(destinationName, description, bundleName, groupName, baseDirName, deployDir)
The createBundleDestination function runs the searches for the group and the bundle based on the specified names, which makes it possible to set up the destination without having to run additional searches.
function createBundleDestination(destinationName, description, bundleName, groupName, baseDirName, deployDir) {
        var groupCrit = new ResourceGroupCriteria;
        var groups = ResourceGroupManager.findResourceGroupsByCriteria(groupCrit);

... 8< ...

        var group = groups.get(0);

        var bundleCrit = new BundleCriteria;
        var bundles = BundleManager.findBundlesByCriteria(bundleCrit);

... 8< ...