It’s unfortunately common to have servers in your environment that your co-workers say not to touch. These fragile, antiquated machines only remind you of their existence through tickets and outages.
These are the Drifted Servers (which would also be an awesome name for a band). It’s in your best interest to bring these errant servers back into line using a configuration management tool like Puppet.
What is configuration drift?
Configuration drift is when a machine gets tweaked and changed to the point it no longer matches the original state.
Unruly systems like this cost time and effort to manage and troubleshoot. Bringing them back to a working, stable state requires something to constantly check and make sure they are configured properly, similar to a quality control worker in a manufacturing plant.
How to fix configuration drift with Puppet
Puppet can help you with configuration drift by converting configurations (Files, Registry, Software, and more) into easily readable, understandable, and — most importantly — enforceable code. Here’s how to do it!
Cloud Migration: The Role-Playing Game
A cloud migration campaign takes strategy and knowledge of lore — kind of like a game of Dungeons & Dragons. Join this unique role-playing exercise where experts gameplay through real cloud migration scenarios.
1. Start with information gathering
The first step is finding everything that you can about that machine’s configuration.
Any documentation that you find will be helpful, but there’s a good chance that it hasn’t been updated since the server was deployed. After all, when was the last time anyone checked for documentation updates after fixing a server outage? It becomes an afterthought, which is also the reason why Infrastructure as Code is a much better way to not only deploy but to track your changes and configurations.
Make sure you check ticketing systems as well for incidents and changes regarding that server. Most importantly, take a look at the system to make sure it matches. Lots of changes in an environment happen that are undocumented, and it’s always best to identify those potential “gotchas.”
2. Build a replica
Once you have all of the configurations identified, it’s time to translate that knowledge into code and build a machine that works exactly like the original (without the freaky issues).
Start with the most basic options and work your way to more complex and specific nuances. You may notice that not all of the configurations are necessary to the working state, and this is natural. Bandages are placed on wounds, and you’re building a new body. (Frankenstein would be proud.)
Chances are, if this isn’t your first time using Puppet, you already have a set of base configurations that you can reference and reuse instead of re-inventing the wheel. If not, congratulations! You are now creating them for all of your future builds too. Recycling is the key to saving time and setting standards. And speaking of standards, this brings us to our next step.
3. Attempt to standardize
Most builds that are prone to issues tend to not get touched often, which means out-of-date software that will need to be upgraded.
Translating configurations to Infrastructure as Code allows you a special bartering chip for your department. Specifically, the ability to update, upgrade, and change system software and operating systems to match stability and security standards. The less software you need to deploy, the easier the environment is to manage and fix.
Think about how easy a mechanic’s job is if they only have to deal with one manufacturer and one model of car. Managing infrastructure is the same way! Just make sure that your new standard versions still work with the application or platform.
Get the Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.
4. Test, test, deploy
Since your code will become the defacto standard for managing and redeploying the server, make sure it works! Keep testing with every revision — and ensure that the system works immediately after deployment with no additional configurations. If it doesn’t, find out why and make changes to your code.
When all is said and done, and you’re ready to implement, you’re going to have to decide on whether you’ll apply your code to the existing system or if you’re going to replace it with a new one. Either way, rejoice! . . . And kick that old system to the curb.
5. Reuse what you’ve created
Now that your machine is back online and won’t be causing you any more headaches, it’s time to start over with another machine.
There’s no way that this is the only machine that needs fixed. Like before, start with information gathering and move on to the next steps. Take what code you’ve made and start re-applying it to the other systems in your enterprise.
It’s important to your department’s bottom line — and your mental health — to bring in the reins on runaway servers. Using Puppet, slowly and surely you’ll find yourself with a better infrastructure to work with, fewer problems to resolve, and more time to shift from reactive to proactive.
Be a master of Puppet
Ready to become a master of Puppet? (Assuming you’re not looking to become a ventriloquist or start a heavy metal band, you’ve come to the right place!) Learn how Puppet works and when to use it in ACG’s beginner-friendly Introduction to Puppet course.