Puppet Application Orchestration – “Modeling applications as code”

One week before their fifth annual conference, Puppet Labs announced a new feature called “Puppet Application Orchestration”. This new capability from one of the leaders in IT automation and DevOps allows customers to manage not only their business-critical infrastructure, but their business-critical applications too. Like everyone else, I was looking forward to the official presentation and first public demo. This post is a short introduction to Puppet Application Orchestration, an innovation I feel will greatly expand the popularity of the infrastructure as code movement within DevOps whilst further enabling customers to deliver their business objectives.

Puppet Application Orchestration will enable the acceleration of application deployments and reduce downtime associated with application releases. Applications are defined and managed as code in the same way that infrastructure has been to date enabling the seamless deployment of the full application stack throughout the application life cycle. Puppet has added this new orchestration layer over the management of the infrastructure code in order to reduce the complexity of deploying applications. Although it has been possible to achieve something similar with Mcollective, new tools and major additions to the Domain Specific Language (DSL) have greatly simplified and extended the capabilities. Writing the applications as Puppet code is very powerful, as you can leverage the benefits of the DSL which has been extended for application orchestration to allow relationships and cross-dependences between applications, components, services and modules to be defined.  As the new functionality is built on the core concepts of Puppet, customers can leverage all 3,500 public forge modules, giving them a huge library of resources from day one!

Below is a simple example of how to manage distributed applications through puppet code:

application forge(

$db_user,
$db_password
) {
forge::pql { $name:
user      => $db_user,
password  => $db_password,
export    => Sql[$name],
}

forge::api { $name:
consume   => Sql[$name],
export    => Http[“forge-api-$name”],
}

forge::web { $name:
consume   => Http[“forge-api-$name”],
export    => Http[“forge-web-$name”],
}
}

Now instead of classes we have applications. In this case we have three profiles: forge::pgl, forge::api, and forge::web. To include this manifest in our node classification (for example site.pp) we could input something like:

site {

forge { “simple”:

$db_user      => ‘simple’,
$db_password  => ‘234ui134k56g3h432kjgh3k3f4ghl’,
nodes         => {
Node[node1.forest-technologies.co.uk] => Forge::Api[‘simple’],
Node[node2.forest-technologies.co.uk] => Forge::Web[‘simple’],
Node[node3.forest-technologies.co.uk] => Forge::Pql[‘simple’],
}
}
}

To run this deployment we will use the new option called “job”:

“puppet job run Forge[‘simple’]

Puppet logoOther future innovations previewed at Puppetconf 2015 included a visual workflow designer within Puppet dashboard, which is likely to lower the barrier of knowledge required for those unfamiliar with Puppet. Puppet Application Orchestrator is planned to be released with Puppet Enterprise 2015.3 alongside other new features such as provisioning with Azure and sync features to release the code from your laptop to your productions servers.

As a long time Puppet devotee, Alejandro leads the Puppet practice within ECS Digital (preiouslt named Forest Technologies).  If you would like to discuss our thoughts on Puppet Application Orchestration and our recommendations on how it should be incorporated into a Continuous Delivery tool chain or any other aspect of DevOps, please do get in touch with us.

Found this interesting? Why not share it: