

Flask + Nginx + Gunicorn(on a Vagrant box) - samrat
http://samrat.github.com/blog/2012/05/flask-nginx-gunicornon-a-vagrant-box.html

======
lunaru
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.

~~~
samrat
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.

~~~
ashconnor
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.

------
pearkes
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...](http://www.pip-
installer.org/en/latest/requirements.html#freezing-requirements)

------
jwingy
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/>

~~~
Goladus
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)

------
kracekumar
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.

~~~
count
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?

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

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

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

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

------
DrCatbox
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

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

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

~~~
pyre
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.

