On Jun 14, 2012, at 10:18 AM, Alec Koumjian wrote:
You are completely incorrect about Salt. It is designed specifically
for managing a large network of machines and making scaling easy.
Alec thanks for pointing my misquote and yes, Salt is a tool designed
to do what Chef or Puppet does.
My point was for a simple server or two that all these "distributed
remote execution system" most likely are an over kill at that point
for this person.
I think there is 2 layers of conversation going on here.
One is how add some automation to "a server" vs spinning up lots of
servers.
-Kevin
On Thu, Jun 14, 2012 at 10:14 AM, Kevin LaTona
<[email protected]> wrote:
Personally I am all for automation and don't care what language a
tool might be written in if it solves the problem.
And at this point I would think it's fair to that say that comparing
Chef or Puppet to Fabric or Salt is an apple to orange comparison.
It looks to me that Chef and Puppet's target market are geared at
much larger install tasks than what Fabric or Salt can do today.
So getting back to the original poster's question then.
I would say some thing like Fabric or Salt could easily help a
person get "a Django server" going with a shorter learning curve.
And when the time comes to spin up 10, 100 or 1000's servers that
Chef or Puppet might solve this problem better.
-Kevin
On Jun 14, 2012, at 9:18 AM, Andrew Haydock wrote:
@John DeRosa
This is why I hate talking about Puppet and Chef...and probably
isn't suited for a Python board. In most cases it comes down to a
personal choice and how you like things implemented and coded. Some
groups end up using Puppet, some end up using Chef (personally I
know more that used the former rather than the latter - but mileage
will vary). Try both, use the one that fits your situation better.
Don't blindly use one because someone else uses it. Both have
management systems have traction, both are effective and both have a
large presence in the IT community. Try them both and choose for
yourself.
But back to task and the original poster - you have quite a few
options. Let us know what you choose and your impressions!
On Thu, Jun 14, 2012 at 8:34 AM, Kevin LaTona <[email protected]>
wrote:
On Jun 14, 2012, at 7:54 AM, John DeRosa wrote:
I would enjoy such a talk. I've been puzzled about Chef vs. Puppet
-- I don't understand why Chef is the zeitgeist de jour, over using
Puppet.
A wild guess would be that Chef is better at marketing and is
locally based vs Puppet which is based out of Portland.... hard to
say for sure.
Puppet is having a 3 day training class June 25-27 here in Seattle.
http://puppetlabs.com/events/seattle-puppet-master-training/
Both Chef and Puppet are VC funded.
While Fabric, Salt and Paramiko are pure open source projects.
Which says a lot about why Chef and Puppet are talked about so much.
But they are both Ruby based vs Python.
-Kevin
John
On Jun 13, 2012, at 4:39 PM, Kevin LaTona wrote:
Would any of you folks that have used these tools considering doing
a SeaPig meeting to discuss your in's + out's / impressions about
the various tool options?
Maybe we could do a panel style discussion meeting as that would
allow us all to explore the topic without the speakers having to do
tons of prep work.
I would be happy to the moderator of the panel if this idea comes
together.
Since Chef is locally based I am sure I could get someone from the
company to show and talk about their product.
While Chef is nice and does a lot.
It makes sense that for some Python people they might want to be
using something like Fabric or Salt or even Paramiko.
Unless of course your fluent in both Python and Ruby that is and or
are not doing all ways doing a complex install etc..
What do you all think?
Any interest in this topic?
Any takers to be part of the panel?
If so, email me directly and let's see if we could put this together
soon.
-Kevin
Kevin LaTona
STUDIO SOLA
Web | Mobile Development
Seattle WA USA
On Jun 13, 2012, at 3:18 PM, Leo Shklovskii wrote:
At EnergySavvy we use a combination of Fabric and Chef.
Chef is fantastic for setting up the server and environment
(virtualenv, uwsgi, nginx, databases, etc) but isn't quite the right
tool for deployment - it can be heavyweight with abstractions that
don't really make sense. Never mind having to write Ruby to make it
go.
Fabric is great as a lightweight layer to build your deployment
system on. We've followed some of the patterns Capistrano does
(individual release directories, symlinks) and have had a great
system over the past few years.
I don't know what your needs are around the CMS - but if they're not
super proprietary, I highly recommend taking a look at Mezzanine - http://mezzanine.jupo.org/
In addition there's also a Django Seattle group that covers a lot of
these issues and has a number of people with significant expertise
in running and deploying Django - http://www.djangoseattle.org/
--
--Leo
Toby Champion wrote:
I'd recommend using Fabric over Chef if your application is in
Python. That's because you can use your application code, either
some of the Django project itself or your libraries, from within
Fabric. I've found this useful for testing and diagnostics. I've
used it recently for throwing fake data at an XMPP server, by using
a library that's used by the Django app directly from Fabric. You
can do this sort of thing by writing Django management commands, but
for quick and dirty work (often required of start-ups), it's easier
from Fabric.
Also, it's one less language to be programming in every day.
Toby
On 6/13/12 1:53 PM, Adam Feuer wrote:
On Wed, Jun 13, 2012 at 12:39 PM, karen<[email protected]> wrote:
There's Paste, which
doesn't sound ideal.....what else should I be looking at?
It's not Python, but it's really good for this: Chef
http://www.opscode.com/chef/
It has a good community and a lot of pre-built recipes (scripts). I've
used Fabric and Chef, I count those big advantages over Fabric.
More info:
http://www.opscode.com/blog/2011/05/23/deploy-django-cms-with-chef/
http://wiki.opscode.com/display/chef/Build+a+Django+Stack
-adam
