Chapter 3. Labels
Chapter 3. Labels Labels make it possible to embed commands in to container images instead of adding them as options to the command line. These are usually docker commands with multiple options that are required to run a particular container, and they often include running the container as privileged. The options are handled on a container-by-container basis and can make the command very long and hard to remember. Labels are another way to provide this information to docker. Labels build on the metadata that is already available in Docker. This metadata is stored in a .json file that defines the container. Docker has a feature that lets you put name-value pairs into containers and labels build on the feature that permits name-value pairs to be inserted into containers. 3.1. Labels Example Labels simplify running long docker commands on the command-line. The example below will help you understand labels. Here, we create "run labels" that have a semantic meaning. Suppose that you want to run the Chrome browser with GPU acceleration and pulse audio. To do this, your container needs access to the GPU. That would be easy enough, but we must consider "composition". X11 and Window Manager work together: that is composition. The most efficient way for these two programs to work together is to create one big frame buffer to which all compositing programs write. This is handled with a very long command, for example: Let's break this down: -v /dev/dri:/dev/dri video card component -v /dev/snd:/dev/snd sound card component -v /dev/shm:/dev/shm shared memory shm shared memory -\u00adipc inter-process communication container:foo_bar means that this label refers to another running container called foo_bar . This links the running container foo_bar to the running container fedora_chrome . This argument shares the interprocess communication namespaces of the two containers and ensures that the two containers refer to the same objects and that each of the two containers uses the same names to refer to those objects. This is important because they will be communicating over /dev/shm . Shared memory is one way of providing inter-process communication. -e 'DISPLAY=:0' which X11 display the output should go to -u username this specifies the username rhel_chrome the name of the container google-chrome the command that the container will run
sudo docker run -v /dev/dri:/dev/dri -v /dev/snd:/dev/snd -v /dev/shm:/shm -\u00adipc=container:foo_bar -\u00adprivileged -e 'DISPLAY=:0' -u username rhel_chrome google-chrome