aboutsummaryrefslogtreecommitdiffstats
path: root/docs/source/siteadmin/production-deployments.rst
blob: 52563e6ee8b4aea15bb7b9e19c0b5f9ad7be6658 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
.. MediaGoblin Documentation

   Written in 2011, 2012, 2013, 2014, 2015 by MediaGoblin contributors

   To the extent possible under law, the author(s) have dedicated all
   copyright and related and neighboring rights to this software to
   the public domain worldwide. This software is distributed without
   any warranty.

   You should have received a copy of the CC0 Public Domain
   Dedication along with this software. If not, see
   <http://creativecommons.org/publicdomain/zero/1.0/>.

=================================================
Further Considerations for Production Deployments
=================================================

This page extends upon our ":doc:`deploying`" guide to describe some common
issues affecting production deployments.


Should I Keep Open Registration Enabled?
----------------------------------------

Unfortunately, in this current release of MediaGoblin we are suffering
from spammers registering to public instances en masse.  As such, you
may want to either:

a) Disable registration on your instance and just make
   accounts for people you know and trust (eg via the `gmg adduser`
   command).  You can disable registration in your mediagoblin.ini
   like so::

     [mediagoblin]
     allow_registration = false

b) Enable a CAPTCHA plugin.  But unfortunately, though some CAPTCHA
   plugins exist, for various reasons we do not have any general
   recommendations we can make at this point.

We hope to have a better solution to this situation shortly.  We
apologize for the inconvenience in the meanwhile.


Confidential Files
------------------

.. warning::

   The directory ``user_dev/crypto/`` contains confidential information. In
   particular, the ``itsdangeroussecret.bin`` is important for the security of
   login sessions. Make sure not to publish its contents anywhere. If the
   contents gets leaked nevertheless, delete your file and restart the server,
   so that it creates a new secret key. All previous login sessions will be
   invalidated.


.. _background-media-processing:

Background Media Processing
---------------------------

":doc:`deploying`" covers use of a separate Celery process, but this sections
describes this in more detail.

MediaGoblin uses `Celery`_ to handle heavy and long-running tasks. Celery can
be launched in two ways:

1. **Embedded in the main MediaGoblin web application.** This is the way
   ``./lazyserver.sh`` does it for you. It's simple as you only have to run one
   process. The only bad thing with this is that the heavy and long-running
   tasks will run *in* the webserver, keeping the user waiting each time some
   heavy lifting is needed as in for example processing a video. This could lead
   to problems as an aborted connection will halt any processing and since most
   front-end web servers *will* terminate your connection if it doesn't get any
   response from the MediaGoblin web application in a while. This approach is
   suitable for development, small sites or when primarily using :doc:`command
   line uploads <commandline-upload>`.

2. **As a separate web application and media processing application
   (recommended).** In this approach, the MediaGoblin web application delegates
   all media processing to a task queue via a `broker`_ (task queue). This is
   the approach used in our :doc:`deployment guide <deploying>`, with RabbitMQ
   as the broker. This offloads the heavy lifting from the MediaGoblin web
   application and users will be able to continue to browse the site while the
   media is being processed in the background. This approach provided the best
   user experience and is recommended for production sites.

The choice between these two behaviours is controlled by the
``CELERY_ALWAYS_EAGER`` environment variable. Specifying ``true`` instructs
MediaGoblin to processing media within the web application while you wait.
Specifying ``false`` instructs MediaGoblin to use background processing.

.. _`broker`: http://docs.celeryproject.org/en/latest/getting-started/brokers/
.. _`celery`: http://www.celeryproject.org/


.. _sentry:


Error Monitoring with Sentry
----------------------------

We have a plugin for `raven`_ integration, see the ":doc:`/plugindocs/raven`"
documentation.

.. _`raven`: http://raven.readthedocs.org


Running multiple MediaGoblin instances on the same server
---------------------------------------------------------

It is possible to run multiple separate MediaGoblin instances concurrently on
the same server. We don't provide detailed instructions to do this, but broadly,
each instance will need:

1. A separate ``mediagoblin.ini`` and ``paste.ini``.
2. A separate database that is configured in ``mediagoblin.ini``.
3. A unique ``CELERY_DEFAULT_QUEUE`` configured in ``mediagoblin.ini``. Queues
   are automatically created, but must be unique between MediaGoblin instances.
4. A separate data directory created and configured in ``mediagoblin.ini`` and
   ``paste.ini``.
5. A unique server port configured in ``paste.ini`` under ``[server:broadcast]``.

You would typically configure the web server to route requests to the
appropriate MediaGoblin instance port based on the requested domain name or
something similar.

It is also possible to share the same MediaGoblin codebase and Python virtualenv
between multiple instances, so long as they have a unique data directory.