Release 0.2.0
Pre-releaseRelase 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 -d
Wait 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 ... done
Major 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
)