2009-06-17 13 views
6

Je souhaite diffuser des flux RSS spécialisés sur un sous-domaine différent du reste du site. Puis-je utiliser l'infrastructure de sites pour utiliser un fichier urls.py et settings.py différent dans une seule instance de django. ou dois-je configurer deux emplacements apache et juste définir les différents fichiers settings.py dans la conf. apache."sites framework" sur une seule instance de django

La raison pour laquelle j'ai besoin de configurer deux fichiers urls.py est d'éviter le contenu en double. Je ne veux pas que le site principal soit disponible sur rss.example.com et je ne veux pas que les flux spécialisés soient accessibles sur example.com

Les servir depuis une seule instance de django serait idéal car re sur l'hébergement partagé avec une mémoire limitée, et il semble comme un gaspillage d'avoir une instance ouverte qui ne sert que rss.

modifier: Je conclu que plusieurs instances avec des fichiers séparés urls.py serait plus facile pour moi ... mais je trouve cet article qui décrit comment le faire en utilisant une seule instance:

http://effbot.org/zone/django-multihost.htm

Solution: Django tupperware

J'ai fini par écrire un cadre pour exécuter plusieurs copies d'un site sur une seule instance de django.

L'idée de base est de modifier à la volée le paramètre SITE_ID pour chaque requête et de charger les autres paramètres de la base de données. Il le fait par domaine et utilise SITE_ID = 1 par défaut (lorsqu'il ne trouve rien)

Tous les paramètres du fichier settings.py agissent comme paramètres par défaut qui sont remplacés par les paramètres stockés dans la base de données pour le site actuel.

Il fonctionne assez bien :) et il fonctionne dans la production à http://rootbuzz.com

+0

Êtes-vous encore utiliser Tupperware? Ou avez-vous trouvé des alternatives meilleures et plus fraîches? –

+0

@MuratCorlu Tupperware est toujours en production sur ce projet :) – Jiaaro

+0

J'ai essayé de l'utiliser avec Django 1.7 mais cela n'a pas fonctionné comme prévu. Le projet semble également mort sur Bitbucket. Pouvez-vous partager un exemple de configuration sur la façon dont vous avez utilisé tupperware? –

Répondre

10

Avec stock Django vous devez avoir un settings.py unique pour chaque site ... parce que le SITE_ID est défini dans settings.py et est la clé pour laquelle le site est la gestion de cette demande. En d'autres termes, SITE_ID est global pour votre instance et vous avez donc besoin d'une instance pour chaque site.

Vous pouvez avoir une urls.py commune si vous le souhaitez, car il n'y a rien qui vous empêche d'utiliser le même ROOT_URLCONF dans tous les fichiers de votre site settings.py ... ou vous pouvez avoir un diffent pour chaque site. Dans ce cas, vous voudrez inclure des sous-URL pour éviter de vous répéter pour les URL courantes.

Il y a au moins deux méthodes que vous pouvez essayer de servir d'une instance unique:

  1. Utilisez apache + mod_wsgi et utiliser le WSGIApplicationGroup et/ou WSGIProcessGroup directives. Je n'ai jamais eu besoin de ça auparavant donc je ne peux pas être complètement sûr que cela fonctionnera comme vous le voulez, mais peu importe, vous pouvez certainement utiliser mod_wsgi en mode démon pour améliorer grandement votre empreinte mémoire.

  2. Vous pouvez utiliser le middleware Django pour refuser/autoriser les URL en fonction du nom d'hôte de la requête (voir HttpRequest.get_host() dans les documents Django). D'ailleurs, même si ce serait un léger coup de performance, vous pouvez mettre un décorateur sur toutes vos vues qui vérifie l'hôte entrant.

+0

merci! c'est exactement ce que je devais savoir – Jiaaro

+0

Puisque ce sous-domaine ne sert que des flux RSS spécialisés, je vais mettre maxRequestsPerChild à 1 pour conserver la RAM. Tous les inconvénients que je devrais connaître (autre que la pénalité de vitesse) – Jiaaro

+0

PS - Comme vous pouvez le voir, je viens de décider de faire une nouvelle instance ... J'ai trop de vues pour mettre un décorateur sur chacun – Jiaaro