django wdrażanie oddzielnych punktów końcowych sieci web i api na heroku

Mam aplikację internetową z powiązanym interfejsem API i bazą danych.django wdrażanie oddzielnych punktów końcowych sieci web i api na heroku

Chciałbym używać tych samych modeli Django w API, ale mam je obsługiwane osobno przez różne procesy, więc mogę skalować je niezależnie.

Również nie potrzebuję interfejsu API do obsługi zasobów statycznych ani żadnego innego widoku.

Powikłanie to, że trasy Mam zdefiniowane mają API i webapp dzielenie domenę główną:

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

i dodatkowo moje aplikacje Django zależą od siebie nawzajem modeli i stałych (tak dwa różne settings.py pliki z inny INSTALLED_APPS nie całkiem to rozwiązuje).

Sądzę, że jednym ze sposobów jest zdefiniowanie różnych procesów w moim pliku Procfile, który właśnie uruchamia aplikację Django, ale w jednym z procesów może mieć inne zmienne środowiskowe? Nie sądzę, że mogę zmienić środowisko na Proc z heroku:config, myślę, że faktycznie musiałby to być dyrektywa w Procfile.

Ktoś ma jakieś doświadczenie lub wgląd w to? Dzięki!

Źródło

2015-07-02 lollercoaster

FWIW, tym większy problem z co nie chcesz konfigurować Django, to fakt, że chcesz robić obie w ramach tej samej nazwy domeny. Oznacza to, że nie można dzielić podzielonych na segmenty aplikacji na osobne dynamiczne sieci, jeśli chcesz je skalować oddzielnie na poziomie dyno. Niektóre serwery WSGI zapewniają wystarczającą zdolność konfiguracyjną do segmentowania aplikacji WWW w obrębie jednego hosta i określania różnej liczby procesów/wątków dla różnych części aplikacji, ale serwer Gunicorn WSGI zalecany przez Heroku nie jest jednym z nich. –

czy nadal mogę używać pojedynczej aplikacji Django/Heroku, ale mam plik settings.py dla domeny i jeden dla subdomeny? – lollercoaster

Możesz to zrobić, jeśli używasz Apache/mod_wsgi jako serwera WSGI, ale konfiguracja Heroku nie zezwala na uruchamianie go w Pythonie 2.7. Można go używać tylko w Pythonie 3.3+, a następnie nadal wymaga pewnych sztuczek ze strony mod_wsgi, aby umożliwić instalację na Heroku. Niestety nie można zagwarantować, że Heroku nie zmieni rzeczy, więc nie działa również w Pythonie 3.3+. –

Jak powiedział Daniel, można użyć tylko dwóch plików ustawień ze wspólną bazą. Jeśli chcesz obsłużyć podzbiór adresów URL, po prostu utwórz osobne definicje adresów URL w ustawieniu ROOT_URLCONF.

Więc struktura projektu byłoby coś takiego:

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

ustawienia/normal.py (analogowe dla API) byłoby somthing tak:

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

Źródło

2015-07-11 08:45:35 jgadelange

Wygląda na to, że rozwiąże to problem.Czy są jakieś wady tego, powiedzmy, dzielenia aplikacji na jedną (normalną) obsługującą domenę, a drugą (api) obsługującą subdomenę? – lollercoaster

Nie, żebym mógł pomyśleć o – jgadelange

oczekiwaniu - jeśli pojawi się prośba o to, w jaki sposób gunicorn wie, do którego procesu służyć? czy oba procesy sprawdzą swoje 'urls.py'? Nie widzę sposobu, żeby to mogło odróżnić. – lollercoaster

Nie sądzę, że potrzebujesz różnych zmiennych środowiskowych, tylko oddzielny plik WSGI wskazujący na inny plik settings.py. Ten plik ustawień może importować współdzielone ustawienia ze wspólnego pliku, a następnie ustawić ich konkretne wartości dla INSTALLED_APPS. Następnie plik Procfile może odnosić się do tych plików wsgi w oddzielnych procesach.

Źródło

2015-07-02 16:57:50

Dwa pliki wsgi i dwa pliki ustawień będą działać. Jeśli jednak istnieje jakaś zależność między aplikacjami (więc nie można usunąć aplikacji z INSTALLED_APPS), nadal będzie ona obsługiwana przez urls.py wszystkich różnych punktów końcowych, tak? – lollercoaster

django wdrażanie oddzielnych punktów końcowych sieci web i api na heroku

Odpowiedz

Powiązane problemy