Exporting part or all of a configuration from one GeoServer installation to another

Question

I'm using a desktop installation of 2.20.4 for setting up and testing my configuration (layers, stores, workspaces). Now I need to move this into an integration environment, then in production.

I found no tool to properly move part or all of a configuration from one environment to another, other than copying the data directory. The last answers I found data from 2013, and it seems nothing has progressed ...

Is that still the case: copying the data directory is still the only way? Is there any way to do this selectively - like copying only a store definition and the layers published from that store? Or a workspace and the stores associated with this workspace.

Important: All my data is in an Oracle database: I have no local data (no actual data files).

Answer 1

Copying the data directory is the only officially supported way.

Anedoctically, it's also possible to copy over a workspace, as long as you are careful to put all the styles used by the layers in the same workspace, as well as all the layer groups. Long story short, make the workspace self-contained, with no external references. This should work because the identifiers of each configuration element (store, layer, style, ...) is generated from a UUID.

Answer 2

We copy parts of the data directory.

One of the problems according to our experience is that copying the entire data directory also copies all security settings, including master password and encryption keys. In a dev->test->prod environment lifecycle you may want to access data from different databases in the different environments and define different access rights.

Supported or not, this is how we solved it:

• We have the data directory in a git repo and exclude some settings, especially the security folder
• We configure Geoserver in a development environment and check in changes to git
• We deploy the data dir from git to the test environment using octopus deploy

In order to use different databases for the different environments octopus replaces the connection parameters to all database datastores by replacing the connection parameters in all datastore.xml files.

The biggest drawback is that we're using plaintext passwords in the datastore.xml files as octopus does not know how the encrypted form looks like before it is saved to the server and we're using different encryption keys in the environments. A work around we be making geoserver save a datastore file on the target environment and copy the encrypted password to octopus before the first deployment. You'll still lose the salt effect in the password unless you repeat the procedure for each instance of the password. But we haven't bothered as we have very restricted access to the production server. A word of warning though: using the rest API it is possible to read the unencrypted password using the resources endpoint. Another solution would be sharing the same encryption key and create the connection in the development environment and copy the encrypted password from there. Another vulnerability is that passwords are checked in to git, but those are encrypted with the key on the development machine and only works for the development database that only contains bogus data anyway.

Another approach would possibly be using the Rest Api to read all necessary configuration from one environment and push it to the next using the Rest Api after replacing the connection parameters. But we haven't tested that as it seems a bit more work to implement.