Hacker News Reader

Comment by Pewpewarrows | Hacker News Reader

Regarding "Don't use ancient system Python versions" and "Use virtual environments", you can knock out two birds with one stone by just using pythonbrew. It also saves you the hassle of rolling your own deb/rpm if a package doesn't happen to exist.

Also, Chef/Puppet aren't "alternatives" to something like Fabric. Use the former for server provisioning, and use the latter for actually kicking off the deployment process. Trying to shoe-horn the finer deployment steps (git checkout, tarballing, symlinks, building the virtualenv, etc) into Chef was a nightmare every time I tried. Those tasks are better suited for Fabric's imperative design. Plus you can just run any Chef commands from Fabric itself, or use something like pychef for finer grained control. It's a win/win.

View on HN

Fabric seems to be the most popular deployment tool, yet the author advises against it without giving any reason why.

I'd love to see some proper detail in the article around why.

And not in the vein of "Chef/Puppet are better", but more along the line of "here's what can go wrong with Fabric".

Fabric is an invaluable deployment tool, but you have to know its boundaries for what it was intended.

With Fabric you tell what to _do_ and with Puppet/Chef you define what the result should _look_ like.

You define how a server should look like and it can make sure its true for 1000 servers. Or 10000.

It’s not about Fabric vs. Puppet, but how to use both in the most efficient way.

I find the line between when to use fabric and when to use puppet/chef is needing the permissions of a more privileged user.

I prefer to deploy applications in the home directory of a dedicated user account with minimal privileges, and use fabric for installing updates and running application tasks.

OTOH, I'd prefer to be using puppet for creating the user accounts, managing the installation and configuration of PostgreSQL, putting app configuration in a safe location, and so on.

This comes down to my (maybe antiquated?) view of having multiple applications running on a single server.

That’s exactly how we do it too. The only difference is that we don’t install the app using Fabric. Instead, puppet installs the deb with the app into the directory.

Maybe I should add a “running apps as root” anti-pattern, but this its 2012 after all, everyone should know that, right? :-/

It would be fantastic if someone were to write a tutorial how to deploy, for instance, a simple Flask+MySQL or Django+PostgreSQL application using these tools. I'm at a loss as to where to start.

http://ontwik.com/python/django-deployment-workshop-by-jacob...

> Those tasks are better suited for Fabric's imperative design.

Yes they are, but IMHO not on the target servers.

I use Fabric to build DEBs that get deployed by Puppet. I prefer to have no build tools on target servers, YMMV.

DEBs for your own project files, or debs containing built python modules that the server needs to run those project files?

If the latter, how well does that mix in with virtualenv? or do you just avoid it entirely?

I’m the dude that wrote article, so like it says: Own stuff + deps.

Your can re-initialize a virtualenv to fix it by simply running virtualenv again.

But pinky swear I’ll write the second article. ;)

Get on it! :) I really enjoyed the article and want to know more of your magic.

Fabric isn't normally deployed on target servers though - it connects to them through SSH.

That’s not what I meant: If you build your virtualenv on the target server, you need build tools like GCC or development files like libpq-dev. I prefer to have as few stuff on servers as possible.

Thanks - that does sound like a big advantage of the deb / rpm route. Plus you don't really want your app servers spending their CPU time compiling.

That’s a plus too. An “aptitude dist-upgrade” is really fast.

Yes, but unless rpm/deb works with softlinks, it is not atomic right? Do you do anything before/after dist-upgrade or is it included in the pre/post install script?

For example, for our deployment, we rely on softlinks and uwsgi robust reload behavior to avoid losing requests. I've seen many devops who were using hg update/git update as a way to "deploy" (arg!), but I'm not sure about the behavior of deb/rpm.

You can do whatever you want inside of the post-install hooks which are just shell scripts. Including any kind of soft link black magic. :)

And you’re right: replacing files of a running application can lead to all kind of weirdness. I’d even prefer to lose some requests than to risk that.

   > [...] you can knock out two birds with one stone by just using pythonbrew

Would you recommend using pythonbrew on a production system?

Reply on news.ycombinator.com