-
Notifications
You must be signed in to change notification settings - Fork 60
move images to their own storage so we don't lose them on every update #207
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
Conversation
Dockerfile
Outdated
| # redirect public img storage into the cache, putting this here and not with the other koel file setups because it makes more sense here, and they are empty folder so don't have a significant impact on file size | ||
| && rm -r /var/www/html/public/img/artists \ | ||
| && rm -r /var/www/html/public/img/avatars \ | ||
| && rm -r /var/www/html/public/img/covers \ | ||
| && rm -r /var/www/html/public/img/playlists \ | ||
| && ln -s /images/artists /var/www/html/public/img/artists \ | ||
| && ln -s /images/avatars /var/www/html/public/img/avatars \ | ||
| && ln -s /images/covers /var/www/html/public/img/covers \ | ||
| && ln -s /images/playlists /var/www/html/public/img/playlists \ | ||
| && ln -s /images/radio-stations /var/www/html/public/img/radio-stations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work with the current installations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this happens in the container build step so all this does is remove the blank folders that where put there from the unpacking of the koel files and replace them with symlinks
anyone with a current setup that has a mount pointing to one of these locations and leaves that as is, that will replace the symlink again with their already configured mount and it will keep working. for anyone not having a mount on these locations it will just use the image folder instead (and that's a volume now)
and no this won't delete existing data since the remove happens in the docker building, users who did not have a mount on these locations have already lost the image data they started the new docker container (with or without this change)
|
rebased to resolve the conflicts |
|
Thanks! |
|
Hi, sorry I'm going to revert this following the change in koel/koel#2086. Basically, starting from the next version, Koel will store all generated and uploaded images (album arts, artist images, etc.) under one single path: |
|
Changes are up in ccdfd02. If you have a better idea, I'm all ears :) |
|
it basically does the same with less steps, looks good to me |
move all the img folders to a /images folder (and make it a volume) for persistent storage. right now each time you update the container (provided you followed only the recommended mappings) you only keep the album covers and everything else breaks
for compatibilty and ease of use this is done by making a /images folder and symlinking the relevant image folders into it. This allows users to simply mount at /images to persist them all instead of needing individual mounts (and add more when if more are needed later)
to further ensure ease of use the entrypoint will ensure all needed folders are present and owned by the www-data user.
IMPORTANT: it doesn't do this recursively because this can be a lot of images and unless the user messed with things it should already be owned by the correct user. doing it recursively would thus only slow down the startup significantly for little to no benifit
finally it cleans up some unneeded manipulations of the /tmp/koel folder