Running GUI’s with Docker on Mac OS X
This report serves as a transcript of our hands-on presentation and as a fast refresher on the best way best to conduct this sort of software on a Mac in 5 minutes or more. To get a more in-depth look at the best way best to construct and operate Linux GUI programs on Mac I highly suggest the entire scratch rundown, by fellow Docker Captain Alex Ellis.
The very first thing we want is a socata Unix tool that generates two bidirectional flows between two endpoints. Our end objective is to produce a relation between the docker container which runs on the graphical program along with the X window system on the OS X server operating system. So let’s start by developing a bridge between a system socket using a TCP listener on port 6000 (the default interface of the X window system) along with the X window machine in my OS X server, that we will set up and operate in another step onto a Unix socket.
> brew install socat
> socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\”$DISPLAY\”
Now we will handle the X window program. To do so on Mac OS X we’ll need Xquartz that, according to the site, is a job that provides the X Window System about the OS X operating system. We can install it by downloading a dmg on the site. But because we’re great developers we will do it in the command line via homebrew. (yes, I really do see the irony in stating that if advertisements this article as being about GUI’s…)
> brew install xquartz
1 important issue to notice is that when you’ve set up it would be to log out and then log back to OS X to find everything to work correctly. After that’s completed we can begin Xquartz.
> open -a Xquartz
A white terminal window may pop up. Open the preferences in the menu and then go to the previous tab safety. There we will need to be certain that the”allow links from system customers” is checked”on”.
And today we return to business… conducting the true graphical program inside a Docker container!
We want the IP of the system interface of the server OS. We then pass on because the display environment variable from the Docker container runs on the graphic interface.
> ifconfig en0 en0: … inet 192.168.0.235 netmask 0xffffff00 broadcast 192.168.199.255 …> docker run -e DISPLAY=192.168.0.235:0 gns3/xeyes
All that trouble simply to have two rolling eyes in your display? Naturally, there’s far more to research. What about conducting chrome at a container? Besides some additional permissions plus a few warnings… simple as pie!
> docker run -e DISPLAY=192.168.0.235:0 --privileged jess/chrome
The options are infinite! So in only a few commands, we have demonstrated that docker should not be only used for its normal graphical software. It can only be used too for graphic programs. What use cases do you see precious for this setup?
