[lug] CM for a small sysadmin.

Quentin Hartman qhartman at gmail.com
Wed Oct 28 13:21:40 MDT 2015


Yeah, I would go for something very light for that small of a deployment.
Ansible looks interesting, but I haven't used it. My concern with it (and
this may be unfounded) is that like what I found in Puppet, you have to
become an expert in the tool before you can do much beyond what it does out
of the box because of all the boilerplate / structure it forces. Chef and
the like are total overkill, but I like that you have more freedom to do
just do what you need to do when and where you need to do it without so
much ceremony. You might do chef-solo? You get most of chef without any of
the infrastructure. If you know ruby already it's pretty easy to get going.

Honestly, your deployment is small enough that it seems you would do well
to experiment with a few and just pick the one that feels best to you.

QH

On Wed, Oct 28, 2015 at 1:07 PM, Dan Ferris <dan at usrsbin.com> wrote:

> Ansible.  It's by far the easiest of the bunch.
>
> On 10/28/2015 01:06 PM, David L. Anselmi wrote:
> > What's a good CM system (ala chef, puppet, etc) for a single server
> > managed by two or three admins?
> >
> > Take for example, the cluedenver.org server that I happen to manage.
> > It's one server that provides a mailing list and web site.  I don't know
> > what all is on it (apps or config) but I can figure it out well enough.
> >
> > Now suppose that I want to migrate it to a cheaper provider, and/or
> > upgrade it to something more modern.  And I'm going to get someone else
> > to help, whose responsibilities will overlap mine but not entirely (so
> > he might be handling all the drupal setup and I may handle all the mail
> > list setup and we both handle everything else).
> >
> > So as part of this migration I want to capture all the changes we make
> > in a way that lets us know what's been done--so it's easier to
> > communicate changes and to reproduce them if we want to move a service
> > to a different host or rebuild the thing entirely.
> >
> > I think the rebuild process should be:
> > - push a button to create a server in the cloud somewhere
> > - run the CM app to configure it correctly
> > - achieve world domination
> >
> > OK, so before running the CM app maybe it needs to be installed, and the
> > config adjusted to account for new host names or network addresses.
> >
> > Things I do by hand that should be handled by the CM app:
> > - install software
> > - configure complex software like apache, tomcat (with custom apps), etc
> > - add yum repositories and install software from them
> > - create user accounts
> > - configure backups for data that can't be reproduced (like the mail
> > list archives or user files)
> >
> > I don't expect this to need to scale to google size, but maybe there
> > will be 3 or 4 servers and 4 or 5 admins one day.
> >
> > I'm sure this sucks as a requirements document but maybe it's close.  Or
> > you can help me explain what I mean.
> >
> > Thanks!
> > Dave
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20151028/ad896b8e/attachment.html>


More information about the LUG mailing list