Releases: geoserver/geoserver-cloud
Release 0.2.1
Relase 0.2.1, February 25, 2021
v0.2.1 is a patch release adding support to configure CPU and Memory resource limits in the docker composition.
Need to run docker-compose with the --compatibility flag in order for deploy.resources.limits.* to be considered (otherwise they're only obeyed in a swarm deploy).
Change JAVA_OPTS to use -XX:MaxRAMPercentage=[0..100] -XX:MaxRAM=<size><M|G> and hence set the max heap size dynamically based on the available RAM.
The --MaxRAM is set in case docker-compose wasn't (accidentally?) run with --compatibility. Otherwise it's unnecessary
given the percentage set and the memory limit imposed to the container.
A log entry is printed when each service is ready to verify the memory and cpu limits are seen by the JVM.
Release 0.2.0
Relase 0.2.0, February 15, 2021
v0.2.0 code freeze by Dec 31, 2020. Internal priority shifts delayed the release until now, though the system has been deployed in production using Kubernetes since 0.1.0 by end of August 2020.
That said, this is still a second prototype and there WILL be hiccups. Use at your own risk.
Quick start:
$ mkdir gscloud && cd gscould
$ wget "https://raw.githubusercontent.com/camptocamp/geoserver-microservices/v0.2.0/docs/deploy/docker-compose/stable/docker-compose.yml" -O docker-compose.yml
$ docker-compose pull
Pulling rabbitmq ... done
Pulling database ... done
Pulling discovery ... done
Pulling config ... done
Pulling gateway ... done
Pulling catalog ... done
Pulling wfs ... done
Pulling wms ... done
Pulling wcs ... done
Pulling rest ... done
Pulling webui ... done
$ docker-compose up -dWait for the services to start up, check with docker-compose ps until they're healthy. May some service had exited, re-run docker-compose up -d, initial startup may cause timeouts as services compete for resources on a single machine.
Then browse to:
- http://localhost:8761/ to access the Discovery service registry page.
- http://localhost:9090/ for the GeoServer UI. The GateWay service will take care of proxying requests to the appropriate microservice.
Experiment dynamic service registration with docker-compose scale <service>=<instances>, for example:
docker-compose scale wfs=3 wcs=0
Starting gscloud_wfs_1 ... done
Creating gscloud_wfs_2 ... done
Creating gscloud_wfs_3 ... done
Stopping and removing gscloud_wcs_1 ... doneMajor features in this release:
catalog-service
v0.2.0's most important update is the incorporation of the catalog service and the inclusion of, a microservice sitting in between the front-services (wms, wfs, rest, etc) and the actual catalog back-end (still jdbcconfig).
The catalog-service is a reactive web service based on String Webflux and scales well both vertically and horizontally.
The catalog-service back-end is supported by a Reactive Feign client.
Catalog/config pluggable architecture
A huge effort has been made to improve the design of the Catalog and Config subsystems, improving the separation of concerns across abstraction layers. As a result, implementing a new catalog/config backend is much easier.
Catalog/config caching
It is possible to enable spring-cache based caching for the Catalog, Config, and Resource-Store through the externalized configuration.
Catalog and configuration change events are propagated to the event-bus, and all the nodes in the cluster react accordingly, cleaning up whatever is necessary from local caches.
Improved configuration
Common service configuration properties have been collapsed to a single application.yml configuration file (see ./config/application.yml)