Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Object Storage #403

Open
rjhenry opened this issue Mar 16, 2024 · 3 comments
Open

[Feature Request] Object Storage #403

rjhenry opened this issue Mar 16, 2024 · 3 comments

Comments

@rjhenry
Copy link

rjhenry commented Mar 16, 2024

I run most of my tools in Kubernetes, making use of object storage to minimise dependencies on local storage for uploads (and the like). Would adding the ability to use S3 (or S3-compatible tools, such as MinIO) be something that would be considered? I would imagine that this would work in the same way as using Postgres for a database, where backups are explicitly not managed by LubeLog any more.

Taking a rough look at a temporary Docker instance I started, it looks as though images and documents (/App/wwwroot/images and /App/wwwroot/documents respectively) could be reasonably easily replaced with object storage.
Translations (translations, /App/wwwroot/translations) look like a viable candidate to be replaced with a ConfigMap mounted to the right directory (and managed outside of LubeLog itself beyond selecting the language to use). This would only work for Kubernetes deployments, but similar could be accomplished in Docker "vanilla" by mounting a particular file in rather than a directory. Alternatively, support for object storage here would also work.
Config (config, /App/config/) looks like it could be a prime candidate to be migrated into the database - from the looks of things, you already do when authentication is enabled. Is it used for anything else?
Data - when using Postgres - looks to be unused so I haven't looked at this at all.
The only remaining directory that I am slightly confused by is the keys directory - from what I can tell, files and images aren't encrypted in any way, so I'm unsure as to what the keys are used for and by extension how that could be "kubernetes-ified". Possibly mounting via a secret, or possibly from some kind of env var?

I don't know much C# otherwise I would be trying to implement this myself, but I am more than happy to run tests and the like.
Thanks for spending your time and effort on a fantastic tool for the community!

@hargata
Copy link
Owner

hargata commented Mar 16, 2024

I'd think the documents, images and translation files would be the easiest to migrate over, but the tricky part would be the config and keys directory.
The config file is still used for authenticating the root user(the first set of credentials you set up when you enable authentication) and the settings in there is the default settings for all new users(they inherit the settings such as dark mode, etc. from the base server config)

The keys directory is the trickiest one since changing it from the default directory to any other directory will require a lot of additional configuration. The keys are used for encrypting / decrypting session cookies to prevent spoofing and is an implementation provided by Microsoft.

@rjhenry
Copy link
Author

rjhenry commented Mar 16, 2024

Thanks for the well-thought-out response. Do you think a middle ground wherein documents, images and translation files are in object storage and then the other config and keys are managed on a persistent volume of some description?
It's less than ideal, as if that volume were to go away then the root user wouldn't be able to sign in and the sessions cookies would all be rendered useless, but does mean that documentation around vehicles is still preserved (and externally managed/backed up). It doesn't solve all the problems, but does at least mean the minimum of storage is required for the container/pod itself.

I wonder if anyone else would have any suggestions on how to manage config and/or keys directories?

@shanduur
Copy link

shanduur commented Sep 12, 2024

The Keys does not need to be stored on the FS, and Redis is a good option to make that little bit more HA capable: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers?view=aspnetcore-8.0&tabs=visual-studio#redis

Config in Kubernetes is not tricky at all (although changes to it are not persistent), I am working on implementing it in the deployment phase, and I it's almost done (PTAL: anza-labs/charts#15)

Documents, images and translations are probably the thing to focus on, although I'm completing automatic translation management during the installation on Kubernetes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants