homeblogfull visibility and control of your infrastructure new puppet releases

Full visibility & control of your infrastructure with new Puppet releases

As the product managers for Puppet Enterprise and open source Puppet, we are proud to announce the most significant releases in our company history for each of these flagship products. For teams that rely on Puppet, we're offering greater visibility and control of what's in your infrastructure. We've also taken steps to make our release cadence better for customers, and for teams all over the globe.

Here are more details for both releases. We welcome any comments or questions you may have.

Puppet Enterprise 2017.2

By Ryan Coleman

We're super-excited to announce a feature-packed release of Puppet Enterprise 2017.2.

With the Package Inspector feature of Puppet Enterprise 2017.2, Puppet can easily gather package information across any or all nodes, regardless of whether the package is puppetized.

Package data is presented in the Puppet Enterprise console user interface (UI), showing you all package names and how many nodes have that specific version on them. As Chief Product Officer Omri Gazitt mentions in his post, this is a down payment on a larger story of resource and node discovery that will expand in subsequent releases. There’s no code to write — just enable Package Inspector on the nodes you want package data for, and run Puppet.

Discovery Blog Image

With Puppet Enterprise 2017.2, you don’t have to leave the console to run Puppet and enable unmanaged package inspection. We’ve added a complete workflow for running Puppet on any portion of your infrastructure — a workflow that’s flexible, scalable, and updates in real time.

PE . Image  scaled
PE . Image  scaled

The first thing you’ll notice is the larger workspace in the console. The navigation has been redesigned, and the UI is more responsive to browser requirements. It’s internationalized and localized in Japanese, with improved UTF-8 support throughout the product.

In the Jobs section of the navigation, you’ll see a list of jobs that have been run recently (think sets of Puppet runs). This is backed by the orchestrator API, and will include records of runs initiated through the puppet job run command-line client, the Run Puppet button on every node in the console, and any API calls you’re making from your continuous integration server — for example, if you're using the Jenkins pipeline plugin we shipped last fall.

It’s now simple to run Puppet on any or all of your nodes by creating a new Puppet job. You can select from a list of nodes, or use the expressive Puppet Query Language to run on any nodes PuppetDB can answer questions about. You can make broad queries, like asking about all of your Windows nodes. You can also make very specific queries, for example, asking which Windows nodes managing a particular package version failed during their last Puppet run. We’ve included a set of common queries to help you get started with PQL. In subsequent releases, we’ll expand the options for running Puppet on node groups and other parts of the console where you can filter down to a set of nodes.

Once you initiate a set of Puppet runs in the new UI, you’ll see live updates as nodes complete their runs, including resource events from PuppetDB, individual report links, and a summary of node success across the job. You can even stop queued Puppet runs if the deployment isn’t going as you expected. You can confidently run as many nodes as you want, because this workflow was designed for scale. The orchestrator will prevent the stampeding herd effect on your Puppet server; it will queue when a background run is in progress; and the underlying Puppet communications protocol will scale with your compile masters.

There’s a lot more to Puppet Enterprise 2017.2, and you can read about it all in the release notes. Best of all, it’s fully supported for nine months, so download today, deploy tomorrow, and #puppetize for the rest of 2017.

Puppet 5 Platform

By Eric Sorenson

In parallel with the release of Puppet Enterprise 2017.2, today we're releasing the open-source foundations which will become the next generation of Puppet Enterprise: a coordinated set of releases for the Puppet Agent, Puppet Server, and PuppetDB, which together are called the Puppet 5 Platform.

The story of the Puppet 5 Platform truly starts about two and a half years ago, when we started thinking about Puppet 4. At the time, we were living in a deep hole of our own construction, the walls propped up with duct tape and monkey patches of core Ruby methods. In order to provide a more consistent installation and usage experience, we made a number of structural changes — like bundling the entire agent stack into an all-in-one installer; changing file system paths to unify the agent between open source Puppet and Puppet Enterprise: and unifying on one Ruby version across all operating systems. (I wrote about this in more depth on the blog.)

