Replace database backend as part of future swarm support

[andyloree]

As titled, current database usage appears to be limited to settings and users in SQLite. As there is no shared storage engine mechanism for SWARM and multi-node containers, and the fact that SQLite cannot operate safely without corruption on any network file service (CIFS/NFS) connectivity. While you can leverage CEPH, GlusterFS or similar in multi-node setups, those introduce further limitations for scaling and non-containerized dependences on the host nodes.

Switching to another form of persistence for settings would be ideal, like using app-side caching and writing to simple config file would allow for CIFS/NFS support without complication of heavy weight DBMS or storage block systems, and allow for dockge to be first service for managing swarm within swarm (from manager nodes or remotely in docker context).

[almereyda]

Indeed currently each dockge instance is already bound to a single source of truth for its runtime configuration. It could also persist a little YAML file .dockge.yaml and that'd be it.

This would also render the configuration very portable, and loosely coupled to the environment it describes.

Are there more stateful parts of the application, other than settings and users, excluding login sessions?

User management could be handed off completely to OIDC, in so settings keep only references to remote identities.

[andyloree]

I would agree, giving OIDC as the "external/enterprise" option, but also having a "keep it simple" single user option via config file would cover most every use-case