Please use https://github.com/PDOK/mapserver-docker
docker build -t pdok/mapserver-wms-ogr .
docker run -e MS_MAPFILE=/srv/data/example.map -d -p 80:80 --name mapserver-example -v /path/on/host:/srv/data pdok/mapserver-wms-ogr
docker stop mapserver-example
docker rm mapserver-example
This project aims to fulfill two needs:
- create a OGC services that are deployable on a scalable infrastructure.
- create a useable Docker base image.
Fulfilling the first need the main purpose is to create an Docker base image that eventually 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.
It will create an WMS-only Mapserver application run with a lightweight web application Lighttpd in which the map=.. QUERY_STRING issue is fixed. The application is configured for service raster files (GeoTIFF)
This stack is composed of the following:
Mapserver is the platform that will provide the WMS services based on a raster datasource.
For transforming simple features from a data store to WFS features.
Lighttpd is the web server we use to run Mapserver as a fastcgi web application.
The Docker image contains 2 stages:
- builder
- service
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.
The service stage copies the Mapserver, build in the first stage, and configures Lighttpd.
docker build -t pdok/mapserver-wms-ogr .
This image can be run straight from the commandline. A volumn needs to be mounted on the container directory /srv/data. The mounted volumn needs to contain at least one mapserver *.map file. The name of the mapfile will determine the URL path for the service.
docker run -d -p 80:80 --name mapserver-run-example -v /path/on/host:/srv/data pdok/mapserver-wms-ogr
The prefered way to use it is as a Docker base image for an other Dockerfile, in which the necessay files are copied into the right directory (/srv/data)
FROM pdok/mapserver-wms-ogr
ENV MS_MAPFILE /srv/data/example.map
COPY /etc/example.map /srv/data/example.map
Running the example above will create a service on the url http://localhost/?request=getcapabilities&service=wcs
The ENV variables that can be set are:
- DEBUG
- MIN_PROCS
- MAX_PROCS
- MAX_LOAD_PER_PROC
- IDLE_TIMEOUT
- MS_MAPFILE
The ENV variables, with the exception of MS_MAPFILE have a default value set in the Dockerfile.
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 -d -p 80:80 --name mapserver-run-example -v /path/on/host:/srv/data pdok/mapserver-wms-postgis
If one wants a OGC WFS service, then we have our pdok/mapserver-wfs-postgis image. So why are those (WFS and WMS) seperated? We regard both service as completly different. Regarding microservices it is logical to split those from each other. Also in our experience we have run to often into issues that the same data is exposed as a WMS and WFS.
In our previous configurations we would run NGINX, while this is a good webservice and has a lot of configuration options, it runs with multiple processes. There for we needed supervisord for managing this, whereas Lighthttpd runs as a single proces. 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.