1

I have a WSGI Python app running in via Gunicorn:

CONFIG = {
    'bind': "unix:{}".format(os.path.join(RUN_DIR, "brain.sock")),
    'preload_app': False,
    # supervisord requires that the child process runs in foreground
    'daemon': False,
    ...
}

It receives HTTP requests via a socket file from Nginx:

server {
    ...
    location / {
        proxy_pass                  http://unix:$root/run/brain.sock:;
        ...
    }

The Gunicorn is run via Supervisord:

[program:myapp]
command = venv/bin/gunicorn -c gunicorn.conf.py myapp.wsgi:application
...

I am thinking of a way to deploy my app without downtime and waiting time. Each worker can take up to 30 seconds to fill up the cache.

My idea to deploy like this:

  1. Start a second Gunicorn with new code which would listen to another socket file.

  2. Wait until the app starts with all caches filled.

  3. Rename the socket file to point to the location used by Nginx. Nginx would still send requests to old socket.

  4. Shut down old Gunicorn with old app version. Nginx will see that the socket is closed and will reopen a new socket from the same location.

Will this work?

Am I reinventing the wheel?

warvariuc
  • 358
  • 1
  • 5
  • 14

2 Answers2

1

That is Blue-green deployment pattern.

Instead of renaming sockets (step 3) you could have two nginx configurations (site file or servers directive with different name), blue and green, pointing to each of your gunicorn instances. Then, when you want to deploy, just enable one and disable the other. Finally nginx reload will handle gracefully all active connections.

Here is an example of that.

  • 1
    I want to try a simpler approach: http://philipcristiano.com/2013/06/27/python-gunicorn-deployment.html – warvariuc Oct 27 '17 at 14:38
0

Instead of gunicorn, you might want to have a look at uwsgi, which

aims at developing a full stack for building hosting services.

Application servers (for various programming languages and protocols), proxies, process managers and monitors are all implemented using a common api and a common configuration style.

Thanks to its pluggable architecture it can be extended to support more platforms and languages.

Currently, you can write plugins in C, C++ and Objective-C.

The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project.

Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules followed).

One of it's features is doing graceful reloads.

gxx
  • 5,591
  • 2
  • 22
  • 42