By Stephen Granger -
I agree with Shane, any configuration management system is better
than none and if you have more than 1 machine it's necessary.
I went the other way and started off using Puppet before it had commercial support (this is not a bad thing). I found it's syntax and class inheritance easy to understand having some OO experience. Having never touched ruby before I didn't find that side of it an issue.
Currently however we are using the new kid on the block, Ansible, http://ansible.cc, http://ansibleworks.com who recently implemented commercial support, again, this hasn't affected the support given or the development process. We started implementing it over 6 months ago and most of the work has involved keeping up with the development changes.
Ansible is very slick and quick to get into especially with it's ability run adhoc commands. It's configuration syntax is based on yaml files, it's written in python and very python friendly. The development behind it now is very fast paced and the community that uses/supports it is very enthusiastic. However the reporting of the state of the machine by default is lacking compared to cfengine and puppet Dashboard/Foreman.
One major concern with configuration management systems (CMS means Content Management System to me :P ) would be is it's syntax easy to get into/maintain? and how will future me or future sysadmins go about maintaining what I've done? How easy can you make it for the others in your team?
+1 Puppet , +.5 Ansible
Some people use Salt stacks too, http://saltstack.com/index.html which has windows support.
Your choice should be made on your(teams) requirements and experience. It's like when you write a script, should I write it in bash, perl, python, ruby... just never tcsh ...
I went the other way and started off using Puppet before it had commercial support (this is not a bad thing). I found it's syntax and class inheritance easy to understand having some OO experience. Having never touched ruby before I didn't find that side of it an issue.
Currently however we are using the new kid on the block, Ansible, http://ansible.cc, http://ansibleworks.com who recently implemented commercial support, again, this hasn't affected the support given or the development process. We started implementing it over 6 months ago and most of the work has involved keeping up with the development changes.
Ansible is very slick and quick to get into especially with it's ability run adhoc commands. It's configuration syntax is based on yaml files, it's written in python and very python friendly. The development behind it now is very fast paced and the community that uses/supports it is very enthusiastic. However the reporting of the state of the machine by default is lacking compared to cfengine and puppet Dashboard/Foreman.
One major concern with configuration management systems (CMS means Content Management System to me :P ) would be is it's syntax easy to get into/maintain? and how will future me or future sysadmins go about maintaining what I've done? How easy can you make it for the others in your team?
+1 Puppet , +.5 Ansible
Some people use Salt stacks too, http://saltstack.com/index.html which has windows support.
Your choice should be made on your(teams) requirements and experience. It's like when you write a script, should I write it in bash, perl, python, ruby... just never tcsh ...
puppet justified their complexity with more effective config management
that was impossible/impractical via other means (ssh, ansible (which i'm
currently leaning towards), etc).
Anecdotes are welcome!
In over 20 years as a sysadmin I've progressed from manually configuring each machine to automating configuration with rsync and ssh to Puppet and, most recently, to CFEngine.
As far as whether or not a config management system is justified . . . my feeling is that if you've got two or more machines to look after then you need a config management system.
Actually, I could argue that if you've only got ONE computer you should still use a configuration management system.
Why? Because a config management system (CMS) forces you to take control of you computer's configuration.
* The CMS ensures your computer is in a known state (so, for example, a package update that replaces a customised config file with a default will have the correct config file put back in place, often without you knowing about it).
* It encourages you to have your config in some sort of revision control system so you have a record of changes to your system and can revert to a previous state if a change breaks something.
* If you have more than one sysadmin it gives you an audit trail so you can see what your colleagues are doing so you don't end up doubling up on work.
These things are useful in their own right but it's when you add more machines to the mix that you really see the advantage. Say you decide to add a second machine to your network. You want it to be more or less the same as your current machine. You don't have enough machines to bother with a PXE boot server and Kickstart file so you just install Linux manually off a DVD. Oh no! You can't get sound to work. There was a PulseAudio config change you had to make six months ago on your other machine, maybe that will fix it? What was that change again? You don't have to worry. Just install your CMS on the new machine and it magically gets configured the same as your old machine.
Time to install a new package? Add it to the CMS package config and it gets installed on both machines. You've just HALVED the time it takes to manage both machines.
Add 1000 machines to your network? It still takes the same amount of time to roll out a new package as it did with ONE machine!
So, my answer to the question "Should I be running a configuration management system?" is "Why *aren't* you running a configuration management system?"
"Can't you just use ssh and some scripts?" I hear you ask. Sure, but what happens if a machine is turned off at the time you send an update out? Do you keep trying it? What if the machine is off for several weeks? What state will it be in when it is finally turned on again? If you're running a CMS it will automatically contact the CMS server and download the desired state and apply it.
Our goal as sysadmins should be to automate ourselves out of the job. If you need to type several commands to achieve a goal, put those commands in a script. If you need to achieve that goal at regular intervals, run the script from cron. If you need to achieve a lot of goals at the same time (like configuring a computer) put your scripts into a CMS.
Sorry, I'm sounding a bit evangelical. :-)
The hardest part about using a CMS is translating your current config system (whether it's manual or some other CMS) into the correct language. My suggestion is to take it in small steps.
Start with getting the CMS to manage package installation. That's a quick and easy one to get working. Don't worry about getting it to install config files or anything, just get the packages installed and then configure them however you currently do it.
Once you've got package management in place you can start looking at making changes to config files. Start with new packages that you're rolling out. You don't have any existing infrastructure in place for them so you can start fresh. When you're happy that it's working you can go through and translate existing configs into the new system.
In my current job I had the luxury of building completely new machines with a new CMS. I installed a base Linux and translated every manual configuration step I made into CFEngine syntax. At the end of it I could get a fully functional system up and running in 15 minutes. It was slow and tedious to begin with because I was learning CFEngine as I went but it has saved me a lot of time in the long run and I can sleep easy at night knowing that my machines are configured exactly as I expect them to be.
Shane.