On 04/25/2013 10:58 AM, John Stoffel wrote:
Phillip> Maybe I'm misunderstanding, but you seem to be implying that
Phillip> Salt is not helping you do anything more than run commands.
Phillip> If so, it's important to note that it can both run commands
Phillip> and manage config ala puppet style. I would actually call
Phillip> this a major advantage, because it allows people who have no
Phillip> configuration management in place to start using a real
Phillip> configuration managment tool and be productive right now, and
Phillip> then gradually work their way into more advanced ways of
Phillip> doing things.
This has been the big issue keeping me from deploying configuration
management at $WORK, because I have to convince all the rest of the
team that it's really worth the hassle and change in mind set.
For me, supporting Solaris 8/10 Sparc/x86_64 systems and a bunch of
RHEL 3/4/5 (mostly 5 now) x86_64 compute nodes, the attraction of
cfengine has always been that it's self contained. I can just drop
the cfengine binaries in place and away I go.
Chef, puppet, etc all seemed to want me to first install python or
ruby or something else that wasn't part of my base systems. This has
changed over time, and esp as I've finally moved away from Solaris 8
in a big way.
Chef introduced the Omnibus installer last year, which improves things
quite drastically on that score. The necessary chef-client and ruby
environment gets installed nicely self-contained in /opt.
I believe, based on developer conversations on twitter, that Puppet is
working on similar right now. Its certainly made life easier here for
deployments of chef to our boxes.
So looking at Salt and seeing that it requires Python is still a
gotcha, but possibly one I can deal with now. But again, it's all
about getting a system in place which I can encourage the rest of my
team to use without causing them undue pain. Yes, sometimes you need
to force the change, but it would be better if I didn't have to.
I didn't have a team to fight against, as it's just me and a jr
sysadmin, just time. The infrastructure is so 'organically grown' that
switching to config management has been a slow process alongside the
usual workload.
I started out by translating our 'standard install steps' wiki page into
a chef recipe, to make initial set-up quick (around 45 minutes+ of
manual work became 5 minutes for chef to do)
Beyond that it's just been chipping away at odd things, like
monitoring. There doesn't have to be a great big splurge to config
manage all the things, it's amazing how many little things make the
biggest pain points, and best impact on the team :)
Paul
Paul
_______________________________________________
Discuss mailing list
Discuss@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
