Ask Your Question

Converting current system state to Puppet code

asked 2017-05-08 04:05:31 -0500

cookiejc gravatar image

Hi, I am looking at a project which will require several services to be rebuilt. ideally we would like to 'Puppetize' these services at the same time.

These services a largely a combination of windows web, app and sql servers but lacking any detailed build documentation.

Puppet seems great when you know exactly what you want to define / manage but does anyone have any experience of taking a current system state and converting it to Puppet code? With the Puppet resource command it seems there may be a way to automate part of this process but im just not sure where to go from here

Thanks for any advice!

edit retag flag offensive close merge delete


as far as I know you can only know the current system state but I never heard of converting it to puppet code. one way I would suggest is you can write your custom type and provider to do that for you.

Hyder gravatar imageHyder ( 2017-05-08 08:00:34 -0500 )edit

Puppitizing a system is simply creating (puppet) code that defines how your software gets deployed (onto instances, into kubernettes, etc). The process is the same for monoliths or multiple services, you'll just have more 'things' that you deploy with independent services.

DarylW gravatar imageDarylW ( 2017-05-08 09:44:00 -0500 )edit

You can't automate something that you can't do manually. You have to first understand what the current steps are for creating the systems the software is deployed to, and then you can begin automating it

DarylW gravatar imageDarylW ( 2017-05-08 09:45:39 -0500 )edit

Thank you for the replies. I am not expecting to automate the entire process more of a tool or method to assist in the process of reverse engineering an existing installation. I'm sure we're not the only organisation who are lacking documentation for some legacy services

cookiejc gravatar imagecookiejc ( 2017-05-08 10:42:34 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2017-05-08 12:20:09 -0500

smarlow gravatar image

I've got a lot more experience with Puppetizing linux systems so I'll talk about that, but the process is going to be analogous for Windows. Typically the process I follow is to get the OS baseline managed and then try to manage applications afterwards.

For the OS baseline I like to look at the build process and look for everything that gets customized. Those customizations are usually pretty easy to code into manifests to get them managed.

If there isn't an explicit build process then I often look at things which commonly get changed to see if they've been altered. This includes stuff like /etc/ssh/sshd_config, /etc/hosts, /etc/snmp/snmpd.conf, and so on. You can also use the find command to look for files which have been altered after the build date to look for files which may have changes you want to incorporate.

Usually when deploying into a brownfield environment I make sure that all servers are running in noop mode. As more manifests get written we check to make sure that we're not overwriting settings that we want on the end systems. Config file layouts may change due to the way the templates are written (e.g. new headers, the ordering of settings may move around), but the settings that we care about should still be in there. If a setting does get overwritten then you want to incorporate that into the manifest.

For individual applications, if that application already has a well-supported module (e.g. sql server) then I usually start with the defaults on that module, look for anything that it changes and then incorporate those changes to the manifest.

If the application doesn't have a module then I usually try to make a simple module with the install -> config -> service pattern and suck in any applicable configuration that I can find.

It's also worthwhile to spin up a test server that has all of the configuration done via Puppet and see if it can run the applications as expected. This is usually pretty helpful in tracking down some bit of config that you're missing.

Ultimately it's a lot of detective work, figuring out what you want to manage. But thankfully Puppetizing things creates a canonical list of things that you care about, so you'll have it for the future.

Hope this helps give you a starting point.

edit flag offensive delete link more


I concur. I have used a similar process where I run in no-op mode until no changes are reported, and then spin up a test server using the config as you suggested to flush out 'missing' configuration

DarylW gravatar imageDarylW ( 2017-05-08 15:26:12 -0500 )edit

Thank you smarlow, I think the important point from responses on here is that 'Puppetizing' is going to be a process which may be time consuming for each system but hopefully worth that time investment!

cookiejc gravatar imagecookiejc ( 2017-05-09 02:42:02 -0500 )edit

answered 2017-05-09 02:12:38 -0500

ross.murray gravatar image

the Puppet Resource command is fantastic for finding out the existing state of your system and running 'Puppet Resource <resource_name>' is very helpful to identify your existing setup - but it's very important to understand its limitations.

One example:

Shortly after installing Puppet I installed a Forge module for IIS that allowed me to work with Web Applications and their configurations - App Pools, Virtual Apps etc. Simply running Puppet Resource IIS_Site showed me every site on a server and all of its settings. But here's the kicker - it wont show you EVERY setting. It will only show you the settings that it has been told to specifically manage via the Module. And the module wasn't written specifically for my use-case and so every now and then I would come across a component I needed to manage that wasn't covered by the module authors who had their own use-cases. The things you need to know about may not be covered by the module, and if they are - how confident are you that it hasn't missed anything?

Puppet Resource is fantastic to see a large amount of information on your existing configuration very quickly. However don't rely on it being your complete configuration - Puppet can only know about what it's been told to know about.

edit flag offensive delete link more


Thanks for the information Ross that's a very relevant example to us!

cookiejc gravatar imagecookiejc ( 2017-05-09 02:39:59 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-05-08 04:05:31 -0500

Seen: 63 times

Last updated: May 09