Published on 21 November 2011 by

Last week we released Puppet Enterprise 2.0, and one of the new orchestration capabilities we’re most excited about is Live Management. Puppet has always given you incredible power for managing your infrastructure, and Live Management harnesses that power into a clean, simple-to-use graphical interface, the Puppet Enterprise Console. Now with just a few clicks of the mouse, you can survey the state of all of your nodes, and clone configurations to other machines. By combining the power of Puppet’s advanced messaging technology with our native resource abstraction layer, we have created a simple entry point to get a detailed overview of your network and manage it on the fly.

Specifically, Live Management will allow you to browse and manage users, groups, software packages, and host entries across your network. These resources can be cloned from, or to, any subset of your infrastructure, which can be narrowed down by a simple hostname search, or more narrowly by the values of different facts about the machines. This new capability will also give you a preview of the impact of this change, which can then later be integrated into a fully Puppetized infrastructure. To demonstrate the capabilities of this new application, this blog post will walk through two example workflows.

Example Workflow 1: Setting up new Webservers

Our first example workflow will demonstrate how easy Live Management makes it to copy aspects of your configuration from existing hosts to new machines. In our example scenario, we have just added two CentOS machines to our network, and want to configure both of them as webservers. Specifically, we want to set them up in the exact same manner as an existing web server with the hostname “MAIN_WWW”. To do this, we’ll need to clone the version of Apache we have installed on MAIN_WWW to our new machines.

First off, we’ll need to find the correct version of the ‘httpd’ package. To do so, we can load the ‘package’ resource tab, and click ‘Find Resources’.

Scrolling down and selecting the ‘httpd’ package will show us information about which versions of this package we have installed on our various hosts.

All package resources with the title ‘httpd’ will be collected on this page, separated into variations according to their specific characteristics. To begin the process of cloning this package to the new hosts, we will click “Clone this variation” under the version installed on MAIN_WWW and continue by clicking the “Preview” button that appears at the top of the screen.

This takes us to a page previewing the results of cloning this resource to the currently selected set of nodes.

To proceed with cloning, we need to restrict this set of nodes to the desired target: all nodes running the CentOS operating system. To do this, we can search on the ‘operatingsystem’ fact with the value ‘CentOS’ under the Advanced Search tab.

Now that we’ve selected the resource we want and the nodes we want to clone it to, we can proceed by clicking “clone.” This will take us to a page showing the results of the operation. Success!

We’ve just set up these nodes to be web servers.

Example Workflow 2: Unifying Accounts

In this workflow scenario, we’ll look at a situation where ad-hoc changes have caused difficult-to-manage configuration drift; specifically, the case where developers have created similar users for logging in to various hosts that all behave a bit differently. Our task is to unify this developer account so that it’s identical across the entire network.

To start off, we’ll find all of the user resources on our network, and select the resource titled ‘developer’.

This resource currently exists in 3 different forms across our networks, with different shells and home directories. To proceed, we will select ‘Clone this variation’ for the version we want on all of our nodes: the one with the shell ‘/bin/zsh’. This takes us to a preview screen, showing which nodes will have their current version of the user ‘developer’ overwritten by the change.

By clicking ‘Clone’, we will unify this user resource to have the same characteristics across all of our currently selected nodes. Again, this takes us to a results page showing success.

These example workflows only begin to show the power available through Live Management, and the wider orchestration capabilities in Puppet Enterprise 2.0. In the next post in this series, we will explore more advanced capabilities available via the new Puppet Enterprise Console, including controlling your Puppet runs and manually controlling our framework that supports distributed, parallel job execution (aka the Marionette Collective) through the Live Management GUI.

Learn More

Share via:
Posted in:

I am using Puppet Enterprise v3.2.
I do not see "Manage Resources" option. Instead, it is "Browse Resources", and "Clone resource" link is missing. How can I clone resources now?

What capabilities in the Live Management UI do you miss? When do you use them? By helping us understand your use cases, we can build better solutions.

With PE 3.8 we added deprecation warnings about the eventual removal of Live Management and it was removed in the 2015.2 release. See…

The reasons why we removed it from the UI are:
- Poor user experience that forced you to switch contexts to take action
- Poor feedback on some actions, like running puppet
- Lacks RBAC so providing access to the web UI was dangerous
- Anything you could do in LM can still be done on the command line with mcollective

Going forward we plan to re-introduce LM's capabilities in more usable forms, so stay tuned.

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.