In order to avoid breaking the world by releasing a radically different puppet-4.0 package into the same download location as the previous puppet-3.8 package, we introduced Puppet Collections: new repository layouts and policy for breaking changes that would let releases hit the streets quickly and safely.

But Puppet 4 passed its two-year birthday in April, and this seemed like a good time to examine some of those assumptions and their consequences as we move towards Puppet 5. With invaluable input from the puppet-dev mailing list community and many other conversations with customers and community, a few patterns emerged:

  • The version numbering we'd landed on was extremely confusing. To get Puppet 4, you needed the right combination of puppet-server-2.x and puppet-agent-1.x, and...
  • It wasn't clear exactly which combination you needed in order to get a working installation, nor where the components should come from.
  • The guarantee of a new Puppet Collection on each major-version boundary didn't make a lot of sense, given that both Facter 3 and PuppetDB 3 rolled into PC1 without a fuss.

In response to these facts, we set a few goals to guide the next iteration, which we've achieved with the introduction of the Puppet 5 Platform today:

  • Each of the three main packages that make up the platform — puppet-agent, puppet-server, and puppetdb — are all trued up to version 5.0.0, and they're available from a repository called puppet5.
  • The release cadence and versioning of these components will align around monthly, semver-compliant releases, and each set of releases will be tested together and guaranteed to interoperate.
  • As we move towards the next major version of the platform, all three components will embody the Puppet 6 Platform together, and will be released into a puppet6 repository, which you can opt into when you're ready.

Despite the major version number, the prime directive of Puppet 5 is this:

Modules that work on Puppet 4 will work unchanged under Puppet 5.

Some opt-in changes from Puppet 3 to 4 are now default, and there are some technical backward incompatibilities, but this should largely be a drop-in upgrade. Network compatibility from Puppet 3 agents to Puppet 5 servers will continue to work, so you don't need to upgrade to 4 first, then 5. The main reasons to do the upgrade are:

  • Hiera 5. A fast, clean re-implementation of Hiera preserves the flexibility and power of hierarchical data lookups while adding much-needed debugging capabilities, built-in encryption via EYAML, and awareness of environment and module-specific hierarchies.
  • Native JSON. All critical-path network communication now uses native JSON implementations, providing massive speedups for large catalogs and reports, plus better interoperability with non-Puppet network APIs.
  • Puppet server metrics. In 2015, we introduced a metrics API that exposed the internal workings of catalog compilation, function calls, and HTTP responses. The API and its accompanying Grafana dashboard were PE-only, but as it turns out, debugging and introspection of your infrastructure isn't a premium feature – it's table stakes for operators everywhere. Puppet Server 5 includes a high-performance enhanced version of this API as part of the platform.
  • Full UTF-8 support. It's a wide world out there, and Puppet's previous limitations dealing with non-ASCII character sets led to trouble for everyone with an accent in their user or directory name. We're now cosmopolitan and internationalized, and thus should no longer be subject to failures because, for example, Erik Dalén is Swedish.
  • The Ruby versions in puppet-agent and puppet-server are bumped to the latest from the upstream projects (2.4 for the MRI Ruby in the agent; puppet-server has opt-in support for jruby9k). This removed a lot of monkey-patching, and keeps Puppet current with developments in the wider open-source communities.

We expect the Puppet 5 Platform to hit the 5.0 mark over the summer and then be incorporated into the next Puppet Enterprise release in autumn 2017. At the moment, you can try it out by installing the "puppet5-nightly-release" package from https://apt.puppet.com/ or https://yum.puppet.com/ for deb- and /rpm-based Linux distributions. For Mac or Windows systems, go to https://downloads.puppet.com/ and click on mac/ or windows/, then puppet5-nightly/.

To stay abreast of development as the release milestone nears, follow this JIRA query and watch the puppet-dev mailing list.

Ryan Coleman is director of product management for Enterprise at Puppet, and Eric Sorenson is director of product management for Ecosystem and Platform at Puppet.

Learn more