Puppet for DevOps: Why you should consider using it

Why you should consider using Puppet for DevOps

This is our first article about DevOps. You might have noticed that HeySupport provides DevOps services to automate the software life cycle, but what is DevOps?

DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

It’s the combination of cultural philosophies, practices, and tools that increase an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

The Role Puppet in DevOps

Years before we have system administrators used shell scripts to run our servers.

We still use them—but the method doesn’t scale. Even the best sysadmin 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.

Automation helps you move faster without sacrificing stability or security. Now is the time to take advantage of automation and proven practices to drive your team — and your deployments — forward.

From development to deployment, Puppet Pipelines automates software delivery.Puppet Enterprise lets you deliver infrastructure changes faster, release better software, and do it all more frequently with confidence.

Operations rely on visibility. Puppet Discovery provides insight into infrastructure resources. Puppet Pipelines ensures consistency across development, staging and production environments, increasing reliability as you decrease cycle times so you can release changes faster. It will give you confidence that your continuous integration and continuous delivery pipeline are consistent and your application is stable, while also allowing you the ability to roll back at a moments notice.

Puppet programming

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.

Manifest destiny

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.

A module’s classesdefined types, and plugins should all be related, and the module should be as self-contained as possible.

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, hostnames, IP addresses, and SSH keys. You can also ask it to gather custom data.

Puppet stores this data in its PuppetDB and Hiera data stores. The master runs on your server as a daemon. The agent also runs on your servers as a daemon.

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.

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. 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.

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.

If you are looking for a professional DevOps company to help you with Puppet for cloud and servers management, HeySupport would be your ideal choice.