Mapserver docker

---

Rationale of this fork

This is not the official mapserver-docker, but merely a demo for running Mapserver with MongoDB support. It functions as an exploration for the SensRNet project, which currently makes use of GeoServer.

MapServer doesn't support MongoDB by default, but it can still be achieved by using a OGR Vector Layer. It supports a MongoDBv3 driver, but requires GDAL to be built with the Mongocxx driver.

An example feature map is included in examples/devices.map. The connection details to the Mongo database is defined in there. An example Mongo can be constructed using https://github.com/kadaster-labs/sensrnet-registry-backend, and the results be viewed with https://github.com/kadaster-labs/sensrnet-central-viewer/tree/mapserver-for-serving-features.

docker build -t mapserver-mongo -f Dockerfile.mongocxx .
docker run --rm -d -p 8082:80 \
           -e MS_MAPFILE=/srv/data/devices.map \
           --name mapserver-example \
           -v `pwd`/example:/srv/data \
           --network backend --link sensrnet-registry-backend-mongo-1 \
           mapserver-mongo

docker stop mapserver-example

MapServer is then available on http://localhost:8082/?request=getcapabilities&service=wfs.

Test Mongo connection

In the builder stage of the Dockerfile, standard ogr tools are available and can be used to check the connection to MongoDB.

docker build --target builder -t mapserver-mongo -f Dockerfile.mongocxx .
docker run --rm -it --network host mapserver-mongo

ogrinfo -ro MONGODBV3:mongodb://localhost:27017/sensrnet
ogrinfo -ro MONGODBV3:mongodb://localhost:27017/sensrnet devices -summary

Test security

docker run -ti --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.cache:/root/.cache \
  aquasec/trivy:0.23.0 image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed --vuln-type os,library mapserver-mongo

To Do

⚠️ While MapServer works quite nicely with Mongo, there was one problem which makes adoption for SensRNet not possible (yet). MongoDB usually makes use of a UUID identifier. The OGR layer, however, only supports Feature IDs of type integer (https://gdal.org/drivers/vector/mongodbv3.html#feature-id). This means that each feature gets a random integer assigned each time the database is queried. On the map they are therefore drawn as new features each time the WFS layer is reloaded. To circumvent this, we would have to add a unique integer property (i.e. ogc_fid) to the MongoDB documents.

---

TL;DR

docker build -t pdok/mapserver .
docker run -e MS_MAPFILE=/srv/data/example.map --rm -d \
            -p 80:80 --name mapserver-example -v `pwd`/example:/srv/data pdok/mapserver

docker stop mapserver-example

Introduction

This project aims to fulfill two needs:

1. create OGC services that are deployable on a scalable infrastructure.
2. create a useable Docker base image.

Fulfilling the first need the main purpose is to create an Docker base image that can be run on a platform like Kubernetes.

Regarding the second need, finding a usable Mapserver Docker image is a challenge. Most images expose the &map=... QUERY_STRING in the GetCapabilities, don't run in FastCGI and are based on Apache.

What will it do

It will create an Mapserver application that runs through Lighttpd. With lua scripting the map=... QUERY_STRING is filter from incoming request. In other words the used Mapfile can only be set with an ENV.

The included EPSG file containing the projection parameters only contains a small set of available EPSG code, namely the once used by our organization. If one wants to use additional EPSG projections one can overwrite this file.

Docker image

The Docker image contains 2 stages:

1. builder
2. service

builder

The builder stage compiles Mapserver. The Dockerfile contains all the available Mapserver build option explicitly, so it is clear which options are enabled and disabled.

service

The service stage copies the Mapserver application, build in the first stage to the service stage, and configures Lighttpd

Usage

Build

docker build -t pdok/mapserver .

For a specific Dutch version which includes a specific (and smaller) epsg file and necessary grid corrections files.

docker build -t pdok/mapserver:nl -f Dockerfile.NL .

Run

This image can be run straight from the CLI. A volume needs to be mounted on the container directory /srv/data. The mounted volume needs to contain a mapserver *.map file that matches the MS_MAPFILE env.

docker run -e MS_MAPFILE=/srv/data/example.map --rm -d \
           -p 80:80 --name mapserver-example -v `pwd`/example:/srv/data pdok/mapserver

Running the example above will create a service on the url http://localhost/?request=getcapabilities&service=wms

The ENV variables that can be set are the following

DEBUG
MIN_PROCS
MAX_PROCS
MAX_LOAD_PER_PROC
IDLE_TIMEOUT
MS_MAPFILE

PROJ_LIB

The ENV variables, with the exception of MS_MAPFILE have a default value set in the Dockerfile.

The GDAL PROJ_LIB env is default set with the value /usr/share/proj. For performance reasons one would like to set a custom PROJ_LIB containing a minimum of available EPSG codes. This can be done with the mentioned PROJ_LIB env.

docker run -e DEBUG=0 -e MIN_PROCS=1 -e MAX_PROCS=3 -e MAX_LOAD_PER_PROC=4 \
           -e IDLE_TIMEOUT=20 -e MS_MAPFILE=/srv/data/example.map --rm -d \
           -p 80:80 --name mapserver-run-example -v `pwd`/example:/srv/data pdok/mapserver

Projections

Altering the proj file is done for different reasons, adding custom projections or removing 'unused' ones for better performance. This can be done in a couple of ways through this setup.

base image

The best example for this is the Dockerfile.NL in this repository. This Dockerfile uses the main Dockerfile as a base image copies specific geodetic grid files and overwrites the default espg with a tuned one for the Netherlands.

A good resource for these geodetic files is the proj cdn.

volume

Another option is to create a proj file (like in the nl dir) and mount this to the container and set the PROJ_LIB env to that location by adding the following parameters to the docker command.

-e PROJ_LIB=/my-custom-proj-dir

-v `pwd`/path/to/proj/dir:/my-custom-proj-dir

Example

When starting the container it will create a WMS & WFS service on the end-point

http://localhost?

Example request

http://localhost/?request=getfeature&service=wfs&VERSION=2.0.0&typename=example:example&count=1

http://localhost/?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=50,2,54,9&CRS=EPSG:4326&WIDTH=905&HEIGHT=517&LAYERS=example&STYLES=&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE

http://localhost/?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&BBOX=48.9306039592783506,0.48758765231731171,55.46504193821721884,12.33319204541738756&CRS=EPSG:4326&WIDTH=1530&HEIGHT=844&LAYERS=example&STYLES=&FORMAT=image/png&QUERY_LAYERS=example&INFO_FORMAT=text/html&I=389&J=537&FEATURE_COUNT=10

Misc

Why Lighttpd

In our previous configurations we would run NGINX, while this is a good web service and has a lot of configuration options, it runs with multiple processes. There for we needed supervisord for managing this, whereas Lighttpd runs as a single process. Also all the routing configuration options aren't needed, because that is handled by the infrastructure/platform, like Kubernetes. If one would like to configure some simple routing is still can be done in the lighttpd.conf.

How to Contribute

Make a pull request...

Contact

Contacting the maintainers can be done through the issue tracker.

Used examples

• https://github.com/srounet/docker-mapserver
• https://github.com/Amsterdam/mapserver