Objects Not Stored in Database

I’m trying to setup Cockpit on docker/kubernetes. I’ve configured it to use MongoDB for storage, however objects such as Singletons, Collections and Forms are still being written to the filesystem instead.

Is this the intended behaviour? The ideal setup for running in docker would be to write all data to an external database and all assets to cloud storage.

By default the cockpit data structures (collections, singletons, forms) are saved in the filesystem (contents are saved in database).

@pauloamgomes Do we have a good pattern for doing containerized deployments? This seems to be a bit of struggle. Perhaps support for storage/ location on s3 bucket (or other external storage) might be a good start.

schemas for collections, singletons etc should always be stored in a version control system (eg git) and placed correctly during a build/deploy task.

another option would be mounted folders to have persisted storage

Thanks for the replies all.

The solution that we’re using on our production installation is a persistent disk to hold the storage data.

Correct me if I’m wrong but there’s no way to automatically commit data structures to a vcs when they are modified in Cockpit, this would surely have to be done manually after every change. Of course the structures could easily be restored during the build phase as we’re having to copy our config to the image with a custom docker file.

The more ‘container’ way to do things would be to store the config values in environment variables, all assets in cloud storage (s3/gcs), and all other data in the database. With this setup the stock image could easily be setup in an environment like Kubernetes.

Isn’t there a s3 volume mount plugin for docker? :thinking:

There is, but it only supports the storage of assets such as images/thumbs as far as I know. :slightly_frowning_face:

In a container setup this means that a mounted volume is still needed, which is overkill for what is being stored.