Mastering Puppet: Storage Configuration and Automation

Written by:
Ed Balduf

June 30, 2016

Automation Puppet

I think there are two schools of thought on managing storage with a tool like Puppet. Let's set the stage first, and then we’ll explore how each of these plays out and the ramifications. The first school of thought is to keep the existing storage-centric workflow and simply use Puppet as a new tool that makes the workflow faster and more documentable. The second school of thought is to change or use a whole server (or VM or container) provisioning workflow. In the second case, we smash the line between storage and servers and think about the process holistically.

In many IT shops, there is a separation of storage and server management, sometimes by conscious design, politics, or happenstance. In our first school of thought, we use Puppet as a tool for the storage group to manage the storage systems and provision storage on those systems. The Puppet “device” construct allows a manifest to define the storage environment, and that definition is then pushed to the storage systems. The storage definition manifest(s) can be revision controlled and audited and by definition represent the environment at that point in time. Unfortunately, the Puppet device construct is fundamentally asynchronous to the remainder of the environment (servers).

A better way to manage an environment is holistically from an application or server perspective, which leads to our second school of thought. Here the storage, server, operating system, network, database, applications, and anything else necessary are configured as one manifest(s) chain. In this case, the framework that applies the manifest to the server also reaches out to the storage infrastructure to provision what it needs as part of the process of building the full stack.

As an example, consider the requirements for provisioning a database server: Why should there be a process executed by the storage admin and then some kind of a handoff to the server process? In a single process, the server database provisioning process can reach out to the storage, allocate what is needed, mount that storage, configure the logical volumes, create the filesystem, and mount the storage for the database. All of this can be completed in one configuration. It is assumed that the manifest would be continued and include the database installation, configuration, and any applications. One process gets the whole stack stood up. The one process can still be audited and revision controlled with tools like Git, but that will eliminate the clumsy steps between various groups that generally leads to longer provisioning times and greater likelihood of errors.

To read more of this article, please sign up to join the SolidFire learning center.

Sign up
request a demo
contact sales