Wdrażanie aplikacji Django z Nginx, Apache, mod_wsgi


13

Mam aplikację django, która może działać lokalnie przy użyciu standardowego środowiska programistycznego. Chcę teraz przenieść to do EC2 do produkcji. Dokumentacja django sugeruje uruchomienie z apache i mod_wsgi oraz używanie nginx do ładowania plików statycznych.

Używam Ubuntu 12.04 na komputerze Ec2. Moja aplikacja Django „ddt” zawiera podkatalog „apache” z ddt.wsgi

import os, sys
apache_configuration= os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace)
sys.path.append('/usr/lib/python2.7/site-packages/django/')
sys.path.append('/home/jeffrey/www/ddt/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'ddt.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Mam zainstalowany mod_wsgi z apt. Mój apache / httpd.conf zawiera

NameVirtualHost *:8080

WSGIScriptAlias / /home/jeffrey/www/ddt/apache/ddt.wsgi
WSGIPythonPath /home/jeffrey/www/ddt

<Directory /home/jeffrey/www/ddt/apache/>
<Files ddt.wsgi>
Order deny,allow
Allow from all
</Files>
</Directory>

Pod apache2 / włączone strony

<VirtualHost *:8080>
ServerName www.mysite.com
ServerAlias mysite.com
<Directory /home/jeffrey/www/ddt/apache/>
    Order deny,allow
    Allow from all
</Directory>
LogLevel warn
ErrorLog  /home/jeffrey/www/ddt/logs/apache_error.log
CustomLog /home/jeffrey/www/ddt/logs/apache_access.log combined
WSGIDaemonProcess datadriventrading.com user=www-data group=www-data threads=25
WSGIProcessGroup datadriventrading.com
WSGIScriptAlias / /home/jeffrey/www/ddt/apache/ddt.wsgi
</VirtualHost>

Jeśli mam rację, te 3 pliki powyżej powinny poprawnie zezwalać mojej aplikacji django na działanie na porcie 8080 .

Mam następujący plik nginx / proxy.conf

proxy_redirect              off;
proxy_set_header            Host $host;
proxy_set_header            X-Real-IP $remote_addr;
proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size        10m;
client_body_buffer_size     128k;
proxy_connect_timeout       90;
proxy_send_timeout          90;
proxy_read_timeout          90;
proxy_buffer_size           4k;
proxy_buffers               4 32k;
proxy_busy_buffers_size     64k;
proxy_temp_file_write_size  64k;

Pod włączoną nginx / witrynami

server {
  listen 80;
  server_name www.mysite.com mysite.com;
  access_log /home/jeffrey/www/ddt/logs/nginx_access.log;
  error_log /home/jeffrey/www/ddt/logs/nginx_error.log;
  location / {
    proxy_pass http://127.0.0.1:8080;
    include     /etc/nginx/proxy.conf;
  }
  location  /media/ {
   root /home/jeffrey/www/ddt/;
  }
}      

Jeśli mam rację, te dwa pliki powinny skonfigurować nginx do przyjmowania żądań na porcie HTTP 80, ale następnie kieruj żądania do apache, który uruchamia aplikację django na porcie 8080. Jeśli przejdę do mysite.com, widzę tylko Witamy w Nginx !

Wszelkie porady dotyczące sposobu debugowania tego?


Czy mógłbyś opublikować plik nginx.conf? jest jakiś problem z tym, że nginx nie włącza twojego hosta, być może linia dołączania jest jak włącz /etc/nginx/conf.d/*.conf; a twój plik konfiguracyjny nie jest .conf. Jakikolwiek sposób, jeśli zobaczysz stronę powitalną nginx, oznacza, że ​​twoja konfiguracja nie została zastosowana.
Andrei Mikhaltsov,

Dla przyszłych użytkowników powinienem wspomnieć, że wraz z pojawieniem się mod_wsgi-express nie musimy wykonywać żadnej konfiguracji Apache, żadnych definicji VirtualHost, niczego w folderach conf i witrynach. Wszystko odbywa się w dobrze zoptymalizowany sposób przez mod_wsgi-express automatycznie. Szczegółowe informacje można znaleźć na blogach Grahama
Anupam,

Odpowiedzi:


1

pamiętaj, że powinieneś używać www.mysite.com lub mysite.com w swoich żądaniach (zgodnie z definicją w pliku konfiguracyjnym):

server {
  listen 80;
  server_name www.mysite.com mysite.com;

ale wygląda na to, że zamawiasz witrynę według adresu lokalnego hosta lub adresu IP


0

Przede wszystkim upewnij się, że możesz uzyskać dostęp do swojej aplikacji na 127.0.0.1:8080 i opublikuj zawartość nginx_error.log. Spróbuj Skopiuj wklej następujący plik nginx conf i sprawdź, czy działa. Używam tej samej konfiguracji dla mojej aplikacji Python.

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";


    ##
    # Virtual Host Configs
    ##

    server {
        listen 80;

        location / {
            proxy_pass_header Server;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Scheme $scheme;
            proxy_pass http://127.0.0.1:8080;
        }

    location /static {
        root /home/ubuntu/www/myproject/webapp;
    }

    }


    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

}

0

W konfiguracji NGINX umieściłeś ścieżkę do pliku conf ( /etc/nginx/proxy.conf) w pliku location. Wierzę, że należy na zewnątrz .


0

Po pierwsze, proszę, z miłości do wszystkiego, co święte, nie używaj zarówno nginx, jak i httpd. To będzie trudność w debugowaniu.

Po drugie, nigdzie w dokumentach nie widziałem, aby zalecali tego rodzaju konfigurację.

Użyj apache lub nginx, to wyeliminuje połowę twoich problemów.

Sprawdź także plik nginx.conf, jeśli nie zawiera plików z innych katalogów, które mogą mieć globalny vhost, który zastępuje twój.

Powinieneś również edytować swój post, aby usunąć domenę w konfiguracji apache w pobliżu parametrów WSGI, ponieważ aktualnie wyciekłeś z konfiguracji produkcyjnej.

Usuń inne witryny z włączonymi witrynami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.