Deployment¶

Testing¶

The serve-develop subcommand of mapproxy-util starts an HTTP server for local testing. It takes an existing MapProxy configuration file as an argument:

mapproxy-util serve-develop mapproxy.yaml

The server automatically reloads if the configuration or any code of MapProxy changes.

--bind, -b¶

Set the socket MapProxy should listen. Defaults to localhost:8080. Accepts either a port number or hostname:portnumber.

--debug¶

Start MapProxy in debug mode. If you have installed Werkzeug (recommended) or Paste, you will get an interactive traceback in the web browser on any unhandled exception (internal error).

The serve-multiapp-develop subcommand of mapproxy-util works similar to serve-develop but takes a directory of MapProxy configurations. See MultiMapProxy.

Production¶

There are two common ways to deploy MapProxy in production.

Embedded in HTTP server

You can directly integrate MapProxy into your web server. Apache can integrate Python web services with the mod_wsgi extension for example.

Behind an HTTP server or proxy

You can run MapProxy as a separate local HTTP server behind an existing web server (nginx, Apache, etc.) or an HTTP proxy (Varnish, squid, etc).

Both approaches require a configuration that maps your MapProxy configuration with the MapProxy application. You can write a small script file for that.

Running MapProxy as a FastCGI server behind HTTP server, a third option, is no longer advised for new setups since the FastCGI package (flup) is no longer maintained and the Python HTTP server improved significantly.

mapproxy-util create -t wsgi-app -f mapproxy.yaml config.py

from mapproxy.wsgiapp import make_wsgi_app
application = make_wsgi_app('examples/minimal/etc/mapproxy.yaml')

from mapproxy.wsgiapp import make_wsgi_app
application = make_wsgi_app('examples/minimal/etc/mapproxy.yaml', reloader=True)

Apache mod_wsgi¶

The Apache HTTP server can directly integrate Python application with the mod_wsgi extension. The benefit is that you don’t have to start another server. Read mod_wsgi installation for detailed instructions.

mod_wsgi requires a server script that defines the configured WSGI function as application. See above.

You need to modify your Apache httpd.conf as follows:

# if not loaded elsewhere
LoadModule wsgi_module modules/mod_wsgi.so

WSGIScriptAlias /mapproxy /path/to/mapproxy/config.py

<Directory /path/to/mapproxy/>
  Order deny,allow
  Allow from all
</Directory>

mod_wsgi has a lot of options for more fine tuning. WSGIPythonHome or WSGIPythonPath lets you configure your virtualenv and WSGIDaemonProcess/WSGIProcessGroup allows you to start multiple processes. See the mod_wsgi configuration directives documentation. Using Mapnik also requires the WSGIApplicationGroup option.

A more complete configuration might look like:

# if not loaded elsewhere
LoadModule wsgi_module modules/mod_wsgi.so

WSGIScriptAlias /mapproxy /path/to/mapproxy/config.py
WSGIDaemonProcess mapproxy user=mapproxy group=mapproxy processes=8 threads=25
WSGIProcessGroup mapproxy
# WSGIPythonHome should contain the bin and lib dir of your virtualenv
WSGIPythonHome /path/to/mapproxy/venv
WSGIApplicationGroup %{GLOBAL}

<Directory /path/to/mapproxy/>
  Order deny,allow
  # For Apache 2.4:
  Require all granted
  # For Apache 2.2:
  # Allow from all
</Directory>

Behind HTTP server or proxy¶

There are Python HTTP servers available that can directly run MapProxy. Most of them are robust and efficient, but there are some odd HTTP clients out there that (mis)interpret the HTTP standard in various ways. It is therefor recommended to put a HTTP server or proxy in front that is mature and widely deployed (like Apache, Nginx, etc.).

cd /path/of/config.py/
gunicorn -k eventlet -w 4 -b :8080 config:application --no-sendfile

start on runlevel [2345]
stop on runlevel [!2345]

respawn

setuid mapproxy
setgid mapproxy

chdir /etc/opt/mapproxy

exec /opt/mapproxy/bin/gunicorn -k eventlet -w 8 -b :8080 \
    --no-sendfile \
    application \
    >>/var/log/mapproxy/gunicorn.log 2>&1

cd /path/of/config.py/
spawning config.application --threads=8 --processes=4 \
  --port=8080

server {
  server_name example.org;
  location /mapproxy {
    proxy_pass http://localhost:8181;
    proxy_set_header Host $http_host;
    proxy_set_header X-Script-Name /mapproxy;
  }
}

<IfModule mod_proxy.c>
  <IfModule mod_headers.c>
        <Location /mapproxy>
                ProxyPass http://localhost:8181
                ProxyPassReverse  http://localhost:8181
                RequestHeader add X-Script-Name "/mapproxy"
        </Location>
  </IfModule>
</IfModule>

Other deployment options¶

Refer to http://wsgi.readthedocs.org/en/latest/servers.html for a list of some available WSGI servers.

Performance¶

Because of the way Python handles threads in computing heavy applications (like MapProxy WMS is), you should choose a server that uses multiple processes (pre-forking based) for best performance.

The examples above are all minimal and you should read the documentation of your components to get the best performance with your setup.

Load Balancing and High Availablity¶

You can easily run multiple MapProxy instances in parallel and use a load balancer to distribute requests across all instances, but there are a few things to consider when the instances share the same tile cache with NFS or other network filesystems.

MapProxy uses file locks to prevent that multiple processes will request the same image twice from a source. This would typically happen when two or more requests for missing tiles are processed in parallel by MapProxy and these tiles belong to the same meta tile. Without locking MapProxy would request the meta tile for each request. With locking, only the first process will get the lock and request the meta tile. The other processes will wait till the the first process releases the lock and will then use the new created tile.

Since file locking doesn’t work well on most network filesystems you are likely to get errors when MapProxy writes these files on network filesystems. You should configure MapProxy to write all lock files on a local filesystem to prevent this. See globals.cache.lock_dir and globals.cache.tile_lock_dir.

With this setup the locking will only be effective when parallel requests for tiles of the same meta tile go to the same MapProxy instance. Since these requests are typically made from the same client you should enable sticky sessions in you load balancer when you offer tiled services (WMTS/TMS/KML).

Logging¶

MapProxy uses the Python logging library for the reporting of runtime information, errors and warnings. You can configure the logging with Python code or with an ini-style configuration. Read the logging documentation for more information.

mapproxy-util create -t log-ini log.ini

MultiMapProxy¶

You can run multiple MapProxy instances (configurations) within one process with the MultiMapProxy application.

MultiMapProxy can dynamically load configurations. You can put all configurations into one directory and MapProxy maps each file to a URL: conf/proj1.yaml is available at http://hostname/proj1/.

Each configuration will be loaded on demand and MapProxy caches each loaded instance. The configuration will be reloaded if the file changes.

MultiMapProxy as the following options:

config_dir

The directory where MapProxy should look for configurations.

allow_listing

If set to true, MapProxy will list all available configurations at the root URL of your MapProxy. Defaults to false.

from mapproxy.multiapp import make_wsgi_app
application = make_wsgi_app('/path/to.projects', allow_listing=True)