Example 2 - CI Server
Overview
This example shows how a developer can use BundleWorks to manage an environment running Hudson, a Continuous Integration (CI) server. In this example, there are two bundles, one for Hudson and one for the Java™ JDK. Unlike the previous example, which contained only loadable bundles, this example includes a executable bundle (i.e. Hudson).
In this example, the Hudson and Java JDK bundles are deployed to an environment named ci. Once these bundles are deployed, the Hudson server can be started using the BundleWorks use and start commands as follows:
use ci hudson start
The 'use' command loads the 'jdk' bundle deployed within the 'ci' environment. It also creates an alias to the 'hudson' bundle deployed inside 'ci', providing a shortcut for executing commands like 'start' on the hudson bundle.
BundleWorks provides additional commands for controlling and managing executable bundles including: stop, restart, status, history, and cfghistory. The reference section of the BundleWorks manual provides more details on these commands.
Bundles
- Java 1.5.0_13 - Java5 development kit
- Hudson 1.153 - Continuous integration server
Environments
- ci - contains Java 1.5.0_13 and Hudson 1.153
Details
/opt/bundles
jdk/
1.5.0_13/ [1]
bundle/
actions/
load.sh
unload.sh
info
hudson/
1.153/ [2]
bundle/
actions/ [3]
install.sh [4]
start.sh [5]
status.sh
stop.sh
config/
hudson.properties [6]
shared/ [7]
war/
hudson.war
/var/env/
ci/ [8]
env/
info
hudson/ [9]
bundle [10]
work/ [11]
config/
hudson.properties [12]
hudson.err
hudson.out
hudson.pid
jobs/
plugins/
secret.key
tmp/ [13]
uses/
jdk [14]
- This is a bundle for version 1.5.0_13 of the Java JDK. The previous example provides more information about this bundle.
- This is a bundle for version 1.153 of Hudson. Unlike the JDK bundle, which references directories outside the bundle, this bundle contains everything needed to run Hudson.
- The actions directory of the Hudson bundle contains the scripts used by BundleWorks to install, start, stop, and get status for Hudson. These scripts rely on BundleWorks functions like check_if_running) and variables like $WORK_DIR.
- The install script is responsible for deploying a new instance of Hudson into an environment. BundleWorks allows multiple instances of an application to be deployed across multiple environments. To do this, BundleWorks creates a work directory inside an environment to contain all the runtime files for a particular instance of an application. In the case of Hudson, this 'work' directory becomes the 'HUDSON_HOME' directory. Multiple instances of Hudson can then be run, as long each has its own home directory, port number, and tmp directory. This install script prompts for a port number and writes it to the properties file copied inside the work directory.
- The start script is responsible for starting a particular instance of Hudson, provided it is not already running. It relies on BundleWorks functions like find_matching_processes and wait_for_start. It also uses the BundleWorks BUNDLE_HOME variable to locate the Hudson war file and the WORK_DIR to set the Hudson 'home' directory. The stop and status scripts operate in a similar fashion.
-
This hudson.properties file is a template properties file. This file contains the line:
httpPort=@{HTTP_PORT}When the hudson bundle is deployed into an environment, this properties file is copied into the hudson 'work' directory within that environment. The variable @{HTTP_PORT} is then replaced with the value entered during the install script. - The shared directory contains the war file downloaded from the Hudson website. This war file can be deployed into a servlet container or it can be run directly without a servlet container as is done in this example.
- The ci environment is created inside /var/env. The hudson and jdk bundles are deployed into this environment.
- The hudson directory inside /var/env/ci is created when the hudson bundle is deployed to the ci environment. This is different from the way that loadable bundles are installed (see Note 14). This hudson directory contains a reference to the 1.153 version of the hudson bundle and a 'work' directory containing all of Hudson's runtime files. This separation of bundle and work directories has several advantages. First, it allows a single bundle to be shared between multiple environments. Second, it simplifies upgrades and rollbacks, since runtime files do not need to be moved or copied when the application version changes. Finally, application runtime files can backed up separately without the need to back up application files which do not change.
- The bundle file inside the hudson directory contains the path of the hudson bundle that is deployed in this environment. When a new version of Hudson is available, it can be deployed in this environment simply by changing the path within this bundle reference file (and, of course, making any other changes needed by Hudson).
- The work directory inside the hudson directory contains all of the runtime files needed to run an instance of Hudson. Additionally, it includes files created by the start script to capture standard out, standard error, and process id of the Hudson instance.
-
This hudson.properties is the result of the install script copying the template properties (see Note 6) into the work directory during deployment. It contains the line:
httpPort=8001
In this case, 8001 was entered during installation and substituted for the variable @{HTTP_PORT} within the template properties file. - The tmp directory is kept inside the hudson work directory, allowing multiple instances of Hudson to run on a single machine. This is accomplished by setting the Java system property java.io.tmpdir to "$WORK_DIR/tmp" within the start script.
- The jdk file here contains the path of the jdk 1.5.0_13 bundle. Since the jdk bundle is a loadable bundle, it is deployed as a reference file within the 'uses' directory of the bundle. A separate directory is not created as is the case for executable bundles like hudson.