-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for Red Hat JBoss Operations Network
Chapter 27. Deploying Content and Applications Through Bundles
27.1. An Introduction to Provisioning Content Bundles
27.1.1. Bundles: Content and Recipes
deploy.xml
; this must always be located in the top level of the bundle archive.
Figure 27.1. Bundle Layout
27.1.2. Destinations (and Bundle Deployments)
- A compatible resource group (of either platforms or JBoss servers)
- A base location, which is the root directory to use to deploy the bundle. Resource plug-ins define a base location for that specific resource type in the
<bundle-target>
element. This can be the root directory or, for JBoss servers, common directories like the profile directory. There may be multiple available base locations. - The deployment directory, which is a subdirectory beneath the base directory where the bundle content is actually sent.
deploy/myApp/
directory. The JBoss AS5 plug-in defines two possible base locations, one for the installation directory and one for the profile directory. The administrator chooses the profile directory, since the application is an exploded JAR file. The agent then derives the real, absolute path of the application from those three elements:
JBoss AS group + {$PROFILE_DIR} + deploy/myApp/
/opt/jbossas/default/server/
, then the destination is:
/opt/jbossas/default/server/deploy/myApp/
C:\jbossas\server\
, then the path is derived slightly differently, appropriate for the platform:
C:\jbossas\default\server\deploy\myApp
Figure 27.2. Bundles, Versions, and Destinations
27.1.3. File Handling During Provisioning
A bundle file contains a set of files and directories that should be pushed to a resource. However, the provisioning process does not merely copy the files over to the deployment directory. Provisioning treats a bundle as, essentially, a template that defines the entire content structure for the target (root) directory.
app.conf lib/myapp.jar
deploy/myApp/
, then the final configuration is going to be:
deploy/myApp/app.conf deploy/myApp/lib/myapp.jar
deploy/myApp/
, then they will be removed before the bundle is copied over, so that the deployment directory looks exactly the way the bundle is configured.
deploy/myApp/
, then that behavior is totally acceptable because the defined application content should be the only content in that directory. However, bundles can contain a variety of content and can be deployed almost anywhere on a platform or within a JBoss server. In a lot of real life infrastructures, the directory where the bundle is deployed may have existing data that should be preserved.
compliance
option can be set to filesAndDirectories, which means that provisioning will copy over the bundle and create the appropriate files and subdirectories, but it will not manage (remove) the existing content in the directory.
Warning
/etc
on a platform or a critical directory like deploy/
or conf/
, then all of the existing files and subdirectories in that directory are deleted. This can cause performance problems or data loss.
Even if the compliance
option is set to filesAndDirectories, subdirectories and files contained in the bundle are always managed by the bundle, even if they existed before the bundle was deployed.
deploy/
directory has this layout before any bundle is deployed:
deploy/ deploy/notes.txt deploy/myApp1/ deploy/myApp2/ deploy/myApp2/first.txt
myApp2/ myApp2/foo.txt myApp2/bar.txt
compliance
is set to filesAdDirectories, the existing files in the deploy/
remain untouched, except for what is in the myApp2/
subdirectory, because that directory is defined by the bundle. So, the final directory layout is this:
deploy/ (ignored) deploy/notes.txt (ignored) deploy/myApp1/ (ignored) deploy/myApp2/ (managed) myApp2/foo.txt (managed) myApp2/bar.txt (managed)
Note
/home/.rhqdeployments/
resourceID/backup
.
After the initial deployment, there can be instances where files are added to the deployment directory, such as log files or additional data.
<rhq:ignore>
element, which tells the provisioning process to ignore those files within the deployment directory.
27.1.4. Requirements and Resource Types
- Platforms, all types
- JBoss EAP 6 (AS 7) standalone servers[5]
- JBoss EAP 5 and any server which uses the JBoss AS 5 plug-in
- JBoss EAP 4 (deprecated)
27.1.5. Provisioning and Agent User System Permission
27.1.6. Provisioning and Roles
27.1.7. Space Considerations for Bundles
27.1.8. Bundles and JBoss ON Server and Agent Plug-ins
27.1.8.1. Resource Support and the Agent Resource Plug-in
<bundle-target>
element simply defines allowed base directories for the resource which can be used as base directories in the bundle definition.
<server name="JBossAS:JBossAS Server" ...> <bundle-target> <destination-base-dir name="Library Directory" description="Where the jar libraries are"> <value-context>pluginConfiguration</value-context> <value-name>lib.dir</value-name> </destination-base-dir> <destination-base-dir name="Deploy Directory" description="Where the deployments are"> <value-context>pluginConfiguration</value-context> <value-name>deploy.dir</value-name> </destination-base-dir> </bundle-target> </server>
<bundle-target>
can use the already-configured base directory or it can set different directories to use. In the example, two directories — the deploy/
and lib/
directories — are given as supported base directories. When a bundle definition is created, the wizard offers the choice of which directory to use.
27.1.8.2. Server-Side and Agent Plug-ins for Recipe Types
Note
27.1.9. Managing and Deploying Bundles with the JBoss ON CLI
- A new JBoss application server can be deployed when an existing JBoss server experiences a heavy load or decreased performance.
- Configuration files for a selected snapshot image can be immediately deployed to a platform or JBoss server to remedy configuration drift, in response to a drift alert.
- A new web context can be deployed when another web is disabled within a
mod_cluster
domain.