[CentralOH] Kokki, or, Server Management

[Austin Godber]

After sleeping on it and rereading your message Issac, I had the following
thought.  If it is acceptable to constrain yourself to Ubuntu on EC2 I would
look at the provisioning stuff thats already built into Canonicals Ubuntu
EC2 AMIs:

https://help.ubuntu.com/community/CloudInit

It seems simple enough that you would only need to dedicate a little time
learning about it.  Its built right into the image.  The cloud-config
section will save you from having to script really common things like
apt-get update and package installs.

Check out this and other examples in the same directory:
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/annotate/head:/doc/examples/cloud-config.txt

This buys you the flexibility of custom scripts with a bit more structure
that should simplify things in the long run.  If you end up doing a lot of
config file munging though it could get messy.

Austin

On Fri, Nov 12, 2010 at 7:21 PM, Austin Godber <godber at gmail.com> wrote:

> I have been playing with Chef quite extensively for the last three weeks.
>  Its definitely capable and the combination of the "knife" command line tool
> plus the centralized server are very compelling.  I think I have just about
> fully automated deploys of the Crunch.io dashboard (apache+wsgi) at this
> point.  Though for smaller numbers of servers I might agree with  Morgan.
>  Though I think getting good at chefs templates and attributes could be
> really flexible once you've got the learning under your belt.
>
> After you, Isaac, talked about Green Unicorn I thought I would try
> switching to it, so I may be writing a chef cookbook for it.
>
> In my mind, Kokki's python implementation is not a strong enough draw to
> give up the /relative/ maturity of chef.  If its a simple reimplementation
> for pythons sake without truly trying to improve on chef it would really be
> pointless for me.  Chef has been really quite comprehensive so far.  I think
> I would spend too much time implementing config management if I used Kokki.
>  I have already implemented enough brittle config management.
>
> Maybe if I get ambitious tomorrow (I think I have all my stupid leaves
> raked) I could do the green unicorn + nginx + postgres implementation I have
> been thinking about in chef and show you how it works.  I might be drinking
> the cool-aid though.  Granted, I have a good perspective for thinking about
> these sorts of things and I think chef definitely has legs in a good number
> of situations.  Actually, I could keep talking here ... but I won't, maybe I
> will just show you guys when I do my presentation.
>
> Austin
>
>
> On Fri, Nov 12, 2010 at 11:28 AM, Issac Kelly <issac.kelly at gmail.com>wrote:
>
>> Cool, thanks Morgan.
>>
>> Yeah, I was thinking that at least the beginning stages could be done
>> pretty easily with fabric and [libcloud][1]
>>
>> Austin, do you have any words of wisdom here?
>>
>> [1]: http://incubator.apache.org/libcloud/
>>
>>
>>
>> On Fri, Nov 12, 2010 at 10:15 AM, Morgan Goose <morgan.goose at gmail.com>wrote:
>>
>>> Issac,
>>>
>>> Interestingly enough, that project was started in the #fabric room on
>>> freenode
>>> and has a room a few months ago IIRC.  It's utalizing fabric as it's
>>> underlying
>>> communication library, and ends up being a loose set of functions to
>>> "organize"
>>> some fabric stuff into good bits for package management.
>>>
>>> I've not used it, and most likely wont, as I feel a one time start script
>>> like
>>> that can be implemented with a good use of a cloud api provider, and some
>>> simple lines of bash for the apt-gets.
>>>
>>> If you pop into either channel I think bitprophet (the main fabric dev)
>>> uses
>>> some cloud'y stuff. And the kokki dev may be lurking in there, or at
>>> lease in
>>> the #kokki room.
>>>
>>> goose
>>>
>>>
>>> On Fri, Nov 12, 2010 at 09:43:30AM -0500, Issac Kelly wrote:
>>> >    I finally got all of my new projects switched over to fabric + git
>>> for
>>> >    deployment. �The big missing piece now is actually setting up the
>>> box.
>>> >    There seem to be a few big projects in the FOSS world (Puppet and
>>> Chef are
>>> >    quite popular in ruby) and then there's this outlier that, even from
>>> my
>>> >    Python friends I've heard noting about ([1]
>>> http://samuelks.com/kokki/)
>>> >    have any of you used this? �What do you use for deployment
>>> management or
>>> >    server management in general?
>>> >
>>> >    My needs are generally very very basic:
>>> >
>>> >    ) Fire up an instance of Ubuntu (Latest LTS) on
>>> [Rackspace|AWS|Slicehost]
>>> >    ) Add general dev tools (build-essential, git-core, svn, mercurial
>>> >    ) Add my Python toolchain (python, virtualenv, virtualenvwrapper,
>>> pil)
>>> >    ) Add Postgres [sometimes GDAL, PostGIS ...]
>>> >    ) Add�psycopg2
>>> >    ) Add nginx // supervisord
>>> >    ) (And now, run fab locally to deploy something)
>>> >    I would like to automate everything except the last step
>>> >
>>> > References
>>> >
>>> >    Visible links
>>> >    1. http://samuelks.com/kokki/
>>>
>>> > _______________________________________________
>>> > CentralOH mailing list
>>> > CentralOH at python.org
>>> > http://mail.python.org/mailman/listinfo/centraloh
>>>
>>> ---end quoted text---
>>> _______________________________________________
>>> CentralOH mailing list
>>> CentralOH at python.org
>>> http://mail.python.org/mailman/listinfo/centraloh
>>>
>>
>>
>> _______________________________________________
>> CentralOH mailing list
>> CentralOH at python.org
>> http://mail.python.org/mailman/listinfo/centraloh
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/mailman/private/centraloh/attachments/20101113/cc5d7815/attachment.html>