Thursday, October 17, 2013

Automating a JBoss Deployment with ANT

One area where virtually all organizations seem to differ is in change management–and specifically in the deployment strategy.  Recently, a client requested I put together deployment instructions, specifying a preference that I include a deployment script that could remotely deploy the application.  To meet this requirement, I decided to incorporate this new functionality into my existing ANT build script.
In my case, the application is a JBoss Web Service deployment.  The following steps are necessary to deploy the application:
  1. Stop the JBoss Server.
  2. Removed the previous EAR deployment.
  3. Copy the new EAR file up to the server.
  4. Restart the JBoss Server.
Note that restarting the JBoss server is not entirely necessary for many applications.  The JBoss hot deploy feature will gladly pick up the changes. However, we’ve had a few issues with hot deployments in other applications and over time have found it best to restart the application server for each deployment. Your mileage may vary.
Also, because we will eventually deploy to multiple environments, I want to be able to store configuration parameters for each target environment in its own .properties file.
The expected command line to run this deployment will be:
ant -Denv=targetEnvironment jboss-deploy
Where targetEnvironment specifies the target deployment environment.
To get started, I added an ANT target to verify two things:
  • That an environment has been specified
  • The corresponding file exists.
If these conditions are met, it reads in the target environment’s configution properties.  Here is the code:
<target name="-jboss-deploy-prep">
     message="Target environment must be specified in ant command line as -Denv=target"
     unless="env" />

  <fail message="conf/${env}.properties file does not exist">
        <available file="conf/${env}.properties" />

  <!-- Get properties for target environment -->
  <property file="conf/${env}.properties" />
The contents of the properties file goes something like this:
jboss.remote.stop=/home/jboss/jboss-5.1.0.GA/server/testapp/bin/testapp stop
jboss.remote.start=/home/jboss/jboss-5.1.0.GA/server/testapp/bin/testapp start
Note that the password is commented out. For security reasons, we may not want to keep the password in the properties file. If the password is not specified, we want to prompt for it. So I added this target:
<!-- get password if not specified -->
<target name="-jboss-prompt-password" unless="jboss.remote.password">
  <input message="Jboss Remote Password:" addproperty="jboss.remote.password">
    <handler classname="" />
Now that I have all the right pieces in place, time to add the jboss-deploy target:
   depends="clean, dist-app, -jboss-deploy-prep, -jboss-prompt-password" >

  <echo message="JBoss Deployment" />
  <echo message="--------------------------------------------------------" />

  <echo message="Stopping the JBoss server running in ${env}" />
     username="${jboss.remote.username}" password="${jboss.remote.password}"
     command="${jboss.remote.stop}" />

  <echo message="Removing existing deployment ..." />
     username="${jboss.remote.username}" password="${jboss.remote.password}"
     command="rm -f ${jboss.remote.instance.home}/deploy/rce-j2ee-*.ear" />

  <echo message="Transferring new deployment ..." />
    sftp="true" trust="true"
    password="${jboss.remote.password}" />

  <echo message="Starting JBoss server running in ${env}" />
    username="${jboss.remote.username}" password="${jboss.remote.password}"
    command="${jboss.remote.start}" />

That’s it. Now executing the jboss-deploy target does the following:
  • Compiles my application
  • Creates a versioned EAR file
  • Stops the JBoss Server
  • Removes the previous deployment
  • Securely copies the new EAR to the server
  • Starts the JBoss server
One other note: if your start/stop scripts make use of the sudo command (as mine does), you may need to modify your sudoers configuration to skipping checking for TTY. The sshexec task does not allocate a TTY terminal, so many Linux distros will not allow the sudo.

No comments:

Post a Comment