XL Deploy and Puppet integration

At XebiaLabs, we build XL Deploy, the most advanced Application Release Automation (ARA) solution on the market. The main reason for customers to use our product is to speed up time to market for new software. The ability to deploy software, without errors and without down time, with the push of a button is a critical component in our customers’ agile, continuous delivery and cloud strategies.
As part of those initiatives, many of our customers are also virtualizing their infrastructure. The functionality that makes XL Deploy ideal for deploying new releases also make it a perfect companion to an on-demand infrastructure strategy. When spikes in demand for applications hit, virtualized infrastructure makes it possible to scale up quickly and automatically. But this infrastructure is not terribly useful without an application running on it. XL Deploy ensures that the newly provisioned servers run the right version of the desired application (configuring loadbalancers, static HTML, Java or .NET applications and databases) and join in shouldering the increased load.XL Deploy and PuppetProvisioning and deployment are complementary processes that, together, enable on-demand application scaling. There are two ways to integrate XL Deploy and Puppet to make this happen.
Chronologically, provisioning has to take place before deployment can. The deployment automation solution must become aware of the new middleware before an application can be deployed to it. In our case, when a new host is started and Puppet is run to provision it, Puppet drives the process and informs XL Deploy when it is done. This type of integration is the topic of this blog.
You could consider Puppet to deploy your applications as well. However, there are a couple of things to consider. First, deployments to WebSphere, WebLogic or JBoss all have their own peculiarities. Puppet does not have any middleware platform intelligence out of the box. Second, Puppet does not manage cross-node dependencies so when scaling up an entire stack (say web server, application server and database) Puppet can not be used to perform a deployment when the entire stack is provisioned. Finally, deployments to an environment require knowledge of that environment that goes beyond the node being provisioned. For instance, a deployment of a website on a new virtual server may require reconfiguring the environment’s loadbalancer. Puppet does not have this type of overview.
Scaling up in these scenarios can best be driven from the application layer. In a future blog I will describe how XL Deploy can drive deployments to virtual environment with Puppet to provide an overall, end-to-end deployment service.Driving XL Deploy from PuppetPuppet supports a flexible module system that allows providers to plug in additional functionality. This functionality can then be invoked from Puppet manifests, descriptions of the configuration newly provisioned node should have. To drive XL Deploy from Puppet, we created a Puppet XL Deploy module that can be found in XL Deploy’s community github repository. It adds resources to Puppet that can be used from a manifest to interact with XL Deploy. The Jython XL Deploy command line interface (CLI) is installed on the node to communicate with the XL Deploy server.
The main use case our customers have is registering middleware that is provisioned through Puppet in XL Deploy to make it ready for deployment. In the following example, a Puppet manifest is shown that provisions a node with an Apache web server and creates a representation of the server in a central XL Deploy installation.
The Puppet manifest consists of three main sections. The first section installs the latest version of the Apache webserver. The second section installs the XL Deploy CLI. The final section registers the provisioned webserver with XL Deploy. We will examine this last section in detail.
The resource XL Deploy::ci represents a CI (Configuration Item) that can be created in XL Deploy. Both a host CI (the server that Apache is running on) and the Apache web server itself must be created. The id, type and properties of the CI are specified in the manifest. Each of these values is the same for every provisioned webserver. Note the use of the configuration value $::ipaddress_eth1. This facter fact is replaced at runtime with the IP address of the virtual machine. It’s use makes it possible to reuse the exact same manifest for every Apache instance provisioned. The apache2-server CI is also added to the TEST-Website environment so that it can be targeted for deployment.
When the webserver node is fully provisioned, this is how the CIs look in the XL Deploy Repository Browser:

If we have a Website application version 1.0 loaded in XL Deploy, we can deploy it to the TEST-Website environment now, with the HTML in our website automatically targeted to the newly provisioned server:
ConclusionXL Deploy and Puppet make a great team to achieve effortless scaling of your application. Using the XL Deploy Puppet module, Puppet provisioned nodes can register themselves with XL Deploy to make them ready for deployments.
Stay tuned for the next blog which will show how XL Deploy can drive Puppet to provision a completely new environment and instantly deploy your application on it.