What is Puppet? And why should you consider it for your cloud and servers?
Puppet is one of the great DevOps programs for managing multiple servers.
Once upon a time, we system administrators used shell scripts to run our servers. We still use them—but the method doesn't scale. Even the best sys admin is too busy to constantly modify scripts for hundreds or thousands of ever-changing servers and their system configurations.
DevOps applications can solve this problem by automating server setup, program installation, and system management. One of the most important of these programs is Puppet.
Puppet, along with Chef, are the most popular DevOps programs, according to RightScale's 2016 survey of DevOps trends. Puppet is used by 42 percent of businesses that use DevOps methodologies, followed closely by Chef with 37 percent.
Puppet is an open source software configuration management and deployment tool. It's most commonly used on Linux and Windows to pull the strings on multiple application servers at once. But you can also use Puppet on several platforms, including IBM mainframes, Cisco switches, and Mac OS servers.
Like other DevOps programs, Puppet does more than automate system administration. It changes the human workflow, and enables developers and system administrators to work together. Programmers can write, test, and launch applications without waiting on Ops staff to deliver the resources needed.
For example, Microsoft and Puppet recently partnered with the RISCO Group, an Israeli security project company, to create a Puppet and Azure Resource Manager-powered self-service web portal. The result, says Ido Vapner, RISCO Group's head of DevSecOps and technology, is a development workflow that enables the company to "provision an entire environment with a single click" instead of it taking "a week to build a new environment."
"The entire project helps us by saving over 200 hours per month," Vapner says.
Puppet, available in both open source and commercial versions, has its own language, the eponymous Puppet. As with other DevOps programs, Puppet automates changes, eliminating manual script-driven changes. However, Puppet is not simply another shell language, such as Windows' PowerShell or Unix and Linux's Bash shells. Nor is Puppet a pure programming language, such as PHP. Instead, Puppet uses a declarative, model-based approach to IT automation. This enables Puppet to define infrastructure as code and enforce system configuration with programs.
In Puppet, the configuration management tool syntax is decoupled from the underlying operating systems and applications' syntax. This enables you to define high-level concepts such as user, application, and service. Puppet then translates these higher-level concepts into the operating system and software setup instructions.
Puppet models everything as data: the node's current state, the desired end state, and the actions needed to move from one to the other. Each Puppet-managed server instance receives a catalog of resources and relationships, compares it with the desired system state, and makes changes as needed to bring the system into compliance with the ideal state.
You use these programs to manage all of the software, services, and configuration on given systems, with an end goal of building complete system configurations in code. This is challenging.
Puppet encourages its users to keep this complexity under control by writing code that is reusable, easy to configure, and easy to refactor. The main method to accomplish this is by using Puppet roles and profiles, which separate your code into three levels:
- Component modules: Normal modules that manage one particular technology, such as puppetlabs/apache.
- Profiles: Wrapper classes that use multiple component modules to configure a layered technology stack. For example, you can create a profile to set up Jenkins, the continuous integration application, with its web front end and automated tasks.
- Roles: Wrapper classes that use multiple profiles to build a complete system configuration. With that Jenkins role, for instance, the server must also have such standard roles as a "base operating system profile" and "base web server profile." The former might declare the server must be running Ubuntu 16.04.2, while the latter would state it must use NGINX.
All this—more tools, languages, profiles, processes—may seem as though it adds complexity. In reality, it gives you space to build practical, business-specific interfaces for system configurations. This makes hierarchical data easier to use, system configurations easier to read, and refactoring easier.
Think of roles and profiles as a pattern for creating your Puppet-controlled systems. Expect to change them over time. Do not mistake them for a straitjacket for your servers' layout.
Puppet code is made up mostly of resource declarations. A resource describes a specific element about the system's desired state. For example, it can include that a specific file should exist or a package should be installed.
A Puppet program, called a manifest, has a file name that uses the ".pp" extension. Puppet's default main manifest is /etc/puppet/manifests/site.pp.
Within these manifests are "classes," named code blocks that can be called by other modules. Classes generally configure large or medium-size chunks of functionality, such as all of the packages, configuration files, and services needed to run an application. Classes make it easier to reuse Puppet code and improve readability.
Except for the mainsite.pp manifest, which contains site-wide and system-specific code, manifests are stored in modules. Puppet modules are Puppet's fundamental building blocks. They are used for abstracting the differences between operating platforms.
Each module should have one area of responsibility. For example, a good module addresses installing MySQL but would not include instructions regarding the installation of another program that requires MySQL. The ideal module manages a single piece of software from its installation through setup, configuration, and service management.
But Puppet can do more than contain the desired state of a program's configuration. Using Puppet’s declarative, model-driven language, you can:
- Enable simulated configuration changes before enforcing them.
- Enforce the deployed desired state automatically, correcting any configuration drift.
- Report on the differences between actual and desired states and any changes made as a result of enforcing the desired state.
Deploying with Puppet
Puppet programs provide configuration management services using a client-server approach. Puppet managed servers use Puppet agents to connect with and update their configuration instructions from the Puppet master. Both the master and agent run on your server as a daemon. At a user-defined time, usually every half-hour, the agent pulls down its updated system configuration information from the master.
The Puppet master gathers the agent's configuration data using the Facter command. By default, Facter gathers system configuration data, such as operating system names, host names, IP addresses, and SSH keys. You can also ask it to gather custom data.
You use this model to implement any desired configuration, or "policy," on your Puppet agent servers. The agent issues your module's marching orders to your servers.
You don't have to start from ground zero with Puppet. Many ready-to-run modules can be run as is or used as blueprints.
On Puppet Forge, a community repository of modules, you'll find almost 5,000 ready-to-run downloadable modules. Some have been downloaded millions of times. A 1-to-5 module rating system makes sure you don't try to deploy a dud.
While some modules are unsupported, others come with the Puppet company support. Still others aren't supported by Puppet but have been approved by Puppet. So, for instance, if you want to set up and run an HPE OneView appliance, there's a Puppet-supported module for that job. There are also other ready-to-run Puppet modules for such popular programs as Apache, MySQL, and NGINX.
These ready-to-run modules aren't just for simple jobs. For example, if you want modules for Docker, Jenkins continuous integration service, or even OpenStack infrastructure-as-a-service cloud components, they're available to you.
Pulling Puppet's strings
Puppet comes in two main versions: Puppet Enterprise and Open Source Puppet.
The open source version gives you a good taste for Puppet. It doesn't, however, come with an easy-to-use web user interface, nor does it support enterprise-only operating systems such as IBM AIX or F5 Big-IP hardware. On the other hand, it's easy to install open source Puppet on your x86 servers for trial runs.
Puppet Enterprise also has three major additional features:
- Role-based Access Control enables you to delegate tasks to designated administrators and groups. It integrates with directory services such as Active Directory and OpenLDAP.
- Puppet Server Reporting collects metrics about a Puppet server's health and performance. This includes active requests, request duration, execution times, and compilation load.
- Event Inspection uses Puppet logs to deliver reports on node, classes, and resources changes, giving you an easy view of what's happening on your Puppet-managed servers.
If you find you like Puppet and need more than the open source version can provide, you can try Puppet Enterprise 2016.5 on 10 nodes for free. The latest, current version is Puppet 2017.1, and a trial version can be explored using a Puppet Enterprise virtual machine.
Is it worth it? Give it a try. I think you'll find the savings in developer and operator time alone is more than enough to make Puppet a worthwhile addition to your IT software stack.
Puppet for DevOps: Lessons for leaders
- Puppet applies a continuous delivery model to the software release cycle by automating operations and deployment workflow.
- System administration tasks are saved as manifests and modules. These are reusable configuration construction blocks to speedily create preconfigured servers.
- Puppet has wide industry support across the cloud and DevOps ecosystem. It works with just about every server platform in the market today.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.