Déployer l'application Django avec Nginx, Apache, mod_wsgi


12

J'ai une application django qui peut s'exécuter localement en utilisant l'environnement de développement standard. Je veux maintenant déplacer cela vers EC2 pour la production. La documentation de django suggère d'exécuter avec apache et mod_wsgi, et d'utiliser nginx pour charger des fichiers statiques.

J'utilise Ubuntu 12.04 sur une box Ec2. Mon application Django, "ddt", contient un sous-répertoire "apache" avec 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()

J'ai installé mod_wsgi depuis apt. Mon apache / httpd.conf contient

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>

Sous apache2 / compatible avec les sites

<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>

Si j'ai raison, ces 3 fichiers ci-dessus devraient permettre correctement à mon application django de s'exécuter sur le port 8080 .

J'ai le fichier nginx / proxy.conf suivant

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;

Sous nginx / compatible avec les sites

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/;
  }
}      

Si je me trompe, ces deux fichiers devraient configurer nginx pour prendre les requêtes sur le port HTTP 80, mais diriger les requêtes vers apache qui exécute l'application django sur le port 8080. Si je vais sur mysite.com, tout ce que je vois c'est Bienvenue dans Nginx !

Des conseils sur la façon de déboguer cela?


Pourriez-vous s'il vous plaît publier votre fichier nginx.conf? il y a un problème avec nginx qui n'active pas votre hôte, peut-être que la ligne d'inclusion est comme include /etc/nginx/conf.d/*.conf; et votre fichier de configuration n'est pas .conf. De toute façon, si vous voyez la page d'accueil de nginx, cela signifie que votre configuration n'est pas appliquée.
Andrei Mikhaltsov

Pour les futurs utilisateurs, je dois mentionner qu'avec l'avènement de mod_wsgi-express, nous n'avons plus besoin de faire de configuration Apache, pas de définitions VirtualHost, rien dans les dossiers conf et sites. Tout est fait de manière bien optimisée par mod_wsgi-express automatiquement. Voir les articles du blog de Graham pour plus de détails
Anupam

Réponses:


1

veuillez noter que vous devez utiliser www.mysite.com ou mysite.com dans vos demandes (comme défini dans le fichier de configuration):

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

mais ressemble, vous demandez le site par localhost ou par adresse IP


0

Tout d'abord, assurez-vous que vous pouvez accéder à votre application sur 127.0.0.1:8080 et veuillez publier le contenu de nginx_error.log. Essayez de copier-coller après le fichier de conf nginx et vérifiez qu'il fonctionne. J'utilise la même configuration pour mon application 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

Dans votre configuration NGINX, vous avez inclus le chemin d'accès au fichier conf ( /etc/nginx/proxy.conf) dans a location. Je crois qu'il appartient à l' extérieur .


0

Tout d'abord, s'il vous plaît pour l'amour de tout ce qui est saint, n'utilisez pas à la fois nginx et httpd. Cela va être pénible à déboguer.

Deuxièmement, nulle part dans la documentation, je n'ai vu qu'ils recommandaient ce type de configuration.

Utilisez apache ou nginx, cela éliminera la moitié de vos problèmes.

Vérifiez également votre nginx.conf s'il n'inclut pas de fichiers provenant d'autres répertoires, qui pourraient avoir un vhost global qui remplace le vôtre.

Vous devez également modifier votre publication pour supprimer le domaine dans la configuration apache près des paramètres WSGI, car vous perdez actuellement votre configuration de production.

Supprimez les autres sites des sites activés.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.