You’ve probably been using Puppet Forge modules to manage bits in your infrastructure for years. If you’re like most of us, you’ve gradually added more modules and maybe you’ve lost track of exactly what some of them do and on what nodes they’re declared. You may even suspect that you have modules installed that you haven’t actually used in years…. only you’re not quite certain which modules those might be. I am certainly guilty of this!
As platform engineering continues to rise in popularity, there is a new side effect to watch out for: the people using the internal developer platforms aren't the people who built it. They’re not necessarily familiar with the codebase, they may not know what's powering it behind the scenes – and the platform might even have to contend with malicious users. So how is Puppet evolving to contend with this new challenge?
“Give customers the power to help themselves. Self-service options allow for faster problem resolution while reducing strain on your support teams.” – our friends at ServiceNow Self-service is a crucial component to any DevOps strategy. Many IT organizations still depend on manual and ticket-driven workflows with strong reliance on dedicated teams to make simple and frequent change requests. Unfortunately, these traditional models don’t scale.
We’re pleased to introduce updates to Puppet Enterprise that give infrastructure operations teams the insights they need to manage and protect infrastructure and complex workflows in a simple yet powerful way. With Puppet Enterprise 2021.7, teams gain automatic access control and a host of system insights related to runs and events.
Puppet 6 brought the ability to defer functions to runtime on the agent, and now we've released improvements that make this easier to do. Read on to find out more and to make sure your modules are ready to be deferred.
What is self-healing infrastructure and why do you need it? The first part is easy; it’s exactly what the name implies. It’s a methodology for creating automation that allows systems to identify and repair errors and misconfigurations without any human action. The “why” is a little more complex, but, like self-healing infrastructure, is well worth the effort.
Let's face it: no one likes patching. When I was a practitioner, we always put off patching until it was absolutely necessary. Until a business need – such as updating an application version or support ending for a version – arose, we didn't patch because "If it ain't broke, don't fix it." We all know this is a bad practice; let's remind ourselves why. The longer a system goes without being patched, the more changes will accumulate.
