Was ist die beste Struktur für ein Django-Projekt mit mehreren Sites, die auf der gleichen Backend-Logik basieren?

Question

Ich habe begonnen, an einem neuen großen Projekt zu arbeiten - viele stadtbasierte Webshops, von denen jeder an einer eigenen Subdomain der einen Domain arbeitet, zum Beispiel citydomain.webshop.com. Es sollten etwa 40 dieser Websites gleichzeitig gestartet werden.

Die Backend-Geschäftslogik und das Template-Design des Projekts sind auf allen Sites gleich. Einige statische Dateien und Datenbankdaten sind sowohl allgemein für alle Sites als auch standortspezifisch (Logs, Bilder, Verkauf von Artikeln, Bestellungen usw.).

Meine Frage ist, wie Sie die bestmögliche Architektur so implementieren, dass ein bestimmter Benutzer, der dieselben URLs in verschiedenen Subdomains besucht, die spezifischen Daten dieser Subdomain von derselben Backend-Logik verarbeitet bekommt.

Ich nehme die folgenden Optionen der möglichen Architektur:

1) Django Projekt Instanz: eine Instanz für alle Websites oder viele Instanzen für jeden Standort?

Der erste Weg scheint in Bezug auf das DRY-Prinzip viel logischer zu sein als der zweite. Ich glaube, dass es im Idealfall ein Projekt Instanz für jede Website bestimmter Bilder, Protokolle etc. mit vielen subfoolders mit Subdomains Namen sein sollte

2) Datenbank: ein db für alle Websites oder viele Datenbanken für jeden Standort?

Ich habe auch eine Datenbank zu haben wegen der gleichen DRY-Prinzip. Die große Menge an Daten würde in verschiedenen standortspezifischen Datenbanken wiederholt werden, und auch der Wechsel zwischen ihnen im laufenden Betrieb könnte mühsam sein (Datenbank-Router scheinen hier laut Dokumentation das Werkzeug zu sein).

Mit nur einer Datenbank, sollte ich wahrscheinlich sites framework verwenden, um Site-spezifische Daten in verschiedenen Tabellen zu speichern (mit Fremdschlüssel zu Site Modell, soweit ich verstehe)? Wie sollte ich dann SITE_ID nach der aktuellen Subdomain ändern? Sollte ich entweder: a) einige benutzerdefinierte Middleware oder b) einige Addon wie django-subdomains, django-multisite, Airavata?

Oder vielleicht ist es nicht sinnvoll, sites framework überhaupt zu implementieren?

3) Einstellungen: Speichern von Einstellungen in settings.py Dateien (die wichtigste und viele ortsspezifische sind) OR kombinieren, um die Haupt settings.py Datei mit ortsspezifischen nur in der Datenbank gespeichert Optionen (möglicherweise innerhalb Site Tabelle oder eine andere Tabelle, würde es verlängern)?

4) Virtuelle Hosts: nur für die Hauptdomäne ODER viele virtuelle Hosts für jede Site? Die zweite Option könnte mit vielen kleinen standortspezifischen Dateien mit einer eigenen SITE_ID (von der einen Haupt settings.py erben) mit vielen Site-spezifischen WSGI-Dateien für jede Subdomain erstellt werden?

Bitte geben Sie mir einen Rat von einigen Best Practices für das oben beschriebene Projekt. Was sollte die richtige Entscheidung für jede dieser "Crossroad" -ähnlichen Optionen sein, was würdest du empfehlen?

Answer 1

OK, ich beantworte meine eigene Frage nach einem Haufen Arbeit.

Nach meinen Projektanforderungen habe ich beschlossen, fast alles an einem Ort zu konzentrieren, um später nicht mit so vielen Versionen der gleichen Sache zu verwechseln. Eine Projektinstanz, eine Datenbank, ein Setuppaket, ein virtueller Host.

Subdomainspezifische Daten werden gespeichert a) entweder in der Datenbank (mit dem benutzerdefinierten Domänenmodell verknüpft), wenn es sich um reine Textdaten handelt b) oder als Datei in einer subdomainspezifischen Verzeichnisstruktur innerhalb der Projektinstanz wenn es sich um binäre Daten handelt (meistens Bilder).

Settings-Paket besteht aus der Grundeinstellungsdatei und drei umgebungsspezifischen Dateien (Entwicklung, Staging, Produktion), die alles aus dieser einen Grunddatei importieren. Sie müssen auswählen, welche Datei verwendet werden soll, und sie in settings.py umbenennen.