Django: conflicto entre Live & amp; Sitios de preparación en el mismo servidor

Question

Recientemente lancé una aplicación Django en vivo. Construimos la aplicación en un subdominio provisional en el servidor. Cuando entré en funcionamiento, copié los archivos del subdominio provisional en el sitio principal, creé una base de datos provisional y apunté el sitio antiguo a la nueva base de datos (dejando el nuevo sitio directo señalado en la base de datos original). Esto está en mod_python bajo Apache.

Creé configuraciones únicas de SESSION_COOKIE_NAME para ambos sitios y configuré SESSION_COOKIE_DOMAIN en " .sitename.com " para el sitio en vivo y Ninguno para el sitio de preparación.

El problema que estamos viendo es que los usuarios del administrador en vivo están realizando ediciones que (al parecer) se están guardando en el sitio de preparación. Los usuarios también están desconectados del sitio de administración "al azar" durante las solicitudes.

¿Hay algo que claramente estoy haciendo mal aquí? ¿Debería SESSION_COOKIE_DOMAIN " www.sitename.com " restringirlo ya que el subdominio está en "staging.sitename.com" ¿Dejé atrás la información de la sesión anterior en la base de datos ahora en vivo (ejecuté ./manage.py clean y eliminé todas las sesiones de la base de datos en vivo antes de que surgiera este problema)?

Gracias

Answer 1

Nos encontramos con este problema en las últimas semanas. Hubo un par de lugares donde esto podría superponerse.

1) ¿Está ejecutando intérpretes de Python separados? Hay algunas formas de configurar mod_python para que los hilos no se crucen entre sí. Los puntos clave aquí son proporcionar un ServerName distinto (en este caso, los dominios staging.sitename.com y www.sitename.com ), así como también proporcionar un Configuración de PythonInterpreter en su archivo de configuración de Apache vhosts.

PythonInterpreter mysite

Documentos relevantes de Django sobre implementaciones en el mismo servidor

2) ¿Está ejecutando un backend de caché en el mismo puerto? Hay una configuración en settings.py que le permite prefijar el contenido en caché con varios caracteres para separar el contenido provisional del contenido en vivo. Esto se implementa con la siguiente configuración en settings.py:

CACHE_MIDDLEWARE_KEY_PREFIX = "STG_"

Otra opción podría ser ejecutar en cachés del sistema de archivos por un tiempo para ver si se resuelve el problema. En settings.py, intente agregar

CACHE_BACKEND = 'file:///var/tmp/django_cache'

3) ¿Has intentado eliminar todos tus archivos .pyc? Curiosamente, cuando las dos soluciones anteriores no pudieron resolver nuestro problema, ejecutamos un comando bash para eliminar todos los archivos compilados de Python (archivos .pyc) mientras el servidor estaba detenido.

find ./ -type f -name "*.pyc" -exec rm -f {} \;

Esto indicaría que los cambios en su implementación no se estaban volviendo a compilar por una razón u otra.

¡Espero que esto ayude!