Towards a better integration of GeoServer in a high-available cloud infrastructure

At the origin of the project

Since 2019, Camptocamp has been working with l’Agence du Numérique de la Sécurité Civile (ANSC) to develop the mapping components of its NexSIS 18-112 project.

This project consists of the creation of a set of web applications, allowing civil security actors to receive emergency calls, to qualify (Where? What? Who?) these calls and to choose the resources that will intervene. The year 2021 will be a crucial year for this project, since it is planned to make the NexSIS 18-112 applications available to several fire and rescue services in the Paris region and in provinces.

The applications developed within the NexSIS 18-112 project leave an important place to geography and mapping tools (representation, decision support, etc.). As part of the development of these applications, GeoServer quickly established itself as an essential block, in order to meet a certain number of the needs expressed by the customer.

We were able to help our client identify its constraints and express its goals around GeoServer. Its main wish was to get closer to a high-availability GeoServer and make it more resilient. Improving the operability of GeoServer was also a goal to be pursued, as the customer's operations teams were not particularly familiar with this solution. Facing these objectives, the customer set a constraint: this project should not have an impact on developments already carried out, as well as those to come.

Challenge accepted !

Once these elements were brought to our attention, we were able to make a proposal to our client. In particular, we offered to donate the work done to the GeoServer community.

From a technical point of view, our proposal mainly contained three axes:

Store GeoServer configuration in a database (more reliable than a file system)
Improve the functioning of a GeoServer cluster (refresh of the configuration between instances)
Separate GeoServer components into Microservices (WebUI, REST API, WFS Service, WMS, etc.)

After several months of work, the first version of GeoServer Cloud has just been published. This work is kind of an overlay which, applied to GeoServer, improves its availability, resilience and operability.

GeoServer Cloud, which was deployed on our customer’s platforms, now allows to:

Simply share a configuration between several instances of GeoServer
Reliable the refresh of the configuration within these instances via a MOM (RabbitMQ in the case of our customer)
Finely dimension the services exposed by GeoServer (and this for each service)
Improve the resilience of GeoServer in the face of failure and facilitate its maintenance
Simplify the integration of GeoServer in a "cloud" context (a Kubernetes cluster in the case of our customer)

What about tomorrow ?

There is obviously still some work to be done to industrialize all the improvements we wanted to make to GeoServer. However, this work is mature enough to be made public to the community of GeoServer users and contributors. This is why we have officially handed over the keys of this GeoServer Cloud project to OSGeo and GeoServer:

Official repository : https://github.com/geoserver/geoserver-cloud
Documentation : http://geoserver.org/geoserver-cloud/

And to further facilitate the deployment of GeoServer, we are working in parallel on the creation of a Terraform Provider. This tool will be able to generate a GeoServer configuration through calls to the REST API exposed by GeoServer. In other words, it gives us the possibility of managing our GeoServer configuration “as code”, which is particularly useful for versioning this configuration, applying it automatically in a CI / CD chain, etc. A GeoServer cluster therefore becomes completely automatable and the configuration will be applied without any manual intervention by an operator! Those who want to can even get rid of the GeoServer's graphical interface (WebUI)… which is made possible by the microservices split offered by GeoServer Cloud!