Application orchestration provides Puppet language extensions and command-line tools to help you configure and manage multi-service and multi-node applications.
Application orchestration enables you to create and manage multi-service and multi-node applications.
Specifically, application orchestration provides:
When you use application orchestration capabilities:
In a nutshell, when using application orchestration, you:
The Puppet wordpress_app is a module that demonstrates an example application model. The module contains application components you can use to set up a WordPress database, a PHP application server, and an HAProxy load balancer. With these components, you can build two WordPress applications: a simple LAMP stack or a complex stack that uses load-balancing.
Before beginning, please check the module’s dependencies and compatibilities. For r10k users, the module contains a Puppetfile that installs the needed dependencies. If you download the module with the PMT, the dependencies are installed for you.
One of the main features of application orchestration is its extension of the Puppet language to provide new constructs for managing multi-service and multi-node dependencies.
These language extensions include, the application definition, application components, and service resources.
Consider the following example:
A common use-case for Puppet users is the three-tier stack application infrastructure: the load-balancer, the application/web server, and the database server. When you configure these servers, you want the application server to know where the database service is and how they connect so that you can cleanly bring up the application. You then want the load balancer to automatically configure itself to balance demand on a number of application servers. When you update the configuration of these machines, or roll out a new application release, you want the three tiers to reconfigure in the correct order.
Previously in Puppet, you’d write some Puppet code for each tier of this stack, and classify the nodes responsible for each tier. Then you’d manually run Puppet on each node in the desired order, or wait for configuration to converge after several node runs. In some cases, you even used exported resources to exchange information between the application and database servers, or you pre-filled information in Hiera.
In other words—you did a lot of labor to realize your stack.
With application orchestration functionality, you model each tier as a component of a larger construct—the application—and use Puppet Enterprise to trigger the nodes’ configurations in the order you specify. When you specify the order of the configurations, information is shared between nodes (for example, services are stopped or started) to ensure each component of the stack is created in the correct order.
The application definition is a lot like a defined resource type, except that instead of defining a chunk of reusable configuration that applies to a single node, the application definition operates across multiple nodes. The components you declare inside an application can be individually assigned to separate nodes that you manage with Puppet.
The application definition defines the configuration of your application infrastructure—what dependencies nodes have on each other and what information they exchange about those dependencies.
An application component is an independent bit of Puppet code that can be used alongside one or more other components to create an application. Components are commonly defined types that consist of traditional Puppet resources that describe the configuration of the component (for example, a file, package, or service). But components can be classes or native resources too.
A type, class, or resource becomes an application component when you declare it in an application manifest while producing, consuming, or requiring a service resource (using the
When you compose applications, application components can share information with each other by exporting and consuming environment-wide service resources. This helps components work together even if they are on different servers. An environment service resource works like an exported resource, providing data for other parts of the application to consume. It also helps application components express dependent relationships.
You can also write custom service resource types.
While the application orchestration language features work in open source Puppet, the language features alone don’t result in ordered runs that respect node dependencies. The Puppet orchestrator command-line tool and service is controls ordered runs, but currently available only in Puppet Enterprise. Open source Puppet users can use the application orchestration language features, but open source Puppet does not provide any tools for controlling ordered runs.