A GeoNode with QGIS Server backend stack. Here is the link diagram for GeoNode with QGIS Server
- Volumes
Volumes were all configured using named volumes. By default, Rancher will create new containers with mounted volumes. These named volume will be created if they don't exist. Once created, they will be persisted on the agent. So if you spin up a new service, but mount the same named-volume, the data will be the same. You can optionally change these named-volume into a path location in your agent if you need to. Usually this is useful when you have some existing data.
- Django ALLOWED_HOSTS setting
The Django framework used by GeoNode will run in production mode. For security reasons,
it doesn't allow a hostname that is not described in the ALLOWED_HOSTS setting.
Simply append your hostname during initial setup of the catalogue service, or after deployment
by putting the correct valye into this setting located in django.environment key
and celery.environment keys - editable by performing an upgrade on the django and celery containers.
Again, see the video at the top of this page for a demonstration of how you upgrade your services to
set their settings.
When entering this value in the catalogue be sure to place the allowed hosts in quotes and separated by commas e.g. 'host1','host' (you can use ip addresses too).
- Django SITEURL setting
Change this value into something your instance will be referenced from the internet.
This setting is located in django.environment key and celery.environment key. Include the http:// prefix too e.g. foo.com
- Nginx frontend port
The frontend that will serve the webserver is nginx by proxying uwsgi. You can specify
nginx.ports key into your exposed port. For example, 7000:80 will forward
nginx 80 port into the agent 7000 port. If your agent directly serve the webserver,
you can use 80:80 for example.
Note that all of these settings can also be changed by upgrading the relevant services after you have created the stack.
- Service scaling
Scalable service in this stack are: celery and qgis-server-backend. It is scaled
to 4 by default. You can change this into other relevant value. You can also change
this value after you have created the stack.
If a service (e.g. qgis-server-backend service) is in a stale condition (stuck on rolling back but didn’t do anything), the easiest way to deal with this is to rename the service first (e.g. qgis-server-backend-old). Next clone the service into the previous name (qgis-server-backend), so we have the same service name, but with fresh containers and the same settings. Then because the qgis-server service is a load balancer to qgis-server-backend, I restart that service too. To make sure it picks up the new container instance’s internal ip.
Your siteurl is probably not set. Use the upgrade option on the django container, perform the upgrade, then restart the nginx container.
If you try opening the web page and it says Gateway error, there might be two reasons for this:
- The django service container is dead,
- It doesn’t connect to nginx container (because nginx forward request to django container).
Check the log for django service. If it is running it’s maybe not dead so just restart the nginx service to make sure it picks up the django service instance. Generally if you restart django, then you need to restart nginx, because it needs the new internal ip of django (see sequencing upgrade section below as this is the same reasone why upgrades need to happen in sequence).
When upgrading / restarting services, you should take care to do things in the proper order:
- Celery workers first
- Django second
- Nginx last
This will ensure that intercontainer references are maintained properly.