all things open

Please note this is referring to CloudForms Version 1. For more information on CloudForms version 2 integration with puppet you should see this post by John Hardy.

Effective configuration management has always been seen as critical to running an efficient IT department. The school of thought has been that effective configuration management is necessary for automation which, in turn, reduces operational expenditures. I’d argue that it is important to ensure that automation is a critical success factor for reducing opex before pursuing it. For some scenarios in which automation may not always lead to reduced opex I’d refer to some great research by Aaron B. Brown and Joseph L. Hellerstein’s on Reducing the Cost of IT Operations–Is Automation Always the Answer? It’s clear that whether to automate or not is an important question to answer before pursuing it as a strategy to reduce opex. For those scenarios in which a proper analysis has been done and automation appears to be a means to reducing opex you can read on. 🙂

As I mentioned in my earlier post on Open Hybrid PaaS, CloudForms is based on the upstream projects of Aeolus and Katello and allows users to gain greater re-use, increased flexibility, and the wonderment of self-service among other things. One way in which CloudForms achieves greater re-use and increased flexibility is by providing users with the ability to bootstrap instances that have been launched in a cloud resource provider with configuration information. This is particularly useful since each cloud resource provider could potentially have differences that the applications must be aware of.  Network topologies, IP address pools, DNS names, may be dynamically assigned and completely different in a private cloud based on Red Hat Enterprise Virtualization then in Amazon EC2 for example. For more information on how this bootstrap configuration works I’d refer you to the Technical Review Webinar, which provides an architecture overview of CloudForms and gives a demonstration of how the bootstrapping in different clouds is performed.

So you can bootstrap your instances, but how do you manage your configurations on the systems once they are running? Managing drift and configuration deployment is not just a “at boot” problem. In the future, Red Hat CloudForms will likely include the ability to manage configurations of deployed instances ongoing. This will likely happen through the inclusion of The Foreman project and some workflow in Katello. Even still, there is no reason an organization couldn’t get started using puppet today with CloudForms. Here is what integrating a puppet master into a CloudForms enabled environment would work today.

Integrating puppet into a CloudForms environment

1. CloudForms requests that the cloud resource provider launch the instance using the Deltacloud API.
2. CloudForms passes runtime configuration information to the Audrey Config Server.
3. The Cloud Resource Provider launches the instance.
4. The Audrey Agent included in the image runs at boot and connects to the Audrey Config Server, exchanging information.
5. With the information required for the environment (for example what the hostname of the puppet master is) the audrey agent configures the Katello Agent and Puppet Agent.
6. The Katello Agent can now get updates from CloudForms.
7. The Puppet Agent can now get configuration from Puppet Master.

Here is a quick look at how Puppet Enterprise can be integrated into CloudForms Application Blueprints. We will assume you have already deployed a puppet master. If you need help with that I’d recommend reading the quick start guide on Puppet Enterprise.

First, synchronize the puppet enterprise packages into CloudForms System Engine. This will allow us to build system templates and include the packages required by puppet enterprise.

Synchronizing the Puppet Enterprise Packages

The packages you will need are below. You can find them by extracting the tarball from puppet enterprise and then just creating a yum repository from them.

 pe-puppet-enterprise-release
 pe-puppet
 pe-facter
 pe-ruby
 pe-ruby-libs
 pe-ruby-shadow
 pe-mcollective
 pe-mcollective-common
 pe-ruby-irb
 pe-ruby-rdoc
 pe-rubygem-stomp
 pe-rubygems
 pe-augeas
 pe-augeas-libs
 pe-rubygem-hiera-puppet
 pe-rubygem-hiera
 pe-ruby-augeas
 pe-rubygem-stomp-doc
 pe-ruby-ldap
 pe-ruby-ri

Next, create the system templates and include the packages listed above in them and promote a changeset with the content outside of your library.

Including the puppet enterprise packages in a system template

Promoting the system template and puppet product

Then, download the system template and import it as a new image in CloudForms Cloud Engine and build your images for your providers.

Image Building

Once you have built your images you can include the necessary services in your Application Blueprint to configure the Puppet agent. You can find my services and scripts for the puppet enterprise agent in my GitHub repository.

Application Blueprint

Once you have added the services it’s just a matter of launching the Application Blueprint and specifying the hostname of the puppet master for which you wish to register the instances too. Please note that you could also take this input out of the hands of the user launching the Application Blueprint if desired.

Almost there

Launching to RHEV

The services and script will automatically register the associated instances to the puppet master. As you can see in the screenshot below, the puppet master now sees the instance has issued a certificate request and it can be signed.

After you have signed the request, you can see the node within the puppet enterprise console and can begin managing it.

Instance details within puppet enterprise console

By leveraging the re-usability of Application Blueprints in CloudForms and its bootstrapping methodology to automatically register instances to a puppet master it is possible to effectively manage configurations across various cloud resource providers.