Skip to content
This repository has been archived by the owner on Apr 8, 2023. It is now read-only.

Deployment

Christian Bartz edited this page Feb 20, 2017 · 6 revisions

Deployment of 1327

Deploying of 1327 is not as easy as eating a piece of cake, but it should be possible to handle if you stick to the following guide:

WebServer

We recommend that you get Nginx as webserver. You can then follow this guide for configuring your Nginx Webserver.

Django Reverse Proxy

In order to make Nginx load your Django code you will need a reverse proxy that is called by Nginx and executes your python code. You may use uwsgi for this or gunicorn. You can find more information on how to configure uwsgi with nginx and django by following this link.

Serving Static Files

In order to serve static files you need to make sure that you copy all your static files to the correct directory where Nginx can find them. You will also need to add the following lines to your localsettings.py:

SENDFILE_BACKEND = 'sendfile.backends.nginx'
SENDFILE_ROOT = '<path to your static files>'
SENDFILE_URL = '/media'

Setting up the Websockets

1327 uses Websockets for showing live updates of Documents that are currently edited. As Django in combination with a Webserver is not capable of handling Websockets you will need some additonal services on your Server that handle the websocket communication.

Before you begin you should install the necessary libraries by issuing the following command: pip install -r requirements-deploy.txt from the root folder of the project.

After you did this you should add the following line to your localsettings.py:

CHANNEL_LAYERS = {
"default": {
	"BACKEND": "asgi_ipc.IPCChannelLayer",
	"ROUTING": "_1327.routing.channel_routing",
	"CONFIG": {
		"prefix": "<your very own choice>",  # e.g. 1327 
	},
},
}

The prefix is necessary for making sure that each instance (Websocket Server and Websocket worker) knows where to put their information.

Services that should be started

In order to successfully run 1327 with Websocket communication enabled you need to run the following services:

  1. daphne _1327.asgi:channel_layer -u /tmp/daphne.sock
  2. python manage.py runworker

The first command starts Daphne, which is a server that handles the websocket requests. The second command starts a worker thread used by Daphne to handle all requests in an asynchronous manner.

You should start these services using a Process Control System like Supervisor or Systemd. We will here focus on how to configure Supervisor but it should be quite similar to other possibilities.

Configuring Supervisor

After you've installed Supervisor you should add the following files you can choose the filename the way you like to the folder /etc/supervsor/conf.d/:

daphne.conf

[program:1327_daphne]
command=<path to your python venv>/bin/daphne _1327.asgi:channel_layer -u /tmp/daphne.sock
directory=<path to your clone of 1327>
user=nobody
group=nogroup  # you can also use nobody here if your system does not have the group nogroup 
autostart=true
autorestart=true
stdout_logfile = <path to a log file>
stderr_logfile = <path to a log file>

worker.conf

[program:1327_worker]
command=<path to your python venv>/bin/python manage.py runworker
directory=<path to your clone of 1327>
user=nobody
group=nogroup  # you can also use nobody here if your system does not have the group nogroup 
autostart=true
autorestart=true
stdout_logfile = <path to a log file>
stderr_logfile = <path to a log file>

You may then try to start your services by issuing one of the following commands:

  • if your system uses systemd: systemctl start supervisor
  • if your system uses init.d: service supervisor start

If everything works well you should now have a service that listens on the unix socket /tmp/daphne.sock You can also check that it works by issuing:

  • systemd: systemctl status supervisor
  • init.d: service supervisor status

Troubleshooting

If your services do not start and show you an error like Permission Denied you should check that the user/group nobody/nogroup has read/write permissions in /dev/shm. If there are files named like r'.\*-[chan|group]' or r'sem\\..\*-[chan|group]-sem' and they do not belong to the user/group nobody/nogroup you should delete them and restart the service.

You should make sure that u-wsgi/gunicorn, daphne, and the workers run using the same username. Otherwise you will encounter permissions problems.

Configuring Nginx

The last step is to configure your Nginx so that it knows how to talk to Daphne. In order to do this you should add the following to your Nginx config, where you configured your Django application:

upstream websocket_server_1327 {
	server unix:/tmp/daphne.sock fail_timeout=0;
} 

location /ws {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
	proxy_pass http://websocket_server_1327;
}

After you've done this you should be good to go. For testing the integration you may create a new document, add some text, click on the share button that will appear and open the preview page. After you've edited some more text you should see that the preview is updating itself. If that works you are done =)