Get your time back by getting rid of unused modules with Dropsonde
Get rid of unused modules and get your time back
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!
If you relate to this, you likely won’t be surprised to learn that one of our most common customer requests is for a way to audit modules in order to identify which are no longer in use. Having these extra unused modules in your environments only serves as dead weight. Code deployments, pluginsync, and onboarding new team members all take longer because the cognitive load of understanding the codebase is greater. Each unused module only adds a miniscule amount but, cumulatively, they really add up.
Identifying and removing unused modules can give that valuable time back.
How to identify and remove unused modules
I’d like to tell you about a couple of tools and techniques for identifying and removing unused modules. In general, there are three scenarios in which you’d want to do this:
- Infrastructure administrators looking at the environment want to know which modules can be removed. Sometimes they’re looking at the control repo and sometimes they’re looking at the codebase on the Puppet server.
- Module developers working on their own workstations want to know if there are unused parts of their modules that they can remove.
- Infrastructure teams and code reviewers want to know that all the code being reviewed is actually in use.
Dropsonde is the content telemetry client built into recent versions of the Puppet Server that helps us focus on the modules and parts of modules that people are actively using. It was designed to respect your privacy and will only report information about publicly published Forge modules. As part of this goal, it was architected from the very beginning to generate local reports so that you can see exactly what information is submitted.
One of the metrics that Dropsonde generates is information about the modules installed – which versions, how many nodes they're declared on, what platforms they're declared on – and which modules don't appear to be used at all.
Getting the list of unused modules is as straightforward as ensuring that version 0.0.8 or greater is installed on your primary Puppet server and running a local report on the command line. Follow the detailed instructions on our technical blog if you'd like to try it out.
Puppet Ghostbuster is a slightly different kind of tool that will help you in the second and third scenarios above. It's designed to run directly on module code and thus can tell you more about the individual components – like functions and templates. A developer can run it on their local workstation with the codebase checked out and get a pretty good idea of which stale components can be removed. You'll need to do a bit of configuration for this, such as exporting your PuppetDB credentials as environment variables and specifying the path to your Hiera data.
Because the tool is implemented as a set of puppet-lint plugins, it's also pretty trivial to configure it to run in CI so that pull request reviewers have an idea of how the code they're reviewing is actually used. Check out the project page for more information, or follow Puppet's technical blog on Dev.to to be the first to know when we publish our detailed tutorials.
Good luck and happy codebase cleaning!
Ben is the Community and DevRel lead at Puppet.