Deployment: Difference between revisions

From GNU MediaGoblin Wiki
Jump to navigation Jump to search
(→‎MongoDB setup: in 2.0, journaling is on and preallocates multigigabyte journal files)
(→‎MongoDB setup: does disabling preallocation work?)
Line 14: Line 14:
* little-endian
* little-endian
* more than one server
* more than one server
* speed is more important than reliability, and journaling is off by default (apparently that’s not true anymore, at least in 2.0, [http://www.mongodb.org/display/DOCS/Journaling journaling is on and will preallocate ''gigabytes'' for the journal files], unless you [[Scaling Down|disable preallocation]].)
* speed is more important than reliability, and journaling is off by default (apparently that’s not true anymore, at least in 2.0, [http://www.mongodb.org/display/DOCS/Journaling journaling is on and will preallocate ''gigabytes'' for the journal files], unless you [[Scaling Down|disable preallocation]] (does that work?).)


= Running MediaGoblin's web server and Celery separately =
= Running MediaGoblin's web server and Celery separately =

Revision as of 09:38, 9 October 2011

This page could use a lot of work. For now, a few smaller deployment tips!

Use Virtualenv

Our Development quick start guide recommends using zc.buildout, but this system is somewhat problematic for actual deployments (if a buildout goes badly, buildout removes all your packaging setup and your scripts in bin/ and other things... yuck :\). Use Virtualenv instead. In the future, all our docs will bet set up to recommend using Virtualenv.

MongoDB setup

You should almost certainly run MongoDB with Journaling on if you have a new enough version of MongoDB. (If you don't, maybe you should get a newer version!) Without journaling there's some risk you could lose data that isn't yet written to disk if MongoDB is shut down incorrectly. But see below.

Also, keep in mind the following assumptions MongoDB makes about your deployment environment

Running MediaGoblin's web server and Celery separately

./lazyserver.sh is all good and well for debugging, but probably not for deployments. Instead, you should probably run