We are currently evaluating GeoServer Cloud and are looking for best practices regarding environment promotion.
We are looking to promote GeoServer Cloud across different environments (e.g., Test→Staging→Prod).
Our environment consist of several on-premise Kubernetes clusters and we are currently deploying the solution using helm. We have built a umbrella helm chart that is based on camptocamp’s helm chart for GeoServer Cloud along with PostgreSQL and RabbitMQ.
While promoting the helm chart across multiple environments is straight forward, we are looking for the best way to handle the promotion of the PostgreSQL catalog backend.
I would also be interested in the solution. At the moment, we remain on the XML configuration files, which are nicely handled by any source control (e.g. Git) and we can observe and manage changes and deploy via CI pipelines. I would like to know how best to do the same with Postgres (other than SQL backup and restores).
You have several ways to do so, depending on the use case of GeoServer Cloud:
If you use GS Cloud as a service provider of a business application, with the same set of datastores/layers/styles on the different environments and no config changes (or little) after deployment, you could have a look to the Terraform provider Camptocamp has developed for the GeoServer configuration. You describe the expected configuration as terraform files and apply it to each environment. We use it on a critical system with a dozen environments to update at each release, every two weeks.
If you use GS Cloud as the core of some kind of SDI, with several changes done through the UI or by several people, you could explore the dump/restore of the pgconfig database. I never used it by myself but it should work.
In both cases, it is only the configuration (xml and property files) which will be promoted. You cannot use these options to promote stuff like icon files or data directly stored in the data_dir (but since you are on K8s it shouldn’t be the case).
