MinimServer 2 in Docker - best approach for persistent config?

[mr_smidge]

Firstly, big thanks for creating MinimServer - I've used the older versions for ages and have now decided to do things 'properly' and both buy a full license, and install v2 in a Dockerised environment.

However, I'm unsure what the best practice is to achieve persistent configuration. I followed the instructions on generic Docker setup, and concluded that following the instructions word-for-word would result in configuration being lost after a container restart, i.e. /opt/minimserver/data would be transient and not last beyond the container's lifetime.

So I added the data directory as a read/write persistent volume in my compose file:

Code:

version: "3"
services:
  server:
    image: minimworld/minimserver:2.0.16
    network_mode: host
    environment:
      - TZ=Europe/London
    volumes:
      - /path/to/minimserver/data:/opt/minimserver/data
      - /path/to/music:/Music:ro

This fixes things for now, but seems sub-optimal:

• The directory also contains logfiles in addition to config, and I'm not sure if they should be shared.
• The directory contains a pid file, which probably shouldn't need to survive container restart.
  

The Synology/QNAP guides mention mounting a /MinimServer directory, but it's apparently read-only, and I'm unsure what it should contain in a general-purpose Docker setup.

What is the recommended way to achieve persistent configuration for a Dockerised setup?

Many thanks.


P.S. I got this wrong initially and the transient config ate one of my license activations . Hope it can be reset!

[simoncn]

If you follow the recommended procedure (no shared data folder), stopping and restarting the container should not cause the contents of /opt/minimserver/data to be lost. If you destroy the container and recreate it, this would cause the settings in /opt/minimserver/data to be lost.

I think your solution would work for preserving the MinimServer settings when the container is destroyed and recreated. This is not a supported and tested configuration and I cannot guarantee that it will work correctly in all cases.

You might find that a full license activation created with the original container no longer works if you destroy and recreate the container. Have you tried this?

You are likely to have problems if the data directory is used by more than one container at the same time. If you don't do this, the presence of log and pid files should not be a problem.

Please use the contact form on this page to request a license reset. Please provide your license code in the Message field.

Edit: Please see this thread for discussion of a problem that might possibly be related to sharing the data folder.

[mr_smidge]

Hi Simon,

(28-12-2020 17:18)simoncn Wrote:  If you destroy the container and recreate it, this would cause the settings in /opt/minimserver/data to be lost.

This is exactly what happened - I recreated the container (via compose down/up) and data stored internally within the container was lost.

Quote:I think your solution would work for preserving the MinimServer settings when the container is destroyed and recreated. This is not a supported and tested configuration and I cannot guarantee that it will work correctly in all cases.

So far no issues, so I will keep my fingers crossed. I'm happy with the current workaround, as I want data to be safe if the container is recreated, but it's worth noting that some people advise not storing config/logging within containers:

https://developers.redhat.com/blog/2016/...ontainers/

As MinimServer is now working for me, I don't have a strong opinion on the above.

Quote:You are likely to have problems if the data directory is used by more than one container at the same time. If you don't do this, the presence of log and pid files should not be a problem.

Absolutely - I do not intend to share the data directory beyond just the running instance.

Quote:You might find that a full license activation created with the original container no longer works if you destroy and recreate the container. Have you tried this?

...

Please use the contact form on this page to request a license reset. Please provide your license code in the Message field.

Exactly this - the license activation had disappeared upon recreating the container. After moving the data directory to a volume, I activated again, but showed 2 activations had been made.

Request now sent to reset - many thanks.

[simoncn]

Moving the data directory to a volume will not enable you to destroy and recreate a container (compose down/up) while preserving your previous license activation. To avoid "orphaned" license activations, you will need to deactivate the license before destroying the container and reactivate it in the new container. Alternatively, you can stop and start the container (compose stop/start) instead of destroying it.

[mr_smidge]

