What is gunicorn.sock?

Question

I am a newbie following the gunicorn-django tutorial by Michal Karzynski. I am using Django 1.7.4 on Ubuntu 14 and my setup for the gunicorn script is as follows

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

When I change the bind setting to unix:$SOCKFILE, my script still runs but I am unable to connect with my browser. In this question I have read that it's not wise to deploy 0.0.0.0:8000 on a production server.

I know a bit about unix sockets, but I don't know understand how I can use the unix socket file to serve my site. I have tried to edit the socket file as the superuser, but the OS doesn't let me open it.

How can I setup the socket file to allow me to serve my pages?

PS: Here is my nginx configuration file

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

score 6 · Answer 1 · answered Feb 07 '15 at 09:31

You're supposed to use a reverse proxy like nginx to sit in front of gunicorn, and that's what actually serves your site. They communicate via the socket.

The gunicorn docs have a sample nginx configuration which does exactly that, although obviously you should make the sockfile match what you've put in your gunicorn config.

Kashif Siddiqui · Answer 2 · 2016-04-02T11:31:26.643

Sockets are a much faster, more efficient alternative to network ports if you are working locally on a server. However if your nginx server and your django app are on different servers then your would need to open up specific ip connections.

For your example if you want to use sockets you just need to point the upstream server address to your socket file. Change the nginx configuration as

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

What is gunicorn.sock?

2 Answers2