Che cos'è gunicorn.sock?

Question

Sono un novizio seguendo il tutorial gunicorn-django di Michal Karzynski. Sto usando Django 1.7.4 su Ubuntu 14 e la mia messa a punto per lo script gunicorn è il seguente

#!/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=- 

Quando cambio l'impostazione di UNIX bind: $ SOCKFILE, il mio script viene eseguito ancora ma sono in grado di connettersi con il mio browser In this question ho letto che non è saggio distribuire 0.0.0.0:8000 su un server di produzione.

Conosco un po 'di socket unix, ma non so come posso usare il file socket unix per servire il mio sito. Ho provato a modificare il file del socket come superutente, ma il sistema operativo non mi consente di aprirlo.

Come posso impostare il file socket per consentirmi di servire le mie pagine?

PS: Qui è la mia nginx file di configurazione

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

Si suppone di utilizzare un proxy inverso come nginx a sedersi di fronte a gunicorn, ed è quello che realmente serve il vostro sito. Comunicano tramite la presa.

I documenti di gunicorn hanno uno sample nginx configuration che fa esattamente questo, anche se ovviamente dovresti far combaciare il sockfile con quello che hai inserito nella configurazione di gunicorn.

Answer 2

Gli zoccoli sono un'alternativa molto più veloce ed efficiente alle porte di rete se si lavora localmente su un server. Tuttavia, se il tuo server nginx e la tua app django sono su server diversi, devi aprire specifiche connessioni IP.

Per l'esempio, se si desidera utilizzare i socket, è sufficiente puntare l'indirizzo del server upstream nel file socket. Modificare la configurazione di nginx come

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