(30-12-2020 20:41)simoncn Wrote:  Moving the data directory to a volume will not enable you to destroy and recreate a container (compose down/up) while preserving your previous license activation. To avoid "orphaned" license activations, you will need to deactivate the license before destroying the container and reactivate it in the new container. Alternatively, you can stop and start the container (compose stop/start) instead of destroying it.

The scenario that comes to mind is an upgrade to the version of the minimserver2 Docker image, which would entail a rebuild of the container (please correct me if wrong) - in this case, does an admin need to de-activate/re-activate a license before upgrading?

Thanks!

[simoncn]

To upgrade to a new version (not an online update), you need to do the following:

1) In the old container, deactivate the license
2) Create the new container
3) In the new container, activate the license

If you do the above, no action from an admin (myself) is needed.

Online updates (such as update 179) can be installed in the existing container.

[mr_smidge]

Understood - thank you!

[kennurnes]

(31-12-2020 09:32)simoncn Wrote:  To upgrade to a new version (not an online update), you need to do the following:

1) In the old container, deactivate the license
2) Create the new container
3) In the new container, activate the license

If you do the above, no action from an admin (myself) is needed.

Online updates (such as update 179) can be installed in the existing container.

This thread did provide answers to the same question that I have now after deploying MinimServer in a docker environment. Good to see that the persistent config works out but on the other hand how it doesn't seem to work then with automatic update pulling the Latest builds and automatic deploy using Watchtower. Also, deploying a new version seems to need a new full scan of the music archive, or I'm I missing something here?

[simoncn]

You can install an online update (such as the latest update 195) in an existing container without losing any configuration settings or needing to do a full scan of your library.

If the update is an automatic update (such as the latest update 195), you can install it by restarting MinimServer using MinimWatch (select the Restart action). You should also be able to install the update by stopping and starting the Docker container for MinimServer. You should not create a new Docker container.

If you are updating to a new version (such as 2.0.18), the simplest way to update to the new version is to create a new container for the new version. This causes you to lose your license activation and your current configuration and requires a full scan of your library. You can avoid these issues by updating MinimServer within the existing Docker container. For example, to update from MinimServer 2.0.16 to MinimServer 2.0.18 in a Docker container running on an QNAP Intel NAS, do the following:

1) From the Downloads page, download the MinimServer Linux package for the new version to a computer. For an Intel NAS, this package is minimserver-2.0.18-linux-intel.tar.gz.

2) Copy this file to the MinimServer/opt shared folder on the NAS

3) In the MinimServer Docker container, run this command:
/opt/minimserver/bin/update /MinimServer/opt/minimserver-2.0.18-linux-intel.tar.gz

4) This should produce the following messages:
/opt/minimserver/minimserver-2.0.16/bin/stopall: line 23: ps: command not found
No MinimServer instances are running
MinimServer update completed successfully

5) From Container Station, stop and restart the Docker container

6) The Docker container should now be running the updated version of MinimServer with no loss of configuration settings or the existing license activation and no need for a full rescan.

[kennurnes]

(01-08-2021 22:15)simoncn Wrote:  If you are updating to a new version (such as 2.0.18), the simplest way to update to the new version is to create a new container for the new version. This causes you to lose your license activation and your current configuration and requires a full scan of your library. You can avoid these issues by updating MinimServer within the existing Docker container. For example, to update from MinimServer 2.0.16 to MinimServer 2.0.18 in a Docker container running on an QNAP Intel NAS, do the following:

Thanks for the response and I might be unclear with what I meant with that I'm running a Docker server which means in my case a dedicated Ubuntu Docker service and not using any NAS docker implementation (actually went away from this since the containers that I've deployed prevented to disks to spin down.).

Suggestion would be to make use of /config volume (-v /opt/minimserver/config:/config) for MinimServer when deployed in Docker environment which isn't been used now. Noticed that the config directory setup is empty; if used that would make the automatic deployment far easier (configuration would be kept) and together being able to pull the 'Latest' which throws an error when used and one have to specify which version to deploy. So on my Wish List I have these two tweaks which would make the docker deployment far easier.