Django: Conflit entre Live & amp; Mise en attente de sites sur le même serveur

Question

J'ai récemment lancé une application Django en direct. Nous avons construit l'application dans un sous-domaine de transfert sur le serveur. Lors de ma mise en ligne, j'ai copié les fichiers du sous-domaine de transfert dans le site principal, créé une base de données de transfert et pointé l'ancien site de transfert vers la nouvelle base de données de transfert (le nouveau site actif étant alors dirigé vers la base de données d'origine). C’est sur mod_python sous Apache.

J'ai créé des paramètres uniques SESSION_COOKIE_NAME pour les deux sites et j'ai défini SESSION_COOKIE_DOMAIN sur ".sitename.com". pour le site actif et Aucun pour le site intermédiaire.

Le problème qui se pose à nous est que les utilisateurs de Live Admin apportent des modifications qui (semble-t-il) sont en cours d'enregistrement sur le site intermédiaire. Les utilisateurs sont également déconnectés du site d'administration " au hasard " pendant les demandes.

Y a-t-il quelque chose que je me trompe clairement ici? SESSION_COOKIE_DOMAIN doit-elle être "www.sitename.com"? pour le restreindre car le sous-domaine est à "staging.sitename.com"? Ai-je laissé les anciennes informations de session dans la base de données now-live (j’ai exécuté ./manage.py clean et supprimé toutes les sessions de la base de données live avant que ce problème ne survienne)?

Merci

Answer 1

Nous avons rencontré ce problème au cours des dernières semaines. Cela pourrait se chevaucher à quelques endroits.

1) Utilisez-vous des interpréteurs python distincts? Il y a plusieurs façons de configurer mod_python afin que les threads ne se superposent pas. Les points clés ici sont de fournir un nom de serveur distinct (dans ce cas, les domaines staging.sitename.com et www.sitename.com ), ainsi Paramètre de configuration PythonInterpreter dans votre fichier de configuration Apache vhosts.

PythonInterpreter mysite

Documents Django pertinents sur les déploiements sur le même serveur

2) Utilisez-vous un serveur de cache sur le même port? Une configuration dans settings.py vous permet de préfixer le contenu mis en cache avec plusieurs caractères afin de séparer le contenu de stockage intermédiaire du contenu en direct. Ceci est implémenté avec la configuration suivante dans settings.py:

CACHE_MIDDLEWARE_KEY_PREFIX = "STG_"

Une autre option pourrait être de s’exécuter sur des caches de systèmes de fichiers distincts pendant un certain temps pour voir si le problème est résolu. Dans settings.py, essayez d’ajouter

.

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

3) Avez-vous essayé de supprimer tous vos fichiers .pyc? Bizarrement, lorsque les deux solutions ci-dessus n'ont pas résolu notre problème, nous avons exécuté une commande bash pour supprimer tous les fichiers python compilés (fichiers .pyc) lorsque le serveur était arrêté.

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

Cela indiquerait que les modifications de votre déploiement n'étaient pas recompilées pour une raison ou une autre.

J'espère que ça aide!