snippetdockerMinor
How to run Dockerized graphical applications on a headless server with packages required for display remotely on clients as part of a separate image?
Viewed 0 times
imagewithclientspartremotelyapplicationsdisplayseparateheadlessdockerized
Problem
In this first section I detail some of the terms I have used:
Dockerized graphical applications: A Docker container run from a Docker image which runs an application which (traditionally) uses x11 (or similar) to display the application on the host machine. More details in second section.
packages required for display remotely on clients: For example, a VNC server which allows a user of a local client (e.g. a laptop with desktop Ubuntu 18.04 installed) to navigate through the browser to an particular host-name and port.
In this second section I give an example of the usual way to run a Dockerized application, using gedit as an example:
Example Dockerfile:
Example Docker build command:
Example Docker run command:
Once-off (can potentially be a harmful command, use with caution):
Subsequently:
Please note: There are some security concerns running
Sub-question / curiosity: The above installs x11, etc into the image. Is there any way to have a separate image with all of those dependencies and have multiple containers share folders in order to satisfy the x11 dependencies?
In this third section I detail an example in which my question is relevant:
I want to keep the Dockerized app as explained in section 2, which runs well locally on a client's laptop but have it as part of a cluster of docker containers (using docker-compose for example) so that the image built from the dockerfile in section 2 is unmodified.
I want to include an additional container which has all the VNC and x11 packages required so that the client can run the application remotely.
Which mechanisms allow the above to take place?
Dockerized graphical applications: A Docker container run from a Docker image which runs an application which (traditionally) uses x11 (or similar) to display the application on the host machine. More details in second section.
packages required for display remotely on clients: For example, a VNC server which allows a user of a local client (e.g. a laptop with desktop Ubuntu 18.04 installed) to navigate through the browser to an particular host-name and port.
In this second section I give an example of the usual way to run a Dockerized application, using gedit as an example:
Example Dockerfile:
FROM ubuntu:18.04
RUN apt-get update && apt-get install -y gedit
CMD geditExample Docker build command:
docker build -t gedit:latest .Example Docker run command:
Once-off (can potentially be a harmful command, use with caution):
xhost +local:dockerSubsequently:
docker run --rm --name=gedit -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix gedit:latestPlease note: There are some security concerns running
xhost +local:docker so to reverse this run xhost -local:dockerSub-question / curiosity: The above installs x11, etc into the image. Is there any way to have a separate image with all of those dependencies and have multiple containers share folders in order to satisfy the x11 dependencies?
In this third section I detail an example in which my question is relevant:
I want to keep the Dockerized app as explained in section 2, which runs well locally on a client's laptop but have it as part of a cluster of docker containers (using docker-compose for example) so that the image built from the dockerfile in section 2 is unmodified.
I want to include an additional container which has all the VNC and x11 packages required so that the client can run the application remotely.
Which mechanisms allow the above to take place?
Solution
You can't run a program running on x11 without a x11 buffer somewhere, be it vnc, xvfb or whatever. You will always need x11 libraries on the system running the program or it couldn't work at all. That's akin to trying to run a C program without libc on the system.
Using system libraries from a different container with a volume is a bad idea, as it create a hard dependency on both containers using the same libraries, and is likely to crash somewhere when both systems try to acquire a lock on the library to load it.
I assume with a lot of tweaks it should be doable, but the added complexity is a real footgun and create more dependencies than should exist.
Using system libraries from a different container with a volume is a bad idea, as it create a hard dependency on both containers using the same libraries, and is likely to crash somewhere when both systems try to acquire a lock on the library to load it.
I assume with a lot of tweaks it should be doable, but the added complexity is a real footgun and create more dependencies than should exist.
Context
StackExchange DevOps Q#5330, answer score: 2
Revisions (0)
No revisions yet.