Fabric enhancements

[jerivas]

My overall goal with this PR is to help developers with none or minimal sys-admin knowledge get Mezzanine sites deployed following best practices. I've tested all new features and made sure existing ones were not broken.

Enhancements over the current fabfile:

• Specifically designed to host multiple sites on the same server.
• Vanilla gunicorn is used instead of the the deprecated gunicorn_django.
• You don't need to host your repos in external sites (GitHub, Bitbucket). The contents are transferred directly from your dev machine to the server.
• You can upload files to the server via rsync instead of git or hg (in case your project is not under VCS).
• You don't need to know which port Gunicorn is going to use, because the connection from Nginx is to a socket file.
• Operations using sudo only require you to type the password once.
• Invalid requests (hosts other than ALLOWED_HOSTS) are blocked on Nginx level.
• Static files are set to expire after 30 days in browser cache (best practice).
• Deployment settings have been moved to local_settings.py for security concerns (they shouldn't be tracked by VCS) and to make sure SECRET_KEY and NEVERCACHE_KEY are in scope.
• Locales are generated for every new site, instead of once per server.
• Added a bunch of comments and updated docstrings to make the whole fabfile more "didactic".
• Expanded instructions and mini-tutorial in the Deployment section of the official docs.

[AlexHill]

Though I don't use the fabfile (I like uWSGI) it's fantastic to see this getting attention. Good job Eduardo.

[stephenmcd]

Why is this hard-coded? I think the common case would be to leverage the number of cores on the machine. Perhaps we can have it default to that, and overideable via a setting.

[jerivas]

In my experience you usually have access to 8 or 16 cores but as little as 512Mb or 1Gb of RAM in a VPS. When running multiple sites you end up with a bunch of workers that eat up your memory. However, single sites probably don't have this problem. I'll add the setting as you suggest as it seems a nice compromise.

[stephenmcd]

Looks good overall, I just left some questions inline.

Once we're happy with everything, can we squash this all into one commit? All the commits listed above will end up in the changelog otherwise.

Thanks a lot Ed!

[jerivas]

Thanks for the feedback, Steve. I'll go over all your points and make some tweaks later this week (hopefully).

[jerivas]

Oh, and yes, I'll squash the commits into one when we're done. What would you like it to say?

[stephenmcd]

Thanks for all the answers Ed, they all make sense. As for the commit message, just a brief description of the enhancements I guess.

[jerivas]

Okay, I addressed all concerns and ended up removing a good deal of unnecessary changes/additions, so thanks for the sharp eye, Steve. Let me know if we're good to go and I'll squash all the commits.

[jerivas]

Also, let me know if you'd like me to update the docs. As I see it, all that needs to be done is update the settings code block and Fabric tasks descriptions. I would also like to propose we include a mini "tutorial", because the current reference might not be enough for complete newcomers. I was thinking on something like this.

[stephenmcd]

Thanks Ed. The mini tutorial is a great idea - many people have complained about the lack of docs on using the built-in fabfile.

[jerivas]

If a user doesn't specify a number in this setting, it'll default to the recommended cores*2+1. You can see it gets injected in the right place in gunicorn_conf.py.template.

[jerivas]

Ok I squashed the commits and left only two: one mentioning the fabfile changes and the other one mentioning the doc changes. I had to pull from master and I'm not sure of how to squash that last commit, so any pointers are appreciated.

[stephenmcd]

Thanks Ed!

I use mercurial for everything (which gets mirrored via git on here) so I can't really help there.

One extraneous commit message isn't too big a deal though.

[fedelibre]

I think you should rebase master in your branch to have your commits on top and then: git commit --amend To add your last change to the last commit

[jerivas]

Thanks Federico. Rebasing instead of merging was the solution. Now we have a squeaky clean commit history.

[stephenmcd]

All merged - thanks again Ed for the huge effort.