QGIS Server on docker and rancher
Simple load balanced configuration for QGIS, Rancher and Docker.
This example will host a service with a map of the Winelands District, Western Cape, South Africa. Based on data from OpenStreetMap and population data published by CIESIN with the district boundary provided by The South African Demarcation Board, this is a simple local map of the Cape Winelands area.
We have made this example public in the hopes that it will inspire others who are looking for ways to scale up QGIS Server in a production environment.
Usage:
- Install Rancher server (not covered here)
- Set up a Rancher environment (not covered here)
- Provision at least two hosts into the environment (we used Hetzner CX10 VPS's which have 1GB ram, 1x1Ghz CPU - that is probably the minimum you can get away with but your published projects may require more oomph...). The supplied setup-node.sh script should give you and indication of what is required to provision the node. Note that this script if run unmodified will provision your host into our rancher environment which is definately not what you want, so be sure to modify the script.
- Create a new stack in the environment (illustrated in screenshots below)
- Use the docker-compose.yml and rancher-compose.yml provided in this repo to start up the service (illustrated below)
Adding a new stack...
Setting the docker-compose and rancher-compose yaml files...
Waiting for the stack to spin up...
Stack spin up completed...
QGIS Nodes (currently 2 running)...
Detailed view of nodes ...
Provisioning a new host ...
Scaling up to three nodes ...
Waiting while a new node spins up ...
Third node integrated into the stack ...
Testing:
- Check what IP address your load balancer is running on in rancher web UI.
- Create a new QGIS WMS connection pointing at the load balancer simply in the format http://xxx.yyy.zzz.aaa (where xxx.yyy.zzz.aaa is the ip address of your load balancer). No need to specify any service descriptors.
- You can also test using the supplied test.sh script which will do two things:
- run apache benchmark (it assumes it is in your path) against the server with two concurrent requests and see how many times it can get a response in 30s.
- fetch and open a map request in your preview app (assumes MacOS client) so that you can have visual verification that the service works.
How does it work?
We use three containers:
- a loadbalancer (provided by rancher).
- a btsync container that will provide the file store. This will be a rancher 'sidekick' container meaning that there will always be one sidekick established for every QGIS container that gets run. BTSync (now Resilio Sync) provides a peer-to-peer file sharing system. With it you can define the files on your desktop and they publish to the web without any work on your part. You just need to take care on your authoring host to remember that changing a file is near immediate and taking drastic action like deleting files locally could have bad consequences for the published service.
-
a QGIS container that will publish the maps in the file store.
Here is a sample output for two nodes:
Concurrency Level: 2 Time taken for tests: 34.177 seconds Complete requests: 3 Failed requests: 0 Total transferred: 30558 bytes HTML transferred: 30090 bytes Requests per second: 0.09 [#/sec] (mean) Time per request: 22784.397 [ms] (mean) Time per request: 11392.198 [ms] (mean, across all concurrent requests) Transfer rate: 0.87 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 215 222 13.0 226 237 Processing: 15198 17344 1861.9 18417 18527 Waiting: 15170 17319 1864.9 18394 18511 Total: 15435 17566 1848.9 18631 18742
And here is what happens if we scale up to three nodes and then rerun the test:
Concurrency Level: 2 Time taken for tests: 37.368 seconds Complete requests: 5 Failed requests: 0 Total transferred: 50930 bytes HTML transferred: 50150 bytes Requests per second: 0.13 [#/sec] (mean) Time per request: 14947.096 [ms] (mean) Time per request: 7473.548 [ms] (mean, across all concurrent requests) Transfer rate: 1.33 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 202 253 45.5 273 300 Processing: 12124 13057 1470.0 12712 15594 Waiting: 12112 13050 1471.5 12711 15588 Total: 12343 13310 1491.5 12944 15893
You can see that in particular the time per request dropped from 11.4 seconds
to 7.5 seconds by adding one node. You can also in rancher the load being
spread nicely across the nodes:
Here you can see the load balancer spreading the requests as I do many sequential
map interactions in QGIS (using it as a WMS client). The screencapture below switches
between rancher to show CPU and IO load and the QGIS desktop.
## Caveats
1. Note that you will need to adapt this for your own needs since it contains
data that is specific to our company and the test.sh script points to our own
servers.
1. When spinning up a new node, it may return OGC service errors until the btsync
is completed. I don't have an elegant way to deal with this (yet) so you should
take that into consideration both when testing and trying to understand if things
are working, and in production as you load balancer may start forwarding traffic
to the new node before it is actually ready to respond to these requests.
Tim Sutton
December 2016