The University of Oregon Provides Centralized, Managed Infrastructure to a Decentralized Campus with Puppet

Challenge: Disparate Teams, Unique Requests + a Need for Rapid Innovation

The University of Oregon’s IT campus was decentralized, comprising hundreds of servers with distinct functions. Each of the university's nine colleges handled their own IT needs, while Information Services (IS) provided select centralized services like Active Directory, OpenLDAP, email, and Banner ERP.

IS used Open Source Puppet for automation and configuration management to manage their centralized services. Puppet allowed the team to make changes that were self-documenting, easily modified, and rolled out at scale. Building on that momentum, the campus also undertook a project to improve efficiency by centralizing services like web hosting, security scanning, and virtual machine hosting with VMWare.

Their experience as an early adopter of Puppet led to interest among other departments. But to offer it at scale, they needed to check several complex boxes:

• Provide a consistent, centralized platform
• Accommodate the unique needs of each department
• Maintain stability across the environment
• Respect other departments’ need for autonomy
• Enable, not hinder, rapid innovation

IS's Systems Administration Services (SAS), which provides a platform for more than a dozen teams of admins responsible for their own tech stacks, tried using a pull requests and approvals process to maintain code base consistency. Unfortunately, that process led to a deluge of support requests and slow progress toward their goal of centralized offerings. It also meant that errant code would still impact other departments in their “delegated administration,” or federated model.

Results: Consistency, Centralization + Autonomy with Puppet Enterprise and Continuous Delivery

“Puppet Enterprise was absolutely essential to meet our needs. It offers a nice user interface for various groups to log in and create reports, see the state of their machines, or run tasks related to their infrastructure.”

Matthew Shepard, Associate Director, Systems Automation Services for Information Services, University of Oregon

Watch: How University of Oregon Provides Delegated Administration for Campus Devs + SysAdmins

To achieve their goal of a centralized platform that fulfilled each department’s needs, the SAS team migrated from Open Source Puppet to Puppet Enterprise. The SAS team ended up breaking out each department’s code into their own Git repositories.

“Using Code Manager and Puppet Enterprise, we’re able to partition each team’s code into their own repositories and pull them in dynamically during a deployment action. All their Puppet‐related files live in that repo. This allows us to permission the repositories correctly, so that each group has write access to their own module and nobody else’s,” said Lucas Crownover, a lead Systems Administrator and Puppet architect for Information Services at University of Oregon. “It really was about solving a multi‐tenancy problem.”

Each repo contains that group’s roles, profiles, hiera, and tasks. Role-based access control (RBAC) could then be set at the repo level, giving only certain people or services access to a given department’s infrastructure code.

To make multi‐tenancy as user-friendly as possible, SAS uses Puppet Enterprise for its web UI and RBAC (using the pp_group Facter fact). That gives delegated admins access to create reports, view their infrastructure’s status, and run tasks. They also associate pp_group to a particular Active Directory group so that a given administrator can only run tasks against nodes within their department. Now a user can run a task against any node that includes a role that is within the repository of that group.

To enhance their federation model and improve Puppet code delivery, SAS also chose Continuous Delivery for Puppet Enterprise. Continuous Delivery for Puppet Enterprise improved SAS’s overall quality of service by reducing compilation errors via syntax validation and allowing for testing of new code in isolation using feature branches.

Panel: University of Oregon and Walmart Explain Why They Use Continuous Delivery for Puppet Enterprise

“We’ve gotten a huge amount of praise for the implementation of [the feature_. branch workflow],” said Crownover. “It allows our developers to dynamically create their own sandboxes to test Puppet code without risk of causing group‐wide compilation errors.”

With such a unique environment, Crownover said working with an engineer from Puppet was essential to the two-week rollout: “We were able to get Continuous Delivery for Puppet Enterprise running pretty quickly after finishing the work on our codebase — and it’s still working today."

Some of the more notable improvements the University has seen by using Puppet to support their federation model include:  

• Reporting: Having a central interface for inspecting agent reports is useful when troubleshooting an issue.
• Orchestration: The Orchestration component allows users to run automated tasks. The campus has also been making use of the Orchestrator API with vRealize Automation to trigger automated provisioning tasks.
• Support: While the University reports that they haven’t needed much support, the times where they’ve submitted a ticket have all been “pleasant.” Techs are quick to respond with helpful information.

“While I believe Open Source Puppet is a fantastic product that already serves the majority of needs, there are some huge benefits we’ve gained by moving to Puppet Enterprise,” said Crownover — including RBAC and other enhanced features, time-saving premium extensions, advanced support levels, and more.

Find out which version of Puppet is right for your infrastructure needs by downloading Open Source Puppet vs. Puppet Enterprise: The Complete Guide for free, or request a demo of Puppet Enterprise today:

OPEN SOURCE VS. ENTERPRISE GUIDE   DEMO PUPPET