What is the best way to upgrade PMS running as docker container

Plex Media Server NAS & Devices
1

I’ve been reading here and on other forums what would be the best way to upgrade a docker container. Based on what I’ve read, the docker container should never be upgraded. There are different images available that allow PMS to be updated but the concept itself is a complete no no in docker community. So following on what is considered the official way to upgrade a container, this is how I plan to upgrade mine.

I created my container using externally mounted volumes:

docker run -d                                                \
--name plex                                                  \
--network=host                                               \
--restart=unless-stopped                                     \
-e TZ="America/Chicago"                                      \
-v /mnt/plex/database:/config                                \
-v /mnt/plex/transcode:/transcode                            \
-v /mnt/:/data/tvshows                                       \
-v /mnt/Media/Movies:/data/movies                            \
plexinc/pms-docker

When an upgrade is available, I plan to stop the original container and create a new container with a temporary name.

docker run -d                                                \
--name plex-tmp                                              \
--network=host                                               \
--restart=unless-stopped                                     \
-e TZ="America/Chicago"                                      \
-v /mnt/plex/database:/config                                \
-v /mnt/plex/transcode:/transcode                            \
-v /mnt/:/data/tvshows                                       \
-v /mnt/Media/Movies:/data/movies                            \
plexinc/pms-docker

Once the updated PMS is validated, I can delete my old container and rename the new one.

docker rename plex-tmp plex

This is the expected way to upgrade a docker container. Is there anything that I am missing from PMS perspective? Would this work?

2 
docker stop plex
docker rm plex
docker pull plexinc/pms-docker
docker run -d                                                \
--name plex                                              \
--network=host                                               \
--restart=unless-stopped                                     \
-e TZ="America/Chicago"                                      \
-v /mnt/plex/database:/config                                \
-v /mnt/plex/transcode:/transcode                            \
-v /mnt/:/data/tvshows                                       \
-v /mnt/Media/Movies:/data/movies                            \
plexinc/pms-docker
3

I added the extra step of starting a new container with a temporary name to allow for validation with the new image. If anything were to go wrong, going back to the previous version is as simple as restarting the previous container. Am I overthinking it?

4

Yes :wink: The only relevant data is in /config. You have correctly bind mounted a directory on the host into the container for /config. All other data in the container is not relevant.

5

@utamav - which source are you using for the plex docker image? I’ve been using this which has an auto update on restart - so all I do when there is an update notification is to restart the plex docker and it’s done!

6

I saw that image but as I mentioned in my first post, upgrading the software of a container is frowned upon in the docker community. So I was looking for the “correct” method in the eyes of the docker community.

7

This is exactly why the latest tagged images don’t do this. Some expect this behavior which is the reason for the public and beta tagged images exist which do update the binaries in the image. Similarly, there are images tagged with explicit version numbers so you have a means of rollback by running one of those images.

As stated by others, everything relevant is in /config. There is a slight modification to the image that’s made only to indicate if this is the first time the container is run or a subsequent run. The rationale is that several of the ENVs will set preferences, change UIDs, and so forth and you usually only want that done the first time only. So while not strictly correct to do this, it was a compromise to account for users that may set these ENVs and never clear them and then find the behavior odd when some prefs get changed back every time the container is started or slow startup (one of them can run a recursive chown). You don’t have any of these ENVs in your run command so it shouldn’t affect you.

Per ease in updating, I’d suggest using docker-compose. You can add multiple containers to the compose file and pull/update/restart multiple at once.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.