2015-07-02 13 views
9

Ich habe eine Webanwendung mit einer zugehörigen API und Datenbank.django separate Web & Api-Endpunkte auf Heroku

Ich würde gerne die gleichen Django-Modelle in der API verwenden, aber sie werden separat von verschiedenen Prozessen bedient, sodass ich sie unabhängig skalieren kann.

Ich brauche auch nicht die API statische Attribute oder eine der anderen Ansichten dienen.

Die Komplikation ist, dass die Strecken I definiert haben die API und die Webapp die Stammdomäne teilen

http://domain.com/normal/application/stuff 
http://domain.com/api/different/stuff 

und zusätzlich abhängig meine Django-Anwendungen auf jedes Modell der anderen und Konstanten (so zwei verschiedene settings.py Dateien mit verschiedene INSTALLED_APPS löst es nicht ganz).

Ich denke, eine Möglichkeit wäre, verschiedene Prozesse in meinem Procfile zu definieren, die nur die Django-App starten, aber in einem der Prozesse möglicherweise andere Umgebungsvariablen haben? Ich glaube nicht, dass ich die Umgebung per Proc mit heroku:config ändern kann, ich denke es müsste eigentlich eine Direktive im Procfile sein.

Wer hat irgendwelche Erfahrungen oder Einsichten mit diesem? Vielen Dank!

+1

FWIW, das größere Problem mit dem, was Sie möchten nicht tun, wie Django zu konfigurieren, es ist die Tatsache, dass Sie beide unter dem gleichen Domain-Namen tun möchten. Dies bedeutet, dass Sie die segmentierten Anwendungen nicht auf separate Web-Dynos aufteilen können, wenn Sie sie auf der Ebene eines Dynos separat skalieren möchten. Einige WSGI-Server bieten genügend Konfigurationsmöglichkeiten, um eine Webanwendung innerhalb des einen Hosts zu segmentieren und eine unterschiedliche Anzahl von Prozessen/Threads für verschiedene Teile der Anwendung anzugeben, aber der von Heroku empfohlene Gunicorn-WSGI-Server gehört nicht dazu. –

+0

könnte ich noch eine einzelne Django-Anwendung/Heroku-Anwendung verwenden, aber eine settings.py für eine Domain und eine für eine Subdomain? – lollercoaster

+0

Sie könnten es tun, wenn Sie Apache/mod_wsgi als WSGI-Server verwenden, aber das Heroku-Setup erlaubt nicht, dass es mit Python 2.7 ausgeführt wird. Kann nur mit Python 3.3+ verwendet werden und benötigt dann noch einige Tricks von mod_wsgi, damit es auf Heroku installiert werden kann. Leider kann nicht garantiert werden, dass Heroku die Dinge nicht ändert, so dass es auch nicht auf Python 3.3+ funktioniert. –

Antwort

2

Wie Daniel sagte, könnten Sie einfach zwei Einstellungsdateien mit einer gemeinsamen Basis verwenden. Wenn Sie eine Teilmenge der URLs bereitstellen möchten, sollten Sie auch separate URL-Definitionen in der ROOT_URLCONF Einstellung erstellen.

So würde Ihre Projektstruktur so etwas wie diese:

project/ 
    project/ 
     settings/ 
      __init__.py 
      base.py 
      normal.py 
      api.py 
     urls/ 
      __init__.py 
      base.py 
      normal.py 
      api.py 
     wsgi/ 
      __init__.py 
      normal.py 
      api.py 

Einstellungen/normal.py (analog für api) somthing so sein würde:

from .base import * 
ROOT_URLCONF = 'project.urls.normal 
+0

Das scheint das Problem zu lösen.Gibt es irgendwelche Nachteile, dies zu tun, z. B. die App in eine (normale) Portion für eine Domain zu spalten und die andere (api) für eine Subdomain? – lollercoaster

+0

Nicht dass ich an – jgadelange

+0

denken könnte warten - wenn eine Anfrage kommt wie weiß Gunicorn welchen Prozess zu dienen? überprüfen beide Prozesse ihre "urls.py"? Ich sehe keinen Weg, um den Unterschied zu erkennen. – lollercoaster

1

Ich glaube nicht, dass Sie verschiedene Umgebungsvariablen benötigen, nur eine separate WSGI-Datei, die auf eine andere settings.py verweist. Diese Einstellungsdatei kann freigegebene Einstellungen aus einer gemeinsamen Datei importieren und dann ihre jeweiligen Werte für INSTALLED_APPS festlegen. Dann kann die Procfile diese wsgi-Dateien in separaten Prozessen beziehen.

+0

Zwei WSGI-Dateien und zwei Einstellungsdateien funktionieren. Wenn es jedoch eine Abhängigkeit zwischen Apps gibt (also Apps nicht von INSTALLED_APPS entfernen können), würde sie immer noch über urls.py alle verschiedenen Endpunkte bedienen, ja? – lollercoaster