SongKong is also available for the Docker platform, the advantage of this is that by making a build available for Docker, this then allow SongKong to be used on any hardware that supports Docker without having to do separate builds for each platform, we don’t even have to be aware of the platform.
Docker builds (called images) are not completely hardware independent so we offer both an Intel Docker Image (songkong/songkong) and an Arm 32 Docker Image (songkong/songkong-arm32) and these are available from DockerHub and are usually automatically available via the Docker platform you are using.
Docker images can be used by installing Docker on your platform, but more usually the Docker platform is already part of your platform. We have tested SongKong Docker version on Synology Nas, Qnap Nas & Unraid and provide instructions on how to use their installation gui to install and configure SongKong.
Example 1
But Docker also provides a command line interface. So the following line creates a container based on the songkong/songkong image that runs SongKong. It runs in remote mode (because it is configured to use -r by default in the docker image) with the SongKong configuration and licensing stored in CONFIGFOLDER and the root music folder stored in MUSICFOLDER. So CONFIGFOLDER and MUSICFOLDER should be replaced with the actual path of two real folders on your system. For SongKong to make use of them they should always be mapped to /songkong and /music
MUSICFOLDER and CONFIGFOLDER are two special parameters that should usually be configured for the Docker version of SongKong, they are not required on regular platforms. They are needed to connect your real filesystem with the virtual filesystem provided within the docker container.
This is the standard run SongKong in interactive remote mode
docker run -v CONFIGFOLDER:/songkong -v MUSICFOLDER:/music songkong/songkong
Example 2
whereas
docker run -v CONFIGFOLDER:/songkong -v MUSICFOLDER:/music songkong/songkong -m /music/
Runs Fix Songs (using -m) against the MUSICFOLDER because first we map MUSICFOLDER to /music and then we specify /music as as parameter to songkong
Example 3
Lets assume our music is stored at /paul/mymusic and within that there is a subfolder for the band radiohead, and also we would like to store our songkong configuration in a folder called /config/songkongdata then we run fix songs against all our music with
docker run -v /config/songkongdata:/songkong -v /paul/mymusic:/music songkong/songkong -m /music/
If we only wanted to run Fix Songs against radiohead we could do
docker run -v /config/songkongdata:/songkong -v /paul/mymusic:/music songkong/songkong -m /music/radiohead
Remember the folder that SongKong sees as /music is actually /paul/mymusic in this case.
Advanced CONFIGFOLDER
If CONFIGFOLDER is not configured then SongKong will still work but all configuration including the logs, database, cache and licensing will be stored within the container. So if you destroy this container such as replacing it with a new version of SongKong you will lose all this information, and will have to reinstall the license.
Advanced MUSICFOLDER
We no longer require you to mount your music to the /music virtual mount point. SongKong will by default show the complete virtual filesystem and therefore as long as your mount music drive(s) to a virtual folder somewhere it will be visible to SongKong.
However, for most users we recommend continuing to mount your music to /music, also there is an option on the Docker version that can hide the whole filesystem tree and just show the the tree from /music