Was ist gunicorn.sock?

Question

Ich bin ein Neuling im Anschluss an dem gunicorn-django Tutorial von Michal Karzynski. Ich verwende Django 1.7.4 auf 14 Ubuntu und mein Setup für das gunicorn Skript ist als

#!/bin/bash 

NAME="mytestapp"         # Name of the application 
DJANGODIR=/var/www/testapp/src    # Django project directory 
SOCKFILE=/var/www/testapp/run/gunicorn.sock # we will communicte using this unix socket 
USER=ubuntu          # the user to run as 
GROUP=ubuntu          # the group to run as 
NUM_WORKERS=3          # how many worker processes should Gunicorn spawn 
DJANGO_SETTINGS_MODULE=testapp.settings    # which settings file should Django use 
DJANGO_WSGI_MODULE=testapp.wsgi      # WSGI module name 

echo "Starting $NAME as `whoami`" 

# Activate the virtual environment 
cd $DJANGODIR 
export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE 
export PYTHONPATH=$DJANGODIR:$PYTHONPATH 

# Create the run directory if it doesn't exist 
RUNDIR=$(dirname $SOCKFILE) 
test -d $RUNDIR || mkdir -p $RUNDIR 

# Start your Django Unicorn 
# Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon) 
exec gunicorn ${DJANGO_WSGI_MODULE}:application \ 
    --name $NAME \ 
    --workers $NUM_WORKERS \ 
    --user=$USER --group=$GROUP \ 
    --bind=0.0.0.0:8000 \ 
    --log-level=debug \ 
    --log-file=- 

folgt Wenn ich die bind ändern, um Unix-Einstellung: $ SOCKFILE, mein Skript läuft noch, aber ich bin nicht in der Lage, mit verbinden mein Browser. In this question Ich habe gelesen, dass es nicht ratsam ist, 0.0.0.0: 8000 auf einem Produktionsserver bereitzustellen.

Ich weiß ein wenig über Unix-Sockets, aber ich weiß nicht, wie ich die Unix-Socket-Datei verwenden kann, um meine Website zu bedienen. Ich habe versucht, die Socket-Datei als Superuser zu bearbeiten, aber das Betriebssystem lässt mich nicht öffnen.

Wie kann ich Setup die Socket-Datei, damit ich meine Seiten dienen?

PS: Hier ist meine nginx Konfigurationsdatei

upstream hello_app_server { 
# fail_timeout=0 means we always retry an upstream even if it failed 
# to return a good HTTP response (in case the Unicorn master nukes a 
# single worker for timing out). 

server 127.0.0.1:8000 fail_timeout=0; 
} 

server { 

    listen 80; 
    server_name test.com; 

    client_max_body_size 4G; 

    access_log /var/www/testapp/src/logs/nginx-access.log; 
    error_log /var/www/testapp/src/logs/nginx-error.log; 

    location /static/ { 
     alias /var/www/testapp/src/static/static_dirs/; 
    } 

    location /media/ { 
     alias /var/www/testapp/src/static/media/; 
    } 

    location/{ 
     # an HTTP header important enough to have its own Wikipedia entry: 
     # http://en.wikipedia.org/wiki/X-Forwarded-For 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

     # enable this if and only if you use HTTPS, this helps Rack 
     # set the proper protocol for doing redirects: 
     # proxy_set_header X-Forwarded-Proto https; 

     # pass the Host: header from the client right along so redirects 
     # can be set properly within the Rack application 
     proxy_set_header Host $http_host; 

     # we don't want nginx trying to do something clever with 
     # redirects, we set the Host: header above already. 
     proxy_redirect off; 

     # set "proxy_buffering off" *only* for Rainbows! when doing 
     # Comet/long-poll stuff. It's also safe to set if you're 
     # using only serving fast clients with Unicorn + nginx. 
     # Otherwise you _want_ nginx to buffer responses to slow 
     # clients, really. 
     # proxy_buffering off; 

     # Try to serve static files from nginx, no point in making an 
     # *application* server like Unicorn/Rainbows! serve static files. 

     if (!-f $request_filename) { 
      proxy_pass http://hello_app_server; 
      break; 
     } 

    } 

    # Error pages 
    error_page 500 502 503 504 /500.html; 
    location = /500.html { 
     root /var/www/testapp/src/static/; 
    } 
} 

Answer 1

Du solltest du einen Reverse-Proxy wie nginx verwenden, vor gunicorn zu sitzen, und das ist, was Ihre Website tatsächlich dient. Sie kommunizieren über die Steckdose.

Die gunicorn docs haben eine sample nginx configuration, die genau das tut, obwohl Sie offensichtlich die Sockfile stimmen sollten, was Sie in Ihrer gunicorn-Konfiguration eingegeben haben.

Answer 2

Sockets sind eine viel schnellere und effizientere Alternative zu Netzwerkports, wenn Sie lokal auf einem Server arbeiten. Wenn sich Ihr nginx-Server und Ihre django-App jedoch auf verschiedenen Servern befinden, müssen Sie bestimmte IP-Verbindungen öffnen.

Für Ihr Beispiel, wenn Sie Sockets verwenden möchten, müssen Sie nur die Upstream-Server-Adresse auf Ihre Socket-Datei verweisen. Ändern Sie die nginx-Konfiguration als

upstream hello_app_server { 
# fail_timeout=0 means we always retry an upstream even if it failed 
# to return a good HTTP response (in case the Unicorn master nukes a 
# single worker for timing out). 
    server unix:/var/www/testapp/run/gunicorn.sock fail_timeout=0; 
} 

server { 
    . 
    . 
    . 
    # Rest of your file...