On Tue, 20 Mar 2012, Miles Fidelman wrote:
[email protected] wrote:
On Tue, 20 Mar 2012, Miles Fidelman wrote:
Tom Perrine wrote:
I've used both cfengine and Puppet over the years, and have met people
who have been successful with Chef. What has worked for others in
their specific environment may (or may not) work well for yours.
What I keep coming back to is that they seem like overkill for what I'm
doing right now - and carry with them the need to:
- install a layer of infrastructure
- work in yet another language (bash and sed do pretty much all I need,
why have to wade through recipes written in Ruby or Python or whatever)?
- do I really need to deal with lots of recipes to ultimately execute a
few install and config. statements (who really needs the overhead to
execute "apt-get install" or "./configure; ./make; ./make test, ./make
install") - at least for the stuff I'm managing now, the details are in
site-specific configurations, and it seems like a lot of getting that
right with Chef (or whatever) involves wading into and understanding how
the individual recipes work (or writing them)
Right now, I'm managing a small high-availability cluster (essentially a
mini-cloud) with one VM for email and list handling, another for managing
backups, and several for development. Where I expect that something like
chef, or puppet, or whatever will be helpful is in about 6 months when we
might be worrying about putting some code into production, and (fingers
crossed) scaling services across multiple VMs, some of which might be
running on AWS or elsewhere in the cloud. Right now, though, it's more
about documenting and streamlining management of the small cluster -
partially to simplify handoff to someone else to administer, partially to
simplify disaster recovery or hardware migration.
If you know you wnt to automate a bigger cluster later, take the time in
development with your small cluster to learn the tool and work through the
configuration.
Well sure, but I see these as different use cases, with different problems,
and probably different tools.
I NEVER expect to replicate our development or administrative environments to
any serious scale - these are going to remain fairly customized, and in the
case of development there are likely to be lots of "throw away" VMs as we
experiment with different plumbing and experimentation. Cleaning up
processes yes (to simplify disaster recovery), lots of automation doesn't
seem to apply. If I were starting from scratch, I'd probably start with
Ganetti (a really nice tool from Google that they use to manage small,
internal clusters, used for administrative applications - though it has some
subtleties that get in the way of doing a completely automated failover). As
I'm not starting from scratch, I just want to get existing shell scripts
under configuration control, and automate manual steps where that's easy
(mostly re. IP address and DNS record managment when creating new virtual
machines).
For production, on the other hand, if we're fortunate, the focus will be on
deploying lots of cookie cutter nodes - each with a fairly constrained
environment - and that's where the combination of an orchestration tool + a
configuration engine seems to offer a lot of leverage. And, yes, I expect
we'll want to wire together a small cluster first, and get the tooling right
before scaling out. It's just that I don't expect this cluster, or
associated procedures, to look anything like our inward facing stuff.
Actually, development and QA is where I see some of the most value in the
complete automation. If you can provide a self-service web page where
developers can click a few selections and get a complete machine (and
destroy an old one) in a few seconds, you have a _very_ valuable tool.
by the way, in case it's not clear, the config management tool should be
configuring your VMs, not just your physical systems.
far too frequently dev and QA machines accumulate 'cruft' left over from
prior installs and tests that end up making new tests work accidently,
causing problems when the code gets into production where such cruft does
not exist.
now I don't think that this means that you need to go to the extreme that
some people do of making the recipe for one app/package try to cover every
possible combination of that package and everything else. I try to work at
a much more granular level where a server seldom has as many as a half
dozen 'app bundles' on them and each app bundle may install a bunch of
packages. If you need systems to do a lot of different things, use a bunch
of VMs, each configured to do one thing (or a small number of things,
hopefully related) instead.
David Lang
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
