Cloud Native GeoServer is GeoServer ready to use in the cloud through dockerized microservices.
This project is an opinionated effort to split GeoServer's geospatial services and API offerings as individually deployable components of a microservices based architecture.
As such, it builds on top of existing GeoServer software components, adapting and/or extending them in an attempt to achieve functional decomposition by business capability; which roughly means each OWS service, the Web UI, the REST API, and probably other components such as the Catalog and Configuration subsystem, become self-contained, individually deployable and scalable micro-services.
gscloud-1.0-RC2_screencast.mp4
The following diagram depicts the System's general architecture.
Cloud Native GeoServer Architecture Diagram
Does that mean GeoServer's .war is deployed several times, with each instance exposing a given "business capability"?
ABSOLUTELY NOT.
Each microservice is its own self-contained application, including only the GeoServer dependencies it needs. Moreover, care has been taken so that when a dependency has both required and non-required components, only the required ones are loaded.
With GeoServer being a traditional, Spring Framework based, monolithic servlet application, a logical choice has been made to base the GeoServer derived microservices in the Spring Boot framework.
Additionally, Spring Cloud technologies enable crucial capabilities such as dynamic service discovery, externalized configuration, distributed events, API gateway, and more.
Only a curated list of the vast amount of GeoServer extensions will be supported, as they are verified and possibly adapted to work with this project's architecture.
CN GeoServer licensed under the GPLv2.
Requirements:
- Java >= 17 JDK
- Maven >=
3.6.3 - Docker version >=
19.03.3 - docker-compose version >=
1.26.2
The simple make command from the project root directory will
build and install all the required components, including upstream GeoServer
dependencies and GeoServer-Cloud Docker images. So for a full build just run:
makeThen for further builds, unless the geoserver_submodule/ has changed,
you can build without running tests with
make installand run tests with
make testCloud Native GeoServer depends on a custom GeoServer branch,
geoserver-cloud_integration, which contains patches to upstream
GeoServer that have not yet been integrated into the mainstream
main branch. Additionally, the geoserver-cloud_integration
GeoServer branch changes the artifact versions from 2.21-SNAPSHOT
to 2.23.0-CLOUD, to avoid confusing maven if you also work
with vanilla GeoServer, and to avoid your IDE downloading the
latest 2.23-SNAPSHOT artifacts from the OsGeo maven repository,
overriding your local maven repository ones, and having
confusing compilation errors that would require re-building
the branch we need.
The geoserver-cloud_integration branch is checked out as a
submodule under the geoserver_submodule/geoserver directory.
The root pom.xml defines a geoserver maven profile, active
by default, that includes the module geoserver_submodule, which
in turn includes all the required geoserver modules for this project.
So in general, you may chose to only eventually build the
geoserver_submodule subproject, since it won't change
frequently, with
make depsAs mentioned above, a make with no arguments will build everything.
But to build only the docker images, run:
make build-imageCloud Native GeoServer-specific modules source code
is under the src/ directory.
When you already have the 2.23.0-CLOUD GeoServer artifacts,
you can chose to only build these projects, either by:
$ ./mvnw clean install -f src/Or
$ cd src/
$ ../mvnw clean installThe docker-compose.yml file and the accompanying overrides
docker-compose-shared_datadir.yml, docker-compose-jdbcconfig.yml,
and docker-compose-standalone.yml at the project's root
directory are meant for development and testing purposes, not
for production use.
You'll find more production-suitable deployment files for docker-compose and podman under the docs/deploy folder.
Also, a ready-to-use Helm chart for Kubernetes is available at the camptocamp/helm-geoserver-cloud Github repository.
To run the development docker composition using a shared data directory. GeoServer-Cloud can start from an empty directory.
$ mkdir docker-compose_datadir
$ alias dcd="docker-compose -f docker-compose.yml -f docker-compose-shared_datadir.yml"
$ dcd up -dNote: In case you want to start the docker composition and being able to test some layers, you can copy data/release datadir that is part of the geoserver_submodule instead of creating the docker-compose_datadir emtpy folder, as follow:
$ cp -rf ./geoserver_submodule/geoserver/data/release /tmp/datadir
$ ln -s /tmp/datadir docker-compose_datadirVerify the services are running with dcd ps.
Healthckecks use curl hitting the http:localhost:8081/actuator/health.
The services run on the 8080 port, and are exposed using different
host ports. The spring-boot-actuator is set up at port 8081.
The gateway-service proxies requests from the 9090 local port:
$ curl "http://localhost:9090/geoserver/cloud/ows?request=getcapabilities&service={WMS,WFS,WCS}"
$ curl -u admin:geoserver "http://localhost:9090/geoserver/cloud/rest/workspaces.json"
Browse to http://localhost:9090/geoserver/cloud
Note the
/geoserver/cloudcontext path is set up in thegateway-service's externalized configuration, and enforced through theGEOSERVER_BASE_PATHindocker-compose.yml. You can change it to whatever you want. The default config/gateway-service.yml configuration file does not set up a context path at all, and hence GeoServer will be available at the root URL.
Please read the contribution guidelines before contributing pull requests to the CN GeoServer project.
Follow the developer's guide to know more about the project's technical details.
v1.2.0 released against GeoServer 2.23.0.
Read the changelog for more information.
CN GeoServer's issue tracking is at this GitHub repository.
Follow the development progress on these GitHub Kanban boards