Docker config directory, keep in container or out of container

[pcm2a 9]

I have a docker container running and I see that the /config directory is inside the container. Is it best practice to keep the /config folder inside the container or could it be moved outside to the normal storage and then mounted as a path /config? If it was outside the container then it would be easier to spin up new versions, try different beta versions, with no risk to losing my data?

 

What are the differences in these commands if I want to update to the latest beta and don't want to lose my settings?

docker exec emby-server update

docker pull emby/embyserver
docker stop emby-server
emby-server

[Luke 37090]

Betas are handled via Docker tags. Our Docker install instructions go over how to specify the tag:

 

https://emby.media/docker-server.html

[pcm2a 9]

This post was more about how to protect the precious /config folder to not lose any data and a question about the difference in two different update commands so I can be more knowledgable about docker.

[solabc16 379]

Hello @@pcm2a

 

As discussed elsewhere and for the benefit of other readers, there is a native package available for Synology/XPEnology and this is the preferred and supported approach.

 

I recognise that for specific situations there may be good reason to run a Docker instances on  Synology/XPEnology platforms for some users, but we don't actively support it.

 

For those interested in joining the beta programme, please refer to : https://emby.media/community/index.php?/topic/68601-accessing-beta-and-development-releases/

 

Best

- James

[pcm2a 9]

I am interested to see and report back how the performance of the native beta compares to the docker container. For example the docker container beta is drastically faster than the native stable version. For the technically savvy one big benefit with the docker container is the ability to run multiple versions and multiple instances Emby at the same time. I can test things on the latest stable release and different beta versions at the same time.

 

I could list a bunch but here are two use cases:

 

1. Let's say you have two IPTV providers, you could import both guides into Emby and end up with lots of duplicate channels and 10 shows trying to record at the same time. Or you can run two docker containers one with each provider.

 

2. Let's say you have an IPTV provider with 1000 channels. What a drag if you import all of those into Emby, which doesn't support m3u categories. So you probably scaled your m3u down to a smaller set of 100 channels. In another docker container you can import the whole thing and use it for those times you need to access one of those extra channels.

Edited March 10, 2019 by pcm2a

[solabc16 379]

Hello @@pcm2a

 

As I said "I recognise that for specific situations there may be good reason to run a Docker instances on  Synology/XPEnology platforms for some users".

 

However, the goal is of course to provide a (media) consumer friendly / facing solution, with the same reliability and robustness as you would expect from your home media devices.

 

That's certainly not to dismiss any of the above.

 

Scenarios that make sense to integrate and have a strong user demand, can always be considered for development and subsequently incorporated into the Emby solution.

 

Best

- James