Are there any plans for an official PlexMediaServer (PMS) Container for native Windows Docker?
It would very useful to reduce the overhead, since binding mounts in Linux Containers experimental support just arrived in Windows Docker and has limitations and the only other way is via windows sharing. Additionally, the overhead of the MobyLinuxVM is avoided.
docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers
In the link you provided, it explicitly states that Lock is not supported on the mounts. Running a SQLite database on a filesystem that does not support locking is known to result in corrupt databases. This is also evident by the fact that the list of containers known to not work are almost entirely databases and application that rely heavily on databases. Others in the past have attempted to run Plex within docker on Windows and ended up with corrupt databases.
So windows docker support just isn’t ready for this so until that time it’s not worth evaluating.
@gbooker02 said:
In the link you provided, it explicitly states thatLockis not supported on the mounts. Running a SQLite database on a filesystem that does not support locking is known to result in corrupt databases. This is also evident by the fact that the list of containers known to not work are almost entirely databases and application that rely heavily on databases. Others in the past have attempted to run Plex within docker on Windows and ended up with corrupt databases.So windows docker support just isn’t ready for this so until that time it’s not worth evaluating.
I think you misunderstood, native windows docker will run the native Windows PMS, not the Linux version. There is already success by @The_Dogg. Native Windows docker does not have those limitations.
https://forums.plex.tv/discussion/238247/windows-server-2016-docker-container#latest.
Native Windows Docker images are supported in Windows server 2016 and Windows 10 anniversary update and beyond.
You find more information at:
hub.docker.com/r/microsoft/nanoserver/
blog.docker.com/2016/09/build-your-first-docker-windows-server-container/
To augment what Gbooker has said.
If there is a “Windows Docker” and a “Everybody else’s Docker” , the whole purpose of Docker is negated. It is an encapsulation which can be taken to any host running the Docker engine.
The Linux app, which is what PMS is in Docker, must have Linux file locking translated to Windows file locking translated by the Windows Docker engine. Until such time as it does, there is no point.
Respectfully, and in hope of exuding a few smiles, Having two versions of “Official Plex Docker image” stands about as much promise as getting pigs to fly 
@ChuckPA said:
To augment what Gbooker has said.If there is a “Windows Docker” and a “Everybody else’s Docker” , the whole purpose of Docker is negated. It is an encapsulation which can be taken to any host running the Docker engine.
The Linux app, which is what PMS is in Docker, must have Linux file locking translated to Windows file locking translated by the Windows Docker engine. Until such time as it does, there is no point.
Respectfully, and in hope of exuding a few smiles, Having two versions of “Official Plex Docker image” stands about as much promise as getting pigs to fly
Please, check my post above.
I did check them before replying.
If we are missing a critical point, please help us understand.
What I take away from the points made is simply: The Docker images and resultant containers are Windows app based
@ChuckPA said:
I did check them before replying.If we are missing a critical point, please help us understand.
What I take away from the points made is simply: The Docker images and resultant containers are Windows app based
Indeed the native Windows Docker is a totally different beast, but based on them, the native windows PMS can run with no issues related to file handling since it has access to the native ntfs volume.
I don’t see any technical documentation describing the process of how mounts are handled. It all depends on how they did the isolation within the kernel which dictates what mount abilities are available to docker. Only certain kinds of mounts are capable of handling file locking correctly, and the others tend to just pretend to do it correctly and silently corrupt your data. Without it being explicitly called out as supported, I’d not trust it with anything that runs a database.
On the “native X docker” vs. “docker” where the former is running apps native to that platform but in isolation and the latter is running linux docker containers, I’d be skeptical of the former taking off. FreeBSD tried it a while back and it didn’t. Though FreeBSD’s native docker had the disadvantage of having to compete with a proven and well used technology called jails, so maybe that’d help out in Windows case since it lacked such a technology.
Unfortunately, the native type containers are in a bit of a catch-22. Most won’t be willing to put the resources in to develop a container unless it is proven to be a viable technology but it won’t be a viable technology unless it has a large catalog of available containers. Then with Window’s ability to already run linux docker containers, the rational for putting in these resources is further reduced (“we already have a container; use that”). Time will tell, but for now I’m skeptical.
@gbooker02 said:
I don’t see any technical documentation describing the process of how mounts are handled. It all depends on how they did the isolation within the kernel which dictates what mount abilities are available to docker. Only certain kinds of mounts are capable of handling file locking correctly, and the others tend to just pretend to do it correctly and silently corrupt your data. Without it being explicitly called out as supported, I’d not trust it with anything that runs a database.On the “native X docker” vs. “docker” where the former is running apps native to that platform but in isolation and the latter is running linux docker containers, I’d be skeptical of the former taking off. FreeBSD tried it a while back and it didn’t. Though FreeBSD’s native docker had the disadvantage of having to compete with a proven and well used technology called jails, so maybe that’d help out in Windows case since it lacked such a technology.
Unfortunately, the native type containers are in a bit of a catch-22. Most won’t be willing to put the resources in to develop a container unless it is proven to be a viable technology but it won’t be a viable technology unless it has a large catalog of available containers. Then with Window’s ability to already run linux docker containers, the rational for putting in these resources is further reduced (“we already have a container; use that”). Time will tell, but for now I’m skeptical.
Microsoft advertises the native Windows docker as production ready , even there are examples how to run the Microsoft SQL server. github.com/docker/labs/tree/master/windows/sql-server
Nevertheless, I cannot find documentation for possible limitations. At least none is reported at docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-storage
Running, a Linux Docker image inside a VM with tons of layers in order to emulate the POSIX filesystem behavior (when it is complete) or employing windows shares that cannot be used for all workloads besides the overhead, seems counterproductive if there is already a native Windows application that can be containerized with native Windows Docker.
If there is a “Windows Docker” and a “Everybody else’s Docker”
At the moment there is a “Windows Application” and a “Linux Application”, docker is just another way of packaging the application. Do we take this to confirm that one of those two versions is going to be discontinued?
the whole purpose of Docker is negated
The purpose of docker is resource and dependency isolation though encapsulation. Run anywhere means that you don’t need to install dependencies before running the container, not that you can run a Linux container on Windows or FreeBSD.
True, it is a different form of packaging.
Sadly, Docker on Windows lacks certain system calls which PMS requires. This is precisely why there is Windows stuff and Linux/Mac (Unix) stuff.
That “encapsulation” layer which people count on was insufficient or faulty.
The database operations are critical and previous tests with PMS in Docker on Windows have failed with corrupt databases.
Root cause was, IIRC, insufficient locking services in the Windows implementation.
Until such time are these fundamental system calls are presented in the application environment, there can be no PMS.
As this thread should have been autoclosed after 90 days but did not, I will close now.
Should this topic need further discussion, please feel free to open a new one and reference appropriately
