Flask + Nginx + Gunicorn(on a Vagrant box)(samrat.github.com)
samrat.github.com
Flask + Nginx + Gunicorn(on a Vagrant box)
http://samrat.github.com/blog/2012/05/flask-nginx-gunicornon-a-vagrant-box.html
6 comments
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.
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...
- 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/
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.
EDIT: Using pip can simply solve py3 and py2 specific features.
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.
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
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.
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.