-
Notifications
You must be signed in to change notification settings - Fork 8
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
Docker support? #17
Comments
Wow this would be great to see in this package! Any thoughts @jbh-cloud? |
@danielcharrua the main reason I've held off on this is that currently spotify_sync stores all of its state in user data. This includes which songs have been matched, downloaded etc. Adding docker to the mix would warrant the need to do bind volume mounting to ensure it still access to this from the host which kinda negates the transience of docker. Adding configuration into the mix (as a bind volume) and potentially supporting profiles would also add complexity to this. It's possible to refactor the code base to support this configuration via environment variables etc. but would require another way to validate parameters (currently using json schema). I'm not opposed to adding docker support but I'm not sure I understand the requirements / use case (apart from specifically running on a NAS). Happy for anyone with an idea of how they would expect to use it to chime in :) |
use cases: |
Yes, also doing a daily/weekly backup of your library on a NAS running docker would be a great one. |
I have a working Dockerfile |
testet on ubuntu |
@erstert3st first of all, thanks for you work on this! I guess it kind of brings me back to my original usecase question. Are we wanting to replicate the exact functionality of it but just allow it to be run via docker or do we want to extend it? Your implementation is designed to run in docker as a continuous process (while True loop) against a specific config file that is built into the image. As it stands spotify_sync is designed to be a one-shot application as opposed to long running instance. I think I would prefer a more bare-bones setup where spotify_sync is the docker entrypoint allowing power users more flexibity if they chose. E.g Cache spotify oauth token once (could even do this from any other machine and put the file in the right directory instead)
The run it..
If people are fine with this, it means no code change (apart from a |
first the loop thing, The other thing, I'm fine with this but it's not the Docker way, to depend on an external file that is needed to work. |
Sorry I have been really busy and haven't had much time. First of all, I completely agree that volume bind mounts pretty much go against the whole point of docker. I would love to support completely argument parsed configuration. However this is currently hindered by:
I have some thoughts about how this may work going forward but would be a significant rewrite to faciliate. In the interim, here is a fully working example running it via volume mounts. It also allows you to access all of the subcommands (as these are just passed in as paramters to the entrypoint...
|
Apologies for the long writeup and very janky way of making this work, I am not an expert on Docker and sort of threw this together while reading lots of documentation, but it works. :) I now have this working in Unraid now as a User Script running on a schedule. Here's the breakdown of how I did it: I cloned the repository to my appdata to start, this is the command I used:
Then, in the same folder, I added a Dockerfile and a requirements.txt file Dockerfile:
Requirements.txt:
Building the docker image we just made in the terminal:
First run (auth, initial bulk song saving, etc)Next, we'll run the docker image in a terminal. This will be run in interactive mode so we can do the initial setup. We will also mount a few folders so that the information persists for future runs:
The first thing we'll do is create a starting point for our config file by using the command in the Quick Start guide:
Make sure to go in and edit your newly created config.json, adding in all the info that is relevant to you. In this example, we will make the download directory /music Then create a profile, replace myFirstProfile with whatever you want it to be named:
Create a Spotify app, as outlined in the docs, and then go through with the Spotify authentication:
Now you're ready to run the download script for the first time.
Once this one-time saving of your initial library is complete, you can go ahead and make this an automated script for future purposes (where you will be adding only new songs to your library) User Script Setup (scheduling future runs)First, you'll need the User Scripts plugin from the Community Applications. Once you have that, you'll make a new script. I named mine Spotify to Plex Sync. You'll go in and edit the script and paste this in:
Essentially, this does a few things: it first removes any instance of the spotify-sync image, so there are no conflicts, then it mounts the previous folders we need within the app so that the saved state of already downloaded songs persists. Then it is running two commands, the first is latching the config to our profile and the second runs spotify_sync in auto mode with that profile. Save your changes once you add this script, and make the cron on it whatever you'd like. I have it set to 0 * * * * which makes it run at the top of every hour. Hit Apply at the bottom of the page and your script should run automatically from now on! 🎉 |
Any thoughts on running this from docker?
I am an avid unraid user and think that having this run via docker would make sense. Dockerfile could look something like this?
requirements.txt
dockerfile
The text was updated successfully, but these errors were encountered: