At XebiaLabs, we build Deployit, 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 Deployit 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. Deployit 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.
Deployit and Puppet
Provisioning and deployment are complementary processes that, together, enable on-demand application scaling. There are two ways to integrate Deployit 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 Deployit 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 Deployit can drive deployments to virtual environment with Puppet to provide an overall, end-to-end deployment service.
Driving Deployit from Puppet
Puppet 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 Deployit from Puppet, we created a Puppet Deployit module that can be found in Deployit's community github repository. It adds resources to Puppet that can be used from a manifest to interact with Deployit. The Jython Deployit command line interface (CLI) is installed on the node to communicate with the Deployit server.
The main use case our customers have is registering middleware that is provisioned through Puppet in Deployit 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 Deployit 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 Deployit CLI. The final section registers the provisioned webserver with Deployit. We will examine this last section in detail.
The resource deployit::ci represents a CI (Configuration Item) that can be created in Deployit. 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 Deployit Repository Browser:
Puppet-provisioned webserver in Deployit
If we have a Website application version 1.0 loaded in Deployit, we can deploy it to the TEST-Website environment now, with the HTML in our website automatically targeted to the newly provisioned server:
Deployment of Website/1.0 to Puppet-provisioned webserver
Conclusion
Deployit and Puppet make a great team to achieve effortless scaling of your application. Using the Deployit Puppet module, Puppet provisioned nodes can register themselves with Deployit to make them ready for deployments.
Stay tuned for the next blog which will show how Deployit can drive Puppet to provision a completely new environment and instantly deploy your application on it.
