Flask + Nginx + Gunicorn(on a Vagrant box) | Hacker News Reader

Flask + Nginx + Gunicorn(on a Vagrant box)

samrat.github.com

76 pointssamrat19 comments

One of the biggest strengths for Vagrant is Chef (or Puppet if you prefer). Anything that requires "apt-get *" as part of your instructions after "vagrant up" and you're just doing it wrong.

Check your Vagrantfile and associated recipes into git. Then it's just "git clone; vagrant up"

The benefit of this is that you can share your stack by having someone else just git clone your stack. Rather than a blog post, we'd be looking at your chef recipe. I'd much prefer that.

Thanks for the feedback. I use Puppet too, but avoided it in the post to simplify it for the reader. Maybe I'll write a follow-up and include Puppet as well.

Please write this follow-up.

I've known about Puppet for a while (Chef is new to me) and I've yet to see a tutorial here on HN on how to get up and running with either.

How big is the performance hit from the virtualization in your experience?

A few things:

- If you're using bash to install dependencies, it might make sense to stick it in a shell file and run as a provisioner on `vagrant up` [1]

- You can set the NFS shared folder for your working directory to be anything you want in your Vagrantfile, eliminating cp'ing files. [2]

- `pip freeze` catches everything pip has installed, while you really only need Flask, virtualenv and gunicorn in your requirements. [3]

As people have said, Chef and Puppet will help with all of the above and the configuration of nginx, which is awesome. If you use a provisioner, when it comes time to deploy to an actual server, you'll have less manual work to do.

It also has the added benefit of heading towards dev-prod parity, something Vagrant can help with a lot.

[1] http://vagrantup.com/v1/docs/provisioners/shell.html

[2] http://vagrantup.com/v1/docs/nfs.html

[3] http://www.pip-installer.org/en/latest/requirements.html#fre...

Can anyone comment on the usefulness of Vagrant over distributing your own virtual box images?

edit Found this to help answer my own question:

http://www.jedi.be/blog/2011/03/28/using-vagrant-as-a-team/

I haven't used Vagrant, but in the past I did write a bunch of scripts using the Virtualbox CLI and puppet to automate creation of multiple virtual machines based on the contents of a few .ini files. Vagrant appears to tackle that same problem-- whether it's more effective or not I can't say. Though Vagrant is definitely more featureful than what I'd cobbled together, I'm not sure how much more valuable it would be to me personally. But having an organized, self-documenting, repeatable way to generate a serverlike infrastructure on your development machine can be very useful (if you don't have extra actual servers lying around to play with, anyway)

don't `apt-get install python-virtualenv` use `pip install virtualenv` because `pip` installs latest version, else you are under distro's package maintainer's mercy for update. After `python setup.py publish` only distro's package is updated.

EDIT: Using pip can simply solve py3 and py2 specific features.

There's an argument there - do you want to be at your distro's security update mercy, or have to remember/have two separate sets of security patch processes to run through?

Thanks, I've updated the post.

gunicorn is nice for starting up a quick WSGI webserver. I prefer uwsgi when integrating with nginx. uwsgi's performance is pretty incredible.

Not to mention a lot of other useful features if you don't mind becoming dependent on it.

Would you mind elaborating on some of the useful features you like about uwsgi? Or why becoming dependent on it is (presumably) not-ideal?

Yup, would be very interested to hear what other neat stuff other than emperor mode you can do with uWSGI.

Why whould anyone spend time on this deployment options for the various python web development frameworks instead of actually doing web development?

This is one area where python lacks, and that you need

Because in IAAS and virtual hosting, you need to do this on your own.

What stack are you using where deployment options are a moot point? (Note: Heroku isn't just Rails, it supports Python as well now)

AppFog supports Python and even has a flask jumpstart, you can have the same flask hello world in 30s at appfog.com

My point was that DrCatbox was implying that Python as a language forces that user to jump through all of these hoops for deployment. This also implies that there are other languages where deployment is a moot point. Deployment is not a moot point just because there are services that will make it easy, and I wouldn't say that the existence (or not) of a service that makes deployment easy is a strength (or failing) or Python as a language. It's like saying that a hammer is lacking because no one has invented toolboxes yet.

Reply on news.ycombinator.com