From Docker in Practice, Second Edition by Ian Miell and Aidan Hobson Sayers
Save 37% off Docker in Practice, Second Edition. Just enter code fccmiell into the promotional discount code box at checkout at manning.com.
This article dives into running containers. If you’re interested in learning some practical techniques that might not be obvious, read on!
You can’t get far without running containers when using Docker, and there’s a lot to take in to use the full power available to you.
Some practical techniques related to running containers on your host may not be immediately obvious. We’ll look at how you can get GUI applications working, start a container on a remote machine, inspect the state of containers and their source images, and shut down containers.
TECHNIQUE n Running GUIs within Docker
You might already be familiar with the “save game” approach to development (It’s discussed in chapter three of the book). That is one way to view applications within your Docker container, and it’s self-contained, requiring only a VNC client to use.
Fortunately there’s a more lightweight and well-integrated way to run GUIs on your desktop, but it requires more setup on your part. It mounts the directory on the host manages communications with the X server to make it accessible to the container.
You want to run GUIs in a container as though they were normal desktop apps.
Here you’re going to create an image with your user credentials and the program and bind mount your X server to it.
The container is linked to the host via the mount of the host’s /tmp/.X11 directory, and this is how the container can perform actions on the host’s desktop.
First make a new directory somewhere convenient, and determine your user and group IDs with the
id command, as shown in the following listing.
Listing 1 — Set up directory and find out your user details
$ mkdir dockergui
$ cd dockergui
$ id ❶
uid=1000(dockerinpractice) \ ❷
gid=1000(dockerinpractice) \ ❸
❶ Gets information about your user that you’ll need for the Dockerfile.
❷ Note your user ID (
uid). In this case, it’s 1000.
❸ Note your group ID (
gid). In this case, it’s 1000.
Now create a file called Dockerfile as follows.
RUN apt-get update
RUN apt-get install -y firefox ❶
RUN groupadd -g GID USERNAME ❷
RUN useradd -d /home/USERNAME -s /bin/bash \
-m USERNAME -u UID -g GID ❸
USER USERNAME ❹
ENV HOME /home/USERNAME ❺
CMD /usr/bin/firefox ❻
❶ Install Firefox as the GUI app. You can change this to whatever application(s) you may want.
❷ Add your host’s group to the image, replacing GID with your group ID and USERNAME with your username.
❸ Add your user account to the image, replacing USERNAME with your username, UID with your user ID, and GID with your group ID.
❹ The image should run as the user you’ve created. Replace USERNAME with your username.
❺ Set the HOME variable correctly. Replace USERNAME with your username.
❻ Run Firefox on startup by default.
Now you can build from that Dockerfile and tag the result as “gui”, as shown in the next listing.
Listing 2. Build the gui image
$ docker build -t gui .
Run it as shown in the following listing.
Listing 3. Run the gui image
docker run -v /tmp/.X11-unix:/tmp/.X11-unix \ ❶
-h $HOSTNAME -v $HOME/.Xauthority:/home/$USER/.Xauthority \ ❷
-e DISPLAY=$DISPLAY gui ❸
❶ Bind mount the X server directory to the container…
❷ …set the DISPLAY variable in the container to be the same as that used in the host, so the program knows which X server to talk to…
❸ …and give the container the appropriate credentials.
You can use this technique to avoid mixing up your desktop work with your development work. With Firefox, for example, you might want to see how your application behaves with no web cache, bookmarks, or search history in a repeatable way for testing purposes. If you see error messages about being unable to open a display when trying to start the image and run Firefox, you can try running selenium tests inside Docker (discussed in chapter 8 of the book).
We understand that some people run almost all their applications inside Docker, including games! Although we don’t go quite that far, it’s useful to know that somebody probably encountered the problems you see.
That’s all for now.
If you want more info about the book, check it out on liveBook here.
About the authors:
Ian Miell is the Lead OpenShift Architect at Barclays. Aidan Hobson Sayers is a developer at Hadean. Previously, they used Docker to transform DevOps at OpenBet.
Originally published at freecontent.manning.com.