The Docker Book

The Docker Book
James Turnbull
April 24, 2016
Version: v1.10.3 (462f469)
Website: The Docker Book
Some rights reserved. No part of this publication may be reproduced, stored in a

retrieval system, or transmitted in any form or by any means, electronic,
mechanical or photocopying, recording, or otherwise, for commercial purposes
without the prior permission of the publisher.
This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of
this license, visit here.
Copyright 2015 - James Turnbull <>
Contents
Page
Chapter 1 Working with Docker images and repositories
What is a Docker image? . . . . . . . . . . . . . . . . . . . .
Listing Docker images . . . . . . . . . . . . . . . . . . . . . .
Pulling images . . . . . . . . . . . . . . . . . . . . . . . . . .
Searching for images . . . . . . . . . . . . . . . . . . . . . .
Building our own images . . . . . . . . . . . . . . . . . . . .
Creating a Docker Hub account . . . . . . . . . . . . . .
Using Docker commit to create images . . . . . . . . .
Building images with a Dockerfile . . . . . . . . . . . .
Building the image from our Dockerfile . . . . . . . . .
What happens if an instruction fails? . . . . . . . . . .
Dockerfiles and the build cache . . . . . . . . . . . . . .
Using the build cache for templating . . . . . . . . . .
Viewing our new image . . . . . . . . . . . . . . . . . .
Launching a container from our new image . . . . . .
Dockerfile instructions . . . . . . . . . . . . . . . . . . .
Pushing images to the Docker Hub . . . . . . . . . . . . . .
Automated Builds . . . . . . . . . . . . . . . . . . . . . .
Deleting an image . . . . . . . . . . . . . . . . . . . . . . . .
Running your own Docker registry . . . . . . . . . . . . . .
Running a registry from a container . . . . . . . . . . .
Testing the new registry . . . . . . . . . . . . . . . . . .
Alternative Indexes . . . . . . . . . . . . . . . . . . . . . . .
Quay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
4
8
10
12
12
14
17
21
24
26
27
28
29
34
55
57
61
64
64
65
68
68
68
Contents
List of Figures
69
List of Listings
72
Index
73
Version: v1.10.3 (462f469)
ii
Chapter 1
Working with Docker images and
repositories
In Chapter 2, we learned how to install Docker. In Chapter 3, we learned how to
use a variety of commands to manage Docker containers, including the docker
run command.
Lets see the docker run command again.
Listing 1.1: Revisiting running a basic Docker container
$ sudo docker run -i -t --name another_container_mum ubuntu \

/bin/bash
root@b415b317ac75:/#
This command will launch a new container called another_container_mum from

the ubuntu image and open a Bash shell.
In this chapter, were going to explore Docker images: the building blocks from
which we launch containers. Well learn a lot more about Docker images, what
they are, how to manage them, how to modify them, and how to create, store,
and share your own images. Well also examine the repositories that hold images
1
Chapter 1: Working with Docker images and repositories

and the registries that store repositories.
What is a Docker image?

Lets continue our journey with Docker by learning a bit more about Docker images. A Docker image is made up of filesystems layered over each other. At the
base is a boot filesystem, bootfs, which resembles the typical Linux/Unix boot
filesystem. A Docker user will probably never interact with the boot filesystem.
Indeed, when a container has booted, it is moved into memory, and the boot
filesystem is unmounted to free up the RAM used by the initrd disk image.
So far this looks pretty much like a typical Linux virtualization stack. Indeed,
Docker next layers a root filesystem, rootfs, on top of the boot filesystem. This
rootfs can be one or more operating systems (e.g., a Debian or Ubuntu filesystem).
In a more traditional Linux boot, the root filesystem is mounted read-only and
then switched to read-write after boot and an integrity check is conducted. In the
Docker world, however, the root filesystem stays in read-only mode, and Docker
takes advantage of a union mount to add more read-only filesystems onto the
root filesystem. A union mount is a mount that allows several filesystems to be
mounted at one time but appear to be one filesystem. The union mount overlays
the filesystems on top of one another so that the resulting filesystem may contain
files and subdirectories from any or all of the underlying filesystems.
Docker calls each of these filesystems images. Images can be layered on top of
one another. The image below is called the parent image and you can traverse
each layer until you reach the bottom of the image stack where the final image
is called the base image. Finally, when a container is launched from an image,
Docker mounts a read-write filesystem on top of any layers below. This is where
whatever processes we want our Docker container to run will execute.
This sounds confusing, so perhaps it is best represented by a diagram.
Version: v1.10.3 (462f469)
Figure 1.1: The Docker filesystem layers

When Docker first starts a container, the initial read-write layer is empty. As
changes occur, they are applied to this layer; for example, if you want to change
a file, then that file will be copied from the read-only layer below into the readwrite layer. The read-only version of the file will still exist but is now hidden
underneath the copy.
Version: v1.10.3 (462f469)

This pattern is traditionally called copy on write and is one of the features that
makes Docker so powerful. Each read-only image layer is read-only; this image
never changes. When a container is created, Docker builds from the stack of images and then adds the read-write layer on top. That layer, combined with the
knowledge of the image layers below it and some configuration data, form the container. As we discovered in the last chapter, containers can be changed, they have
state, and they can be started and stopped. This, and the image-layering framework, allows us to quickly build images and run containers with our applications
and services.
Listing Docker images

Lets get started with Docker images by looking at what images are available to
us on our Docker host. We can do this using the docker images command.
Listing 1.2: Listing Docker images
$ sudo docker images

REPOSITORY TAG
IMAGE ID
ubuntu
c4ff7513909d 6 days ago
latest
CREATED
VIRTUAL SIZE
225.4 MB
We see that weve got an image, from a repository called ubuntu. So where does
this image come from? Remember in Chapter 3, when we ran the docker run
command, that part of the process was downloading an image? In our case, its
the ubuntu image.
NOTE
Local images live on our local Docker host in the /var/lib/docker directory. Each image will be inside a directory named for your storage driver;
for example, aufs or devicemapper. Youll also find all your containers in the
/var/lib/docker/containers directory.
Version: v1.10.3 (462f469)

That image was downloaded from a repository. Images live inside repositories,
and repositories live on registries. The default registry is the public registry managed by Docker, Inc., Docker Hub.
TIP
The Docker registry code is open source. You can also run your own registry, as well see later in this chapter. The Docker Hub product is also available
as a commercial behind the firewall product called Docker Trusted Registry, formerly Docker Enterprise Hub.
Figure 1.2: Docker Hub

Version: v1.10.3 (462f469)

Inside Docker Hub (or on a Docker registry you run yourself), images are stored
in repositories. You can think of an image repository as being much like a Git
repository. It contains images, layers, and metadata about those images.
Each repository can contain multiple images (e.g., the ubuntu repository contains
images for Ubuntu 12.04, 12.10, 13.04, 13.10, and 14.04). Lets get another image
from the ubuntu repository now.
Listing 1.3: Pulling the Ubuntu 12.04 image
$ sudo docker pull ubuntu:12.04

Pulling repository ubuntu
463ff6be4238: Download complete
511136ea3c5a: Download complete
3af9d794ad07: Download complete
. . .
Here weve used the docker pull command to pull down the Ubuntu 12.04 image
from the ubuntu repository.
Lets see what our docker images command reveals now.
Listing 1.4: Listing the ubuntu Docker images
$ sudo docker images

REPOSITORY TAG
IMAGE ID
CREATED
VIRTUAL SIZE
ubuntu
latest
5506de2b643b 3 weeks ago
ubuntu
12.04
0b310e6bf058 5 months ago 127.9 MB
ubuntu
precise 0b310e6bf058 5 months ago 127.9 MB
199.3 MB
You can see weve now got the latest Ubuntu image and the 12.04 image. This
show us that the ubuntu image is actually a series of images collected under a
single repository.
Version: v1.10.3 (462f469)
NOTE
We call it the Ubuntu operating system, but really it is not the full operating system. Its a cut-down version with the bare runtime required to run the
distribution.
We identify each image inside that repository by what Docker calls tags. Each
image is being listed by the tags applied to it, so, for example, 12.04, 12.10,
quantal, or precise and so on. Each tag marks together a series of image layers
that represent a specific image (e.g., the 12.04 tag collects together all the layers
of the Ubuntu 12.04 image). This allows us to store more than one image inside
a repository.
We can refer to a specific image inside a repository by suffixing the repository
name with a colon and a tag name, for example:
Listing 1.5: Running a tagged Docker image
$ sudo docker run -t -i --name new_container ubuntu:12.04 /bin/

bash
root@79e36bff89b4:/#
This launches a container from the ubuntu:12.04 image, which is an Ubuntu 12.04
operating system.
We can also see that our new 12.04 images are listed twice with the same ID in our
docker images output. This is because images can have more than one tag. This
makes it easier to help label images and make them easier to find. In this case,
image ID 0b310e6bf058 is actually tagged with 12.04 and precise: the version
number and code name for that Ubuntu release, respectively.
Its always a good idea to build a container from specific tags. That way well know
exactly what the source of our container is. There are differences, for example,
between Ubuntu 12.04 and 14.04, so it would be useful to specifically state that
were using ubuntu:12.04 so we know exactly what were getting.
Version: v1.10.3 (462f469)

There are two types of repositories: user repositories, which contain images contributed by Docker users, and top-level repositories, which are controlled by the
people behind Docker.
A user repository takes the form of a username and a repository name; for example,
jamtur01/puppet.
Username: jamtur01
Repository name: puppet
Alternatively, a top-level repository only has a repository name like ubuntu. The
top-level repositories are managed by Docker Inc and by selected vendors who provide curated base images that you can build upon (e.g., the Fedora team provides
a fedora image). The top-level repositories also represent a commitment from
vendors and Docker Inc that the images contained in them are well constructed,
secure, and up to date.
In Docker 1.8 support was also added for managing the content security of images,
essentially signed images. This is currently an optional feature and you can read
more about it on the Docker blog.
WARNING User-contributed images are built by members of the Docker community. You should use them at your own risk: they are not validated or verified
in any way by Docker Inc.
Pulling images
When we run a container from images with the docker run command, if the image
isnt present locally already then Docker will download it from the Docker Hub.
By default, if you dont specify a specific tag, Docker will download the latest
tag, for example:
Version: v1.10.3 (462f469)
Listing 1.6: Docker run and the default latest tag
$ sudo docker run -t -i --name next_container ubuntu /bin/bash

root@23a42cee91c3:/#
Will download the ubuntu:latest image if it isnt already present on the host.
Alternatively, we can use the docker pull command to pull images down ourselves preemptively. Using docker pull saves us some time launching a container
from a new image. Lets see that now by pulling down the fedora:20 base image.
Listing 1.7: Pulling the fedora image
$ sudo docker pull fedora:20

fedora:latest: The image you are pulling has been verified
782cf93a8f16: Pull complete
7d3f07f8de5f: Pull complete
511136ea3c5a: Already exists
Status: Downloaded newer image for fedora:20
Lets see this new image on our Docker host using the docker images command.
This time, however, lets narrow our review of the images to only the fedora images. To do so, we can specify the image name after the docker images command.
Listing 1.8: Viewing the fedora image
$ sudo docker images fedora

REPOSITORY TAG
IMAGE ID
fedora
7d3f07f8de5f 6 weeks ago 374.1 MB
20
Version: v1.10.3 (462f469)
CREATED
VIRTUAL SIZE

We see that the fedora:20 image has been downloaded. We could also downloaded another tagged image using the docker pull command.
Listing 1.9: Pulling a tagged fedora image
$ sudo docker pull fedora:21
This would have just pulled the fedora:21 image.
Searching for images

We can also search all of the publicly available images on Docker Hub using the
docker search command:
Listing 1.10: Searching for images
$ sudo docker search puppet

NAME
DESCRIPTION STARS OFFICIAL AUTOMATED
wfarr/puppet-module...
jamtur01/puppetmaster
. . .
TIP You can also browse the available images online at Docker Hub.
Here, weve searched the Docker Hub for the term puppet. Itll search images and
return:
Repository names
Version: v1.10.3 (462f469)
10

Image descriptions
Stars - these measure the popularity of an image
Official - an image managed by the upstream developer (e.g., the fedora
image managed by the Fedora team)
Automated - an image built by the Docker Hubs Automated Build process
NOTE Well see more about Automated Builds later in this chapter.
Lets pull down one of these images.
Listing 1.11: Pulling down the jamtur01/puppetmaster image
$ sudo docker pull jamtur01/puppetmaster
This will pull down the jamtur01/puppetmaster image (which, by the way, contains a pre-installed Puppet master server).
We can then use this image to build a new container. Lets do that now using the
docker run command again.
Listing 1.12: Creating a Docker container from the puppetmaster image
$ sudo docker run -i -t jamtur01/puppetmaster /bin/bash

root@4655dee672d3:/# facter
architecture => amd64
augeasversion => 1.2.0
. . .
root@4655dee672d3:/# puppet --version
3.4.3
Version: v1.10.3 (462f469)
11

You can see weve launched a new container from our jamtur01/puppetmaster
image. Weve launched the container interactively and told the container to
run the Bash shell. Once inside the containers shell, weve run Facter (Puppets
inventory application), which was pre-installed on our image. From inside the
container, weve also run the puppet binary to confirm it is installed.
Building our own images

So weve seen that we can pull down pre-prepared images with custom contents.
How do we go about modifying our own images and updating and managing them?
There are two ways to create a Docker image:
Via the docker commit command
Via the docker build command with a Dockerfile
The docker commit method is not currently recommended, as building with a
Dockerfile is far more flexible and powerful, but well demonstrate it to you for
the sake of completeness. After that, well focus on the recommended method
of building Docker images: writing a Dockerfile and using the docker build
command.
NOTE
We dont generally actually create new images; rather, we build new

images from existing base images, like the ubuntu or fedora images weve already
seen. If you want to build an entirely new base image, you can see some information on this here.
Creating a Docker Hub account

A big part of image building is sharing and distributing your images. We do this
by pushing them to the Docker Hub or your own registry. To facilitate this, lets
start by creating an account on the Docker Hub. You can join Docker Hub here.
Version: v1.10.3 (462f469)
12
Figure 1.3: Creating a Docker Hub account.

Create an account and verify your email address from the email youll receive after
signing up.
Now lets test our new account from Docker. To sign into the Docker Hub you can
use the docker login command.
Version: v1.10.3 (462f469)
13
Listing 1.13: Logging into the Docker Hub
$ sudo docker login

Username: jamtur01
Password:
Email: james@lovedthanlost.net
Login Succeeded
This command will log you into the Docker Hub and store your credentials for
future use. You can use the docker logout command to log out from a registry
server.
NOTE
Your credentials will be stored in the $HOME/.dockercfg file. Since

Docker 1.7.0 this is now $HOME/.docker/config.json.
Using Docker commit to create images

The first method of creating images used the docker commit command. You can
think about this method as much like making a commit in a version control system.
We create a container, make changes to that container as you would change code,
and then commit those changes to a new image.
Lets start by creating a container from the ubuntu image weve used in the past.
Listing 1.14: Creating a custom container to modify
$ sudo docker run -i -t ubuntu /bin/bash

root@4aab3ce3cb76:/#
Version: v1.10.3 (462f469)
14

Next, well install Apache into our container.
Listing 1.15: Adding the Apache package
root@4aab3ce3cb76:/# apt-get -yqq update

. . .
root@4aab3ce3cb76:/# apt-get -y install apache2
. . .
Weve launched our container and then installed Apache within it. Were going
to use this container as a web server, so well want to save it in its current state.
That will save us from having to rebuild it with Apache every time we create a
new container. To do this we exit from the container, using the exit command,
and use the docker commit command.
Listing 1.16: Committing the custom container
$ sudo docker commit 4aab3ce3cb76 jamtur01/apache2

8ce0ea7a1528
You can see weve used the docker commit command and specified the ID of the
container weve just changed (to find that ID you could use the docker ps -l
-q command to return the ID of the last created container) as well as a target
repository and image name, here jamtur01/apache2. Of note is that the docker
commit command only commits the differences between the image the container
was created from and the current state of the container. This means updates are
lightweight.
Lets look at our new image.
Version: v1.10.3 (462f469)
15
Listing 1.17: Reviewing our new image
$ sudo docker images jamtur01/apache2

. . .
jamtur01/apache2
latest
8ce0ea7a1528
13 seconds ago
90.63 MB
We can also provide some more data about our changes when committing our
image, including tags. For example:
Listing 1.18: Committing another custom container
$ sudo docker commit -m "A new custom image" -a "James Turnbull"

\
4aab3ce3cb76 jamtur01/apache2:webserver
f99ebb6fed1f559258840505a0f5d5b6173177623946815366f3e3acff01adef
Here, weve specified some more information while committing our new image.
Weve added the -m option which allows us to provide a commit message explaining our new image. Weve also specified the -a option to list the author of the
image. Weve then specified the ID of the container were committing. Finally,
weve specified the username and repository of the image, jamtur01/apache2, and
weve added a tag, webserver, to our image.
We can view this information about our image using the docker inspect command.
Version: v1.10.3 (462f469)
16
Listing 1.19: Inspecting our committed image
$ sudo docker inspect jamtur01/apache2:webserver

[{
"Architecture": "amd64",
"Author": "James Turnbull",
"Comment": "A new custom image",
. . .
}]
TIP You can find a full list of the docker
commit flags here.
If we want to run a container from our new image, we can do so using the docker
run command.
Listing 1.20: Running a container from our committed image
$ sudo docker run -t -i jamtur01/apache2:webserver /bin/bash
Youll note that weve specified our image with the full tag: jamtur01/apache2:
webserver.
Building images with a Dockerfile

We dont recommend the docker commit approach. Instead, we recommend that
you build images using a definition file called a Dockerfile and the docker build
command. The Dockerfile uses a basic DSL (Domain Specific Language) with instructions for building Docker images. We recommend the Dockerfile approach
Version: v1.10.3 (462f469)
17

over docker commit because it provides a more repeatable, transparent, and idempotent mechanism for creating images.
Once we have a Dockerfile we then use the docker build command to build a
new image from the instructions in the Dockerfile.
Our first Dockerfile
Lets now create a directory and an initial Dockerfile. Were going to build a
Docker image that contains a simple web server.
Listing 1.21: Creating a sample repository
$ mkdir static_web
$ cd static_web
$ touch Dockerfile
Weve created a directory called static_web to hold our Dockerfile. This directory is our build environment, which is what Docker calls a context or build
context. Docker will upload the build context, as well as any files and directories
contained in it, to our Docker daemon when the build is run. This provides the
Docker daemon with direct access to any code, files or other data you might want
to include in the image.
Weve also created an empty Dockerfile file to get started. Now lets look at an
example of a Dockerfile to create a Docker image that will act as a Web server.
Version: v1.10.3 (462f469)
18
Listing 1.22: Our first Dockerfile
# Version: 0.0.1
FROM ubuntu:14.04
MAINTAINER James Turnbull "james@example.com"
RUN apt-get update && apt-get install -y nginx
RUN echo 'Hi, I am in your container' \
>/usr/share/nginx/html/index.html
EXPOSE 80
The Dockerfile contains a series of instructions paired with arguments. Each

instruction, for example FROM, should be in upper-case and be followed by an
argument: FROM ubuntu:14.04. Instructions in the Dockerfile are processed from
the top down, so you should order them accordingly.
Each instruction adds a new layer to the image and then commits the image.
Docker executing instructions roughly follow a workflow:
Docker runs a container from the image.

An instruction executes and makes a change to the container.
Docker runs the equivalent of docker commit to commit a new layer.
Docker then runs a new container from this new image.
The next instruction in the file is executed, and the process repeats until all
instructions have been executed.
This means that if your Dockerfile stops for some reason (for example, if an
instruction fails to complete), you will be left with an image you can use. This is
highly useful for debugging: you can run a container from this image interactively
and then debug why your instruction failed using the last image created.
NOTE
The Dockerfile also supports comments. Any line that starts with a #
is considered a comment. You can see an example of this in the first line of our
Version: v1.10.3 (462f469)
19

Dockerfile.
The first instruction in a Dockerfile must be FROM. The FROM instruction specifies
an existing image that the following instructions will operate on; this image is
called the base image.
In our sample Dockerfile weve specified the ubuntu:14.04 image as our base
image. This specification will build an image on top of an Ubuntu 14.04 base
operating system. As with running a container, you should always be specific
about exactly from which base image you are building.
Next, weve specified the MAINTAINER instruction, which tells Docker who the author of the image is and what their email address is. This is useful for specifying
an owner and contact for an image.
Weve followed these instructions with two RUN instructions. The RUN instruction
executes commands on the current image. The commands in our example: updating the installed APT repositories and installing the nginx package and then
creating the /usr/share/nginx/html/index.html file containing some example
text. As weve discovered, each of these instructions will create a new layer and,
if successful, will commit that layer and then execute the next instruction.
By default, the RUN instruction executes inside a shell using the command wrapper
/bin/sh -c. If you are running the instruction on a platform without a shell or
you wish to execute without a shell (for example, to avoid shell string munging),
you can specify the instruction in exec format:
Listing 1.23: A RUN instruction in exec form
RUN [ "apt-get", " install", "-y", "nginx" ]
We use this format to specify an array containing the command to be executed

and then each parameter to pass to the command.
Next, weve specified the EXPOSE instruction, which tells Docker that the applicaVersion: v1.10.3 (462f469)
20

tion in this container will use this specific port on the container. That doesnt mean
you can automatically access whatever service is running on that port (here, port
80) on the container. For security reasons, Docker doesnt open the port automatically, but waits for you to do it when you run the container using the docker run
command. Well see this shortly when we create a new container from this image.
You can specify multiple EXPOSE instructions to mark multiple ports to be exposed.
NOTE Docker also uses the EXPOSE instruction to help link together containers,
which well see in Chapter 5. You can expose ports at run time with the docker
run command with the --expose option.
Building the image from our Dockerfile

All of the instructions will be executed and committed and a new image returned
when we run the docker build command. Lets try that now:
Version: v1.10.3 (462f469)
21
Listing 1.24: Running the Dockerfile
$ cd static_web
$ sudo docker build -t="jamtur01/static_web" .
Sending build context to Docker daemon
2.56 kB

Step 0 : FROM ubuntu:14.04
---> ba5877dc9bec
Step 1 : MAINTAINER James Turnbull "james@example.com"
---> Running in b8ffa06f9274
---> 4c66c9dcee35
Removing intermediate container b8ffa06f9274
Step 2 : RUN apt-get update
---> Running in f331636c84f7
---> 9d938b9e0090
Removing intermediate container f331636c84f7
Step 3 : RUN apt-get install -y nginx
---> Running in 4b989d4730dd
---> 93fb180f3bc9
Removing intermediate container 4b989d4730dd
Step 4 : RUN echo 'Hi, I am in your container'
>/usr/share/
nginx/html/index.html
---> Running in b51bacc46eb9
---> b584f4ac1def
Removing intermediate container b51bacc46eb9
Step 5 : EXPOSE 80
---> Running in 7ff423bd1f4d
---> 22d47c8cb6e5
Successfully built 22d47c8cb6e5
Weve used the docker build command to build our new image. Weve specified
the -t option to mark our resulting image with a repository and a name, here the
jamtur01 repository and the image name static_web. I strongly recommend you
Version: v1.10.3 (462f469)
22

always name your images to make it easier to track and manage them.
You can also tag images during the build process by suffixing the tag after the
image name with a colon, for example:
Listing 1.25: Tagging a build
$ sudo docker build -t="jamtur01/static_web:v1" .
TIP
If you dont specify any tag, Docker will automatically tag your image as
latest.
The trailing . tells Docker to look in the local directory to find the Dockerfile.
You can also specify a Git repository as a source for the Dockerfile as we see
here:
Listing 1.26: Building from a Git repository
$ sudo docker build -t="jamtur01/static_web:v1" \

git@github.com:jamtur01/docker-static_web
Here Docker assumes that there is a Dockerfile located in the root of the Git
repository.
TIP Since Docker 1.5.0 and later you can also specify a path to a file to use as a
build source using the -f flag. For example, docker build -t "jamtur01/static_web" -f /path/to/file. The file specified doesnt need to be called Dockerfile
but must still be within the build context.
Version: v1.10.3 (462f469)
23
But back to our docker build process. You can see that the build context has
been uploaded to the Docker daemon.
Listing 1.27: Uploading the build context to the daemon
2.56 kB
TIP
If a file named .dockerignore exists in the root of the build context then
it is interpreted as a newline-separated list of exclusion patterns. Much like a
.gitignore file it excludes the listed files from being treated as part of the build
context, and therefore prevents them from being uploaded to the Docker daemon.
Globbing can be done using Gos filepath.
Next, you can see that each instruction in the Dockerfile has been executed with
the image ID, 22d47c8cb6e5, being returned as the final output of the build process. Each step and its associated instruction are run individually, and Docker has
committed the result of each operation before outputting that final image ID.
What happens if an instruction fails?

Earlier, we talked about what happens if an instruction fails. Lets look at an
example: lets assume that in Step 4 we got the name of the required package
wrong and instead called it ngin.
Lets run the build again and see what happens when it fails.
Version: v1.10.3 (462f469)
24
Listing 1.28: Managing a failed instruction
$ cd static_web
2.56 kB

Step 1 : FROM ubuntu:14.04
---> 8dbd9e392a96
---> Running in d97e0c1cf6ea
---> 85130977028d
Step 3 : RUN apt-get update
---> Running in 85130977028d
---> 997485f46ec4
Step 4 : RUN apt-get install -y ngin
---> Running in ffca16d58fd8
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package ngin
2014/06/04 18:41:11 The command [/bin/sh -c apt-get install -y
ngin] returned a non-zero code: 100
Lets say I want to debug this failure. I can use the docker run command to create
a container from the last step that succeeded in my Docker build, in this example
using the image ID of 997485f46ec4.
Version: v1.10.3 (462f469)
25
Listing 1.29: Creating a container from the last successful step
$ sudo docker run -t -i 997485f46ec4 /bin/bash

dcge12e59fe8:/#
I can then try to run the apt-get install -y ngin step again with the right package name or conduct some other debugging to determine what went wrong. Once
Ive identified the issue, I can exit the container, update my Dockerfile with the
right package name, and retry my build.
Dockerfiles and the build cache

As a result of each step being committed as an image, Docker is able to be really
clever about building images. It will treat previous layers as a cache. If, in our
debugging example, we did not need to change anything in Steps 1 to 3, then
Docker would use the previously built images as a cache and a starting point.
Essentially, itd start the build process straight from Step 4. This can save you a
lot of time when building images if a previous step has not changed. If, however,
you did change something in Steps 1 to 3, then Docker would restart from the first
changed instruction.
Sometimes, though, you want to make sure you dont use the cache. For example,
if youd cached Step 3 above, apt-get update, then it wouldnt refresh the APT
package cache. You might want it to do this to get a new version of a package. To
skip the cache, we can use the --no-cache flag with the docker build command..
Listing 1.30: Bypassing the Dockerfile build cache
$ sudo docker build --no-cache -t="jamtur01/static_web" .
Version: v1.10.3 (462f469)
26
Using the build cache for templating

As a result of the build cache, you can build your Dockerfiles in the form of
simple templates (e.g., adding a package repository or updating packages near
the top of the file to ensure the cache is hit). I generally have the same template
set of instructions in the top of my Dockerfile, for example for Ubuntu:
Listing 1.31: A template Ubuntu Dockerfile
FROM ubuntu:14.04
ENV REFRESHED_AT 2014-07-01
RUN apt-get -qq update
Lets step through this new Dockerfile. Firstly, Ive used the FROM instruction to
specify a base image of ubuntu:14.04. Next Ive added my MAINTAINER instruction to provide my contact details. Ive then specified a new instruction, ENV.
The ENV instruction sets environment variables in the image. In this case, Ive
specified the ENV instruction to set an environment variable called REFRESHED_AT,
showing when the template was last updated. Lastly, Ive specified the apt-get
-qq update command in a RUN instruction. This refreshes the APT package cache
when its run, ensuring that the latest packages are available to install.
With my template, when I want to refresh the build, I change the date in my ENV
instruction. Docker then resets the cache when it hits that ENV instruction and runs
every subsequent instruction anew without relying on the cache. This means my
RUN apt-get update instruction is rerun and my package cache is refreshed with
the latest content. You can extend this template example for your target platform
or to fit a variety of needs. For example, for a fedora image we might:
Version: v1.10.3 (462f469)
27
Listing 1.32: A template Fedora Dockerfile
FROM fedora:20
ENV REFRESHED_AT 2014-07-01
RUN yum -q makecache
Which performs a similar caching function for Fedora using Yum.
Viewing our new image

Now lets take a look at our new image. We can do this using the docker images
command.
Listing 1.33: Listing our new Docker image
$ sudo docker images jamtur01/static_web

REPOSITORY
TAG
jamtur01/static_web latest
ID
CREATED
SIZE
22d47c8cb6e5
24 seconds ago 12.29 kB
(virtual 326 MB)
If we want to drill down into how our image was created, we can use the docker
history command.
Version: v1.10.3 (462f469)
28
Listing 1.34: Using the docker history command
$ sudo docker history 22d47c8cb6e5

IMAGE
CREATED
CREATED BY
SIZE
22d47c8cb6e5
:{}]
6 minutes ago
/bin/sh -c #(nop) EXPOSE map[80/tcp
0 B
b584f4ac1def
container'
93fb180f3bc9
6 minutes ago
/bin/sh -c echo 'Hi, I am in your
27 B
6 minutes ago
/bin/sh -c apt-get install -y nginx
18.46 MB
9d938b9e0090
6 minutes ago
/bin/sh -c apt-get update
20.02 MB
4c66c9dcee35
6 minutes ago
/bin/sh -c #(nop) MAINTAINER James
Turnbull " 0 B
. . .
We see each of the image layers inside our new jamtur01/static_web image and
the Dockerfile instruction that created them.
Launching a container from our new image

Lets launch a new container using our new image and see if what weve built has
worked.
Version: v1.10.3 (462f469)
29
Listing 1.35: Launching a container from our new image
$ sudo docker run -d -p 80 --name static_web jamtur01/static_web

\
nginx -g "daemon off;"
6751b94bb5c001a650c918e9a7f9683985c3eb2b026c2f1776e61190669494a8
Here Ive launched a new container called static_web using the docker run command and the name of the image weve just created. Weve specified the -d option,
which tells Docker to run detached in the background. This allows us to run longrunning processes like the Nginx daemon. Weve also specified a command for
the container to run: nginx -g "daemon off;". This will launch Nginx in the
foreground to run our web server.
Weve also specified a new flag, -p. The -p flag manages which network ports
Docker publishes at runtime. When you run a container, Docker has two methods
of assigning ports on the Docker host:
Docker can randomly assign a high port from the range 32768 to 61000 on
the Docker host that maps to port 80 on the container.
You can specify a specific port on the Docker host that maps to port 80 on
the container.
The docker run command will open a random port on the Docker host that will
connect to port 80 on the Docker container.
Lets look at what port has been assigned using the docker ps command.
Version: v1.10.3 (462f469)
30
Listing 1.36: Viewing the Docker port mapping
$ sudo docker ps -l
CONTAINER ID
IMAGE
... PORTS
NAMES
6751b94bb5c0
tcp
jamtur01/static_web:latest ... 0.0.0.0:49154->80/
static_web
We see that port 49154 is mapped to the container port of 80. We can get the
same information with the docker port command.
Listing 1.37: The docker port command
$ sudo docker port 6751b94bb5c0 80

0.0.0.0:49154
Weve specified the container ID and the container port for which wed like to see
the mapping, 80, and it has returned the mapped port, 49154.
Or we could use the container name too.
Listing 1.38: The docker port command with container name
$ sudo docker port static_web 80

0.0.0.0:49154
The -p option also allows us to be flexible about how a port is published to the
host. For example, we can specify that Docker bind the port to a specific port:
Version: v1.10.3 (462f469)
31
Listing 1.39: Exposing a specific port with -p
$ sudo docker run -d -p 80:80 --name static_web jamtur01/

static_web \
This will bind port 80 on the container to port 80 on the local host. Its important to be wary of this direct binding: if youre running multiple containers, only
one container can bind a specific port on the local host. This can limit Dockers
flexibility.
To avoid this, we could bind to a different port.
Listing 1.40: Binding to a different port
$ sudo docker run -d -p 8080:80 --name static_web jamtur01/

static_web \
This would bind port 80 on the container to port 8080 on the local host.
We can also bind to a specific interface.
Listing 1.41: Binding to a specific interface
$ sudo docker run -d -p 127.0.0.1:80:80 --name static_web

jamtur01/static_web \
Here weve bound port 80 of the container to port 80 on the 127.0.0.1 interface
on the local host. We can also bind to a random port using the same structure.
Version: v1.10.3 (462f469)
32
Listing 1.42: Binding to a random port on a specific interface
$ sudo docker run -d -p 127.0.0.1::80 --name static_web jamtur01/

static_web \
Here weve removed the specific port to bind to on 127.0.0.1. We would now
use the docker inspect or docker port command to see which random port was
assigned to port 80 on the container.
TIP You can bind UDP ports by adding the suffix /udp to the port binding.
Docker also has a shortcut, -P, that allows us to publish all ports weve exposed
via EXPOSE instructions in our Dockerfile.
Listing 1.43: Exposing a port with docker run
$ sudo docker run -d -P --name static_web jamtur01/static_web \

This would publish port 80 on a random port on our local host. It would also
publish any additional ports we had specified with other EXPOSE instructions in
the Dockerfile that built our image.
TIP You can find more information on port redirection here.

With this port number, we can now view the web server on the running container
Version: v1.10.3 (462f469)
33

using the IP address of our host or the localhost on 127.0.0.1.
NOTE
You can find the IP address of your local host with the ifconfig or ip
addr command.
Listing 1.44: Connecting to the container via curl
$ curl localhost:49154
Hi, I am in your container
Now weve got a simple Docker-based web server.
Dockerfile instructions
Weve already seen some of the available Dockerfile instructions, like RUN and
EXPOSE. But there are also a variety of other instructions we can put in our
Dockerfile. These include CMD, ENTRYPOINT, ADD, COPY, VOLUME, WORKDIR, USER,
ONBUILD, LABEL, STOPSIGNAL, ARG and ENV. You can see a full list of the available
Dockerfile instructions here.
Well also see a lot more Dockerfiles in the next few chapters and see how to
build some cool applications into Docker containers.
CMD
The CMD instruction specifies the command to run when a container is launched. It
is similar to the RUN instruction, but rather than running the command when the
container is being built, it will specify the command to run when the container
is launched, much like specifying a command to run when launching a container
with the docker run command, for example:
Version: v1.10.3 (462f469)
34
Listing 1.45: Specifying a specific command to run
$ sudo docker run -i -t jamtur01/static_web /bin/true
This would be articulated in the Dockerfile as:

Listing 1.46: Using the CMD instruction
CMD ["/bin/true"]
You can also specify parameters to the command, like so:

Listing 1.47: Passing parameters to the CMD instruction
CMD ["/bin/bash", "-l"]
Here were passing the -l flag to the /bin/bash command.
WARNING
Youll note that the command is contained in an array. This

tells Docker to run the command as-is. You can also specify the CMD instruction
without an array, in which case Docker will prepend /bin/sh -c to the command.
This may result in unexpected behavior when the command is executed. As a
result, it is recommended that you always use the array syntax.
Lastly, its important to understand that we can override the CMD instruction using
the docker run command. If we specify a CMD in our Dockerfile and one on the
docker run command line, then the command line will override the Dockerfiles
Version: v1.10.3 (462f469)
35

CMD instruction.
NOTE Its also important to understand the interaction between the CMD instruction and the ENTRYPOINT instruction. Well see some more details of this below.
Lets look at this process a little more closely. Lets say our Dockerfile contains
the CMD:
Listing 1.48: Overriding CMD instructions in the Dockerfile
CMD [ "/bin/bash" ]
We can build a new image (lets call it jamtur01/test) using the docker build
command and then launch a new container from this image.
Listing 1.49: Launching a container with a CMD instruction
$ sudo docker run -t -i jamtur01/test

root@e643e6218589:/#
Notice something different? We didnt specify the command to be executed at the

end of the docker run. Instead, Docker used the command specified by the CMD
instruction.
If, however, I did specify a command, what would happen?
Version: v1.10.3 (462f469)
36
Listing 1.50: Overriding a command locally
$ sudo docker run -i -t jamtur01/test /bin/ps

PID TTY
1 ?
TIME CMD
00:00:00 ps
You can see here that we have specified the /bin/ps command to list running
processes. Instead of launching a shell, the container merely returned the list
of running processes and stopped, overriding the command specified in the CMD
instruction.
TIP You can only specify one CMD instruction in a Dockerfile. If more than one
is specified, then the last CMD instruction will be used. If you need to run multiple
processes or commands as part of starting a container you should use a service
management tool like Supervisor.
ENTRYPOINT
Closely related to the CMD instruction, and often confused with it, is the ENTRYPOINT
instruction. So whats the difference between the two, and why are they both
needed? As weve just discovered, we can override the CMD instruction on the
docker run command line. Sometimes this isnt great when we want a container
to behave in a certain way. The ENTRYPOINT instruction provides a command
that isnt as easily overridden. Instead, any arguments we specify on the docker
run command line will be passed as arguments to the command specified in the
ENTRYPOINT. Lets see an example of an ENTRYPOINT instruction.
Version: v1.10.3 (462f469)
37
Listing 1.51: Specifying an ENTRYPOINT
ENTRYPOINT ["/usr/sbin/nginx"]
Like the CMD instruction, we also specify parameters by adding to the array. For
example:
Listing 1.52: Specifying an ENTRYPOINT parameter
ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"]
NOTE
As with the CMD instruction above, you can see that weve specified the
ENTRYPOINT command in an array to avoid any issues with the command being
prepended with /bin/sh -c.
Now lets rebuild our image with an ENTRYPOINT of ENTRYPOINT ["/usr/sbin/

nginx"].
Listing 1.53: Rebuilding static_web with a new ENTRYPOINT
And then launch a new container from our jamtur01/static_web image.
Version: v1.10.3 (462f469)
38
Listing 1.54: Using docker run with ENTRYPOINT
$ sudo docker run -t -i jamtur01/static_web -g "daemon off;"
Weve rebuilt our image and then launched an interactive container. We specified
the argument -g "daemon off;". This argument will be passed to the command
specified in the ENTRYPOINT instruction, which will thus become /usr/sbin/nginx
-g "daemon off;". This command would then launch the Nginx daemon in the
foreground and leave the container running as a web server.
We can also combine ENTRYPOINT and CMD to do some neat things. For example,
we might want to specify the following in our Dockerfile.
Listing 1.55: Using ENTRYPOINT and CMD together
ENTRYPOINT ["/usr/sbin/nginx"]
CMD ["-h"]
Now when we launch a container, any option we specify will be passed to the
Nginx daemon; for example, we could specify -g "daemon off"; as we did above
to run the daemon in the foreground. If we dont specify anything to pass to the
container, then the -h is passed by the CMD instruction and returns the Nginx help
text: /usr/sbin/nginx -h.
This allows us to build in a default command to execute when our container is run
combined with overridable options and flags on the docker run command line.
TIP
If required at runtime, you can override the ENTRYPOINT instruction using

the docker run command with --entrypoint flag.
Version: v1.10.3 (462f469)
39

WORKDIR
The WORKDIR instruction provides a way to set the working directory for the container and the ENTRYPOINT and/or CMD to be executed when a container is launched
from the image.
We can use it to set the working directory for a series of instructions or for the
final container. For example, to set the working directory for a specific instruction
we might:
Listing 1.56: Using the WORKDIR instruction
WORKDIR /opt/webapp/db
RUN bundle install
WORKDIR /opt/webapp
ENTRYPOINT [ "rackup" ]
Here weve changed into the /opt/webapp/db directory to run bundle install
and then changed into the /opt/webapp directory prior to specifying our
ENTRYPOINT instruction of rackup.
You can override the working directory at runtime with the -w flag, for example:
Listing 1.57: Overriding the working directory
$ sudo docker run -ti -w /var/log ubuntu pwd

/var/log
This will set the containers working directory to /var/log.
Version: v1.10.3 (462f469)
40

ENV
The ENV instruction is used to set environment variables during the image build
process. For example:
Listing 1.58: Setting an environment variable in Dockerfile
ENV RVM_PATH /home/rvm/
This new environment variable will be used for any subsequent RUN instructions,
as if we had specified an environment variable prefix to a command like so:
Listing 1.59: Prefixing a RUN instruction
RUN gem install unicorn
would be executed as:

Listing 1.60: Executing with an ENV prefix
RVM_PATH=/home/rvm/ gem install unicorn
You can specify single environment variables in an ENV instruction or since Docker
1.4 you can specify multiple variables like so:
Listing 1.61: Setting multiple environment variables using ENV
ENV RVM_PATH=/home/rvm RVM_ARCHFLAGS="-arch i386"
Version: v1.10.3 (462f469)
41

We can also use these environment variables in other instructions.
Listing 1.62: Using an environment variable in other Dockerfile instructions
ENV TARGET_DIR /opt/app

WORKDIR $TARGET_DIR
Here weve specified a new environment variable, TARGET_DIR, and then used its
value in a WORKDIR instruction. Our WORKDIR instruction would now be set to /opt
/app.
NOTE
You can also escape environment variables when needed by prefixing

them with a backslash.
These environment variables will also be persisted into any containers created
from your image. So, if we were to run the env command in a container built
with the ENV RVM_PATH /home/rvm/ instruction wed see:
Listing 1.63: Persistent environment variables in Docker containers
root@bf42aadc7f09:~# env
. . .
RVM_PATH=/home/rvm/
. . .
You can also pass environment variables on the docker run command line using
the -e flag. These variables will only apply at runtime, for example:
Version: v1.10.3 (462f469)
42
Listing 1.64: Runtime environment variables
$ sudo docker run -ti -e "WEB_PORT=8080" ubuntu env

HOME=/
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=792b171c5e9f
TERM=xterm
WEB_PORT=8080
Now our container has the WEB_PORT environment variable set to 8080.
USER
The USER instruction specifies a user that the image should be run as; for example:
Listing 1.65: Using the USER instruction
USER nginx
This will cause containers created from the image to be run by the nginx user. We
can specify a username or a UID and group or GID. Or even a combination thereof,
for example:
Version: v1.10.3 (462f469)
43
Listing 1.66: Specifying USER and GROUP variants
USER user
USER user:group
USER uid
USER uid:gid
USER user:gid
USER uid:group
You can also override this at runtime by specifying the -u flag with the docker run
command.
TIP The default user if you dont specify the USER instruction is root.
VOLUME
The VOLUME instruction adds volumes to any container created from the image.
A volume is a specially designated directory within one or more containers that
bypasses the Union File System to provide several useful features for persistent or
shared data:
Volumes can be shared and reused between containers.

A container doesnt have to be running to share its volumes.
Changes to a volume are made directly.
Changes to a volume will not be included when you update an image.
Volumes persist until no containers use them.
This allows us to add data (like source code), a database, or other content into an
image without committing it to the image and allows us to share that data between
containers. This can be used to do testing with containers and an applications
Version: v1.10.3 (462f469)
44

code, manage logs, or handle databases inside a container. Well see examples of
this in Chapters 5 and 6.
You can use the VOLUME instruction like so:
Listing 1.67: Using the VOLUME instruction
VOLUME ["/opt/project"]
This would attempt to create a mount point /opt/project to any container created
from the image.
TIP Also useful and related is the docker
cp command. This allows you to copy

files to and from your containers. You can read about it in the Docker command
line documentation.
Or we can specify multiple volumes by specifying an array:

Listing 1.68: Using multiple VOLUME instructions
VOLUME ["/opt/project", "/data" ]
TIP Well see a lot more about volumes and how to use them in Chapters 5 and
6. If youre curious you can read more about volumes in the Docker volumes
documentation.
Version: v1.10.3 (462f469)
45

ADD
The ADD instruction adds files and directories from our build environment into our
image; for example, when installing an application. The ADD instruction specifies
a source and a destination for the files, like so:
Listing 1.69: Using the ADD instruction
ADD software.lic /opt/application/software.lic
This ADD instruction will copy the file software.lic from the build directory to /
opt/application/software.lic in the image. The source of the file can be a URL,
filename, or directory as long as it is inside the build context or environment. You
cannot ADD files from outside the build directory or context.
When ADDing files Docker uses the ending character of the destination to determine what the source is. If the destination ends in a /, then it considers the source
a directory. If it doesnt end in a /, it considers the source a file.
The source of the file can also be a URL; for example:
Listing 1.70: URL as the source of an ADD instruction
ADD http://wordpress.org/latest.zip /root/wordpress.zip
Lastly, the ADD instruction has some special magic for taking care of local tar
archives. If a tar archive (valid archive types include gzip, bzip2, xz) is specified
as the source file, then Docker will automatically unpack it for you:
Version: v1.10.3 (462f469)
46
Listing 1.71: Archive as the source of an ADD instruction
ADD latest.tar.gz /var/www/wordpress/
This will unpack the latest.tar.gz archive into the /var/www/wordpress/ directory. The archive is unpacked with the same behavior as running tar with the
-x option: the output is the union of whatever exists in the destination plus the
contents of the archive. If a file or directory with the same name already exists in
the destination, it will not be overwritten.
WARNING Currently this will not work with a tar archive specified in a URL.
This is somewhat inconsistent behavior and may change in a future release.
Finally, if the destination doesnt exist, Docker will create the full path for us,
including any directories. New files and directories will be created with a mode
of 0755 and a UID and GID of 0.
NOTE Its also important to note that the build cache can be invalidated by ADD
instructions. If the files or directories added by an ADD instruction change then
this will invalidate the cache for all following instructions in the Dockerfile.
COPY
The COPY instruction is closely related to the ADD instruction. The key difference
is that the COPY instruction is purely focused on copying local files from the build
context and does not have any extraction or decompression capabilities.
Version: v1.10.3 (462f469)
47
Listing 1.72: Using the COPY instruction
COPY conf.d/ /etc/apache2/
This will copy files from the conf.d directory to the /etc/apache2/ directory.
The source of the files must be the path to a file or directory relative to the build
context, the local source directory in which your Dockerfile resides. You cannot
copy anything that is outside of this directory, because the build context is uploaded to the Docker daemon, and the copy takes place there. Anything outside
of the build context is not available. The destination should be an absolute path
inside the container.
Any files and directories created by the copy will have a UID and GID of 0.
If the source is a directory, the entire directory is copied, including filesystem
metadata; if the source is any other kind of file, it is copied individually along
with its metadata. In our example, the destination ends with a trailing slash /, so
it will be considered a directory and copied to the destination directory.
If the destination doesnt exist, it is created along with all missing directories in
its path, much like how the mkdir -p command works.
LABEL
The LABEL instruction adds metadata to a Docker image. The metadata is in the
form of key/value pairs. Lets see an example.
Listing 1.73: Adding LABEL instructions
LABEL version="1.0"
LABEL location="New York" type="Data Center" role="Web Server"
Version: v1.10.3 (462f469)
48

The LABEL instruction is written in the form of label="value". You can specify
one item of metadata per label or multiple items separated with white space. We
recommend combining all your metadata in a single LABEL instruction to save
creating multiple layers with each piece of metadata. You can inspect the labels
on an image using the docker inspect command..
Listing 1.74: Using docker inspect to view labels
$ sudo docker inspect jamtur01/apache2

. . .
"Labels": {
"version": "1.0",
"location"="New York",
"type"="Data Center",
"role"="Web Server"
},
Here we see the metadata we just defined using the LABEL instruction.
NOTE The LABEL instruction was introduced in Docker 1.6.

STOPSIGNAL
The STOPSIGNAL instruction instruction sets the system call signal that will be sent
to the container when you tell it to stop. This signal can be a valid number from
the kernel syscall table, for instance 9, or a signal name in the format SIGNAME, for
instance SIGKILL.
Version: v1.10.3 (462f469)
49
NOTE The STOPSIGNAL instruction was introduced in Docker 1.9.

ARG
The ARG instruction defines variables that can be passed at build-time via the
docker build command. This is done using the --build-arg flag. You can only
specify build-time arguments that have been defined in the DOCKERFILE.
Listing 1.75: Adding ARG instructions
ARG build
ARG webapp_user=user
The second ARG instruction sets a default, if no value is specified for the argument
at build-time then the default is used. Lets use one of these arguments in a docker
build now.
Listing 1.76: Using an ARG instruction
$ docker build --build-arg build=1234 -t jamtur01/webapp .
As the jamtur01/webapp image is built the build variable will be set to 1234 and
the webapp_user variable will inherit the default value of user.
WARNING At this point youre probably thinking - this is a great way to pass
secrets like credentials or keys. Dont do this. Your credentials will be exposed
during the build process and in the build history of the image.
Version: v1.10.3 (462f469)
50

Docker has a set of predefined ARG variables that you can use at build-time without
a corresponding ARG instruction in the Dockerfile.
Listing 1.77: The predefined ARG variables
HTTP_PROXY
http_proxy
HTTPS_PROXY
https_proxy
FTP_PROXY
ftp_proxy
NO_PROXY
no_proxy
To use these predefined variables, pass them using the --build-arg <variable
>=<value> flag to the docker build command.
NOTE The ARG instruction was introduced in Docker 1.9 and you can read more
about it in the Docker documentation.
ONBUILD
The ONBUILD instruction adds triggers to images. A trigger is executed when the
image is used as the basis of another image (e.g., if you have an image that needs
source code added from a specific location that might not yet be available, or if
you need to execute a build script that is specific to the environment in which the
image is built).
The trigger inserts a new instruction in the build process, as if it were specified
right after the FROM instruction. The trigger can be any build instruction. For
example:
Version: v1.10.3 (462f469)
51
Listing 1.78: Adding ONBUILD instructions
ONBUILD ADD . /app/src

ONBUILD RUN cd /app/src && make
This would add an ONBUILD trigger to the image being created, which we see when
we run docker inspect on the image.
Listing 1.79: Showing ONBUILD instructions with docker inspect
$ sudo docker inspect 508efa4e4bf8

...
"OnBuild": [
"ADD . /app/src",
"RUN cd /app/src/ && make"
]
...
For example, well build a new Dockerfile for an Apache2 image that well call
jamtur01/apache2.
Version: v1.10.3 (462f469)
52
Listing 1.80: A new ONBUILD image Dockerfile
FROM ubuntu:14.04
RUN apt-get update && apt-get install -y apache2
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2
ONBUILD ADD . /var/www/
EXPOSE 80
ENTRYPOINT ["/usr/sbin/apache2"]
CMD ["-D", "FOREGROUND"]
Now well build this image.

Listing 1.81: Building the apache2 image
$ sudo docker build -t="jamtur01/apache2" .

...
Step 7 : ONBUILD ADD . /var/www/
---> Running in 0e117f6ea4ba
---> a79983575b86
Successfully built a79983575b86
We now have an image with an ONBUILD instruction that uses the ADD instruction
to add the contents of the directory were building from to the /var/www/ directory
in our image. This could readily be our generic web application template from
which I build web applications.
Lets try this now by building a new image called webapp from the following
Dockerfile:
Version: v1.10.3 (462f469)
53
Listing 1.82: The webapp Dockerfile
FROM jamtur01/apache2
ENV APPLICATION_NAME webapp
ENV ENVIRONMENT development
Lets look at what happens when I build this image.

Listing 1.83: Building our webapp image
$ sudo docker build -t="jamtur01/webapp" .

...
Step 0 : FROM jamtur01/apache2
# Executing 1 build triggers
Step onbuild-0 : ADD . /var/www/
---> 1a018213a59d
---> 1a018213a59d
...
Successfully built 04829a360d86
We see that straight after the FROM instruction, Docker has inserted the ADD instruction, specified by the ONBUILD trigger, and then proceeded to execute the
remaining steps. This would allow me to always add the local source and, as Ive
done here, specify some configuration or build information for each application;
hence, this becomes a useful template image.
The ONBUILD triggers are executed in the order specified in the parent image and
are only inherited once (i.e., by children and not grandchildren). If we built another image from this new image, a grandchild of the jamtur01/apache2 image,
then the triggers would not be executed when that image is built.
Version: v1.10.3 (462f469)
54
NOTE There are several instructions you cant ONBUILD: FROM, MAINTAINER, and
ONBUILD itself. This is done to prevent Inception-like recursion in Dockerfile

builds.
Pushing images to the Docker Hub

Once weve got an image, we can upload it to the Docker Hub. This allows us to
make it available for others to use. For example, we could share it with others in
our organization or make it publicly available.
NOTE The Docker Hub also has the option of private repositories. These are a
paid-for feature that allows you to store an image in a private repository that is
only available to you or anyone with whom you share it. This allows you to have
private images containing proprietary information or code you might not want to
share publicly.
We push images to the Docker Hub using the docker push command.
Lets try a push now.
Listing 1.84: Trying to push a root image
$ sudo docker push static_web

2013/07/01 18:34:47 Impossible to push a "root" repository.
Please rename your repository in <user>/<repo> (ex: jamtur01/
static_web)
Whats gone wrong here?

Version: v1.10.3 (462f469)
Weve tried to push our image to the repository

55

static_web, but Docker knows this is a root repository. Root repositories are
managed only by the Docker, Inc., team and will reject our attempt to write to
them. Lets try again.
Listing 1.85: Pushing a Docker image
$ sudo docker push jamtur01/static_web

The push refers to a repository [jamtur01/static_web] (len: 1)
Processing checksums
Sending image list
Pushing repository jamtur01/static_web to registry-1.docker.io (1
tags)
. . .
This time, our push has worked, and weve written to a user repository, jamtur01
/static_web. We would write to your own user ID, which we created earlier, and
to an appropriately named image (e.g., youruser/yourimage).
We can now see our uploaded image on the Docker Hub.
Version: v1.10.3 (462f469)
56
Figure 1.4: Your image on the Docker Hub.
TIP
You can find documentation and more information on the features of the
Docker Hub here.
Automated Builds
In addition to being able to build and push our images from the command line,
the Docker Hub also allows us to define Automated Builds. We can do so by connecting a GitHub or BitBucket repository containing a Dockerfile to the Docker
Hub. When we push to this repository, an image build will be triggered and a new
image created. This was previously also known as a Trusted Build.
Version: v1.10.3 (462f469)
57
NOTE Automated Builds also work for private GitHub and BitBucket repositories.
The first step in adding an Automated Build to the Docker Hub is to connect your
GitHub account or BitBucket to your Docker Hub account. To do this, navigate to
Docker Hub, sign in, click on your profile link, then click the Add Repository ->
Automated Build button.
Figure 1.5: The Add Repository button.

You will see a page that shows your options for linking to either GitHub or BitBucket. Click the Select button under the GitHub logo to initiate the account
linkage. You will be taken to GitHub and asked to authorize access for Docker
Hub.
On Github you have two options: Public and Private (recommended) and
Limited. Select Public and Private (recommended), and click Allow Access
to complete the authorization. You may be prompted to input your GitHub
password to confirm the access.
From here, you will be prompted to select the organization and repository from
which you want to construct an Automated Build.
Version: v1.10.3 (462f469)
58
Figure 1.6: Selecting your repository.

Select the repository from which you wish to create an Automated Build by clicking the Select button next to the required repository, and then configure the
build.
Version: v1.10.3 (462f469)
59
Figure 1.7: Configuring your Automated Build.

Specify the default branch you wish to use, and confirm the repository name.
Specify a tag you wish to apply to any resulting build, then specify the location of
the Dockerfile. The default is assumed to be the root of the repository, but you
can override this with any path.
Finally, click the Create Repository button to add your Automated Build to the
Docker Hub.
Version: v1.10.3 (462f469)
60
Figure 1.8: Creating your Automated Build.

You will now see your Automated Build submitted. Click on the Build Status
link to see the status of the last build, including log output showing the build
process and any errors. A build status of Done indicates the Automated Build is
up to date. An Error status indicates a problem; you can click through to see the
log output.
NOTE You cant push to an Automated Build using the docker
push command.
You can only update it by pushing updates to your GitHub or BitBucket repository.
Deleting an image
We can also delete images when we dont need them anymore. To do this, well
use the docker rmi command.
Version: v1.10.3 (462f469)
61
Listing 1.86: Deleting a Docker image
$ sudo docker rmi jamtur01/static_web

Untagged: 06c6c1f81534
Deleted: 06c6c1f81534
Deleted: 9f551a68e60f
Deleted: 997485f46ec4
Deleted: a101d806d694
Deleted: 85130977028d
Here weve deleted the jamtur01/static_web image. You can see Dockers layer
filesystem at work here: each of the Deleted: lines represents an image layer
being deleted.
NOTE
This only deletes the image locally. If youve previously pushed that
image to the Docker Hub, itll still exist there.
If you want to delete an images repository on the Docker Hub, youll need to sign
in and delete it there using the Delete repository link.
Version: v1.10.3 (462f469)
62
Figure 1.9: Deleting a repository.

We can also delete more than one image by specifying a list on the command line.
Listing 1.87: Deleting multiple Docker images
$ sudo docker rmi jamtur01/apache2 jamtur01/puppetmaster
or, like the docker rm command cheat we saw in Chapter 3, we can do the same
with the docker rmi command:
Version: v1.10.3 (462f469)
63
Listing 1.88: Deleting all images
$ sudo docker rmi `docker images -a -q`
Running your own Docker registry

Having a public registry of Docker images is highly useful. Sometimes, however,
we are going to want to build and store images that contain information or data
that we dont want to make public. There are two choices in this situation:
Make use of private repositories on the Docker Hub.
Run your own registry behind the firewall.
The team at Docker, Inc., have open-sourced the code they use to run a Docker
registry, thus allowing us to build our own internal registry. The registry does not
currently have a user interface and is only made available as an API service.
TIP If youre running Docker behind a proxy or corporate firewall you can also
use the HTTPS_PROXY, HTTP_PROXY, NO_PROXY options to control how Docker connects.
Running a registry from a container

Installing a registry from a Docker container is simple. Just run the Dockerprovided container like so:
Version: v1.10.3 (462f469)
64
Listing 1.89: Running a container-based registry
$ sudo docker run -p 5000:5000 registry:2
NOTE
Since Docker 1.3.1 you need to add the flag --insecure-registry

localhost:5000 to your Docker daemon startups flags and restart to use a local
registry.
This will launch a container running version 2.0 of the registry application and
bind port 5000 to the local host.
TIP
If youre running an older version of the Docker Registry, prior to 2.0, you
can use the Migrator tool to upgrade to a new registry.
Testing the new registry

So how can we make use of our new registry? Lets see if we can upload one of
our existing images, the jamtur01/static_web image, to our new registry. First,
lets identify the images ID using the docker images command.
Version: v1.10.3 (462f469)
65
Listing 1.90: Listing the jamtur01 static_web Docker image
$ sudo docker images jamtur01/static_web

REPOSITORY
TAG
ID
CREATED
SIZE
jamtur01/static_web
latest
22d47c8cb6e5
24 seconds ago
12.29
kB (virtual 326 MB)
Next we take our image ID, 22d47c8cb6e5, and tag it for our new registry. To
specify the new registry destination, we prefix the image name with the hostname
and port of our new registry. In our case, our new registry has a hostname of
docker.example.com.
Listing 1.91: Tagging our image for our new registry
$ sudo docker tag 22d47c8cb6e5 docker.example.com:5000/jamtur01/

static_web
After tagging our image, we can then push it to the new registry using the docker
push command:
Version: v1.10.3 (462f469)
66
Listing 1.92: Pushing an image to our new registry
$ sudo docker push docker.example.com:5000/jamtur01/static_web

The push refers to a repository [docker.example.com:5000/jamtur01
/static_web] (len: 1)
Processing checksums
Sending image list
Pushing repository docker.example.com:5000/jamtur01/static_web (1
tags)
Pushing 22
d47c8cb6e556420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
Buffering to disk 58375952/? (n/a)
Pushing 58.38 MB/58.38 MB (100%)
. . .
The image is then posted in the local registry and available for us to build new
containers using the docker run command.
Listing 1.93: Building a container from our local registry
$ sudo docker run -t -i docker.example.com:5000/jamtur01/

static_web /bin/bash
This is the simplest deployment of the Docker registry behind your firewall. It
doesnt explain how to configure the registry or manage it. To find out details
like configuring authentication, how to manage the backend storage for your images and how to manage your registry see the full configuration and deployments
details in the Docker Registry deployment documentation.
Version: v1.10.3 (462f469)
67
Alternative Indexes
There are a variety of other services and companies out there starting to provide
custom Docker registry services.
Quay
The Quay service provides a private hosted registry that allows you to upload both
public and private containers. Unlimited public repositories are currently free.
Private repositories are available in a series of scaled plans. The Quay product
has recently been acquired by CoreOS and will be integrated into that product.
Summary
In this chapter, weve seen how to use and interact with Docker images and the
basics of modifying, updating, and uploading images to the Docker Hub. Weve
also learned about using a Dockerfile to construct our own custom images. Finally, weve discovered how to run our own local Docker registry and some hosted
alternatives. This gives us the basis for starting to build services with Docker.
Well use this knowledge in the next chapter to see how we can integrate Docker
into a testing workflow and into a Continuous Integration lifecycle.
Version: v1.10.3 (462f469)
68
List of Figures
1.1 The Docker filesystem layers . . . . .
1.2 Docker Hub . . . . . . . . . . . . . . .
1.3 Creating a Docker Hub account. . . .
1.4 Your image on the Docker Hub. . . .
1.5 The Add Repository button. . . . . .
1.6 Selecting your repository. . . . . . .
1.7 Configuring your Automated Build.
1.8 Creating your Automated Build. . . .
1.9 Deleting a repository. . . . . . . . . .
69
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5
13
57
58
59
60
61
63
Listings
1.1 Revisiting running a basic Docker container . . . . . . . . . .
1.2 Listing Docker images . . . . . . . . . . . . . . . . . . . . . . .
1.3 Pulling the Ubuntu 12.04 image . . . . . . . . . . . . . . . . .
1.4 Listing the ubuntu Docker images . . . . . . . . . . . . . . . .
1.5 Running a tagged Docker image . . . . . . . . . . . . . . . . .
1.6 Docker run and the default latest tag . . . . . . . . . . . . . .
1.7 Pulling the fedora image . . . . . . . . . . . . . . . . . . . . . .
1.8 Viewing the fedora image . . . . . . . . . . . . . . . . . . . . .
1.9 Pulling a tagged fedora image . . . . . . . . . . . . . . . . . .
1.10 Searching for images . . . . . . . . . . . . . . . . . . . . . . .
1.11 Pulling down the jamtur01/puppetmaster image . . . . . .
1.12 Creating a Docker container from the puppetmaster image
1.13 Logging into the Docker Hub . . . . . . . . . . . . . . . . . .
1.14 Creating a custom container to modify . . . . . . . . . . . .
1.15 Adding the Apache package . . . . . . . . . . . . . . . . . . .
1.16 Committing the custom container . . . . . . . . . . . . . . .
1.17 Reviewing our new image . . . . . . . . . . . . . . . . . . . .
1.18 Committing another custom container . . . . . . . . . . . . .
1.19 Inspecting our committed image . . . . . . . . . . . . . . . .
1.20 Running a container from our committed image . . . . . . .
1.21 Creating a sample repository . . . . . . . . . . . . . . . . . .
1.22 Our first Dockerfile . . . . . . . . . . . . . . . . . . . . . . . .
1.23 A RUN instruction in exec form . . . . . . . . . . . . . . . . .
1.24 Running the Dockerfile . . . . . . . . . . . . . . . . . . . . . .
1.25 Tagging a build . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.26 Building from a Git repository . . . . . . . . . . . . . . . . . .
70
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
6
6
7
9
9
9
10
10
11
11
14
14
15
15
16
16
17
17
18
19
20
22
23
23
Listings
1.27 Uploading the build context to the daemon . . . . .
1.28 Managing a failed instruction . . . . . . . . . . . . .
1.29 Creating a container from the last successful step .
1.30 Bypassing the Dockerfile build cache . . . . . . . .
1.31 A template Ubuntu Dockerfile . . . . . . . . . . . . .
1.32 A template Fedora Dockerfile . . . . . . . . . . . . .
1.33 Listing our new Docker image . . . . . . . . . . . . .
1.34 Using the docker history command . . . . . . . . . .
1.35 Launching a container from our new image . . . .
1.36 Viewing the Docker port mapping . . . . . . . . . .
1.37 The docker port command . . . . . . . . . . . . . . .
1.38 The docker port command with container name . .
1.39 Exposing a specific port with -p . . . . . . . . . . . .
1.40 Binding to a different port . . . . . . . . . . . . . . .
1.41 Binding to a specific interface . . . . . . . . . . . . .
1.42 Binding to a random port on a specific interface . .
1.43 Exposing a port with docker run . . . . . . . . . . .
1.44 Connecting to the container via curl . . . . . . . . .
1.45 Specifying a specific command to run . . . . . . . .
1.46 Using the CMD instruction . . . . . . . . . . . . . . .
1.47 Passing parameters to the CMD instruction . . . . .
1.48 Overriding CMD instructions in the Dockerfile . . .
1.49 Launching a container with a CMD instruction . .
1.50 Overriding a command locally . . . . . . . . . . . .
1.51 Specifying an ENTRYPOINT . . . . . . . . . . . . . .
1.52 Specifying an ENTRYPOINT parameter . . . . . . .
1.53 Rebuilding static_web with a new ENTRYPOINT .
1.54 Using docker run with ENTRYPOINT . . . . . . . .
1.55 Using ENTRYPOINT and CMD together . . . . . . .
1.56 Using the WORKDIR instruction . . . . . . . . . . .
1.57 Overriding the working directory . . . . . . . . . . .
1.58 Setting an environment variable in Dockerfile . . .
1.59 Prefixing a RUN instruction . . . . . . . . . . . . . .
1.60 Executing with an ENV prefix . . . . . . . . . . . . .
1.61 Setting multiple environment variables using ENV
Version: v1.10.3 (462f469)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
26
26
27
28
28
29
30
31
31
31
32
32
32
33
33
34
35
35
35
36
36
37
38
38
38
39
39
40
40
41
41
41
41
71
Listings
1.62 Using an environment variable in other Dockerfile instructions
1.63 Persistent environment variables in Docker containers . . . . . .
1.64 Runtime environment variables . . . . . . . . . . . . . . . . . . . .
1.65 Using the USER instruction . . . . . . . . . . . . . . . . . . . . . .
1.66 Specifying USER and GROUP variants . . . . . . . . . . . . . . . .
1.67 Using the VOLUME instruction . . . . . . . . . . . . . . . . . . . .
1.68 Using multiple VOLUME instructions . . . . . . . . . . . . . . . .
1.69 Using the ADD instruction . . . . . . . . . . . . . . . . . . . . . . .
1.70 URL as the source of an ADD instruction . . . . . . . . . . . . . .
1.71 Archive as the source of an ADD instruction . . . . . . . . . . . .
1.72 Using the COPY instruction . . . . . . . . . . . . . . . . . . . . . .
1.73 Adding LABEL instructions . . . . . . . . . . . . . . . . . . . . . . .
1.74 Using docker inspect to view labels . . . . . . . . . . . . . . . . .
1.75 Adding ARG instructions . . . . . . . . . . . . . . . . . . . . . . . .
1.76 Using an ARG instruction . . . . . . . . . . . . . . . . . . . . . . .
1.77 The predefined ARG variables . . . . . . . . . . . . . . . . . . . . .
1.78 Adding ONBUILD instructions . . . . . . . . . . . . . . . . . . . . .
1.79 Showing ONBUILD instructions with docker inspect . . . . . . .
1.80 A new ONBUILD image Dockerfile . . . . . . . . . . . . . . . . . .
1.81 Building the apache2 image . . . . . . . . . . . . . . . . . . . . . .
1.82 The webapp Dockerfile . . . . . . . . . . . . . . . . . . . . . . . . .
1.83 Building our webapp image . . . . . . . . . . . . . . . . . . . . . .
1.84 Trying to push a root image . . . . . . . . . . . . . . . . . . . . . .
1.85 Pushing a Docker image . . . . . . . . . . . . . . . . . . . . . . . .
1.86 Deleting a Docker image . . . . . . . . . . . . . . . . . . . . . . . .
1.87 Deleting multiple Docker images . . . . . . . . . . . . . . . . . . .
1.88 Deleting all images . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.89 Running a container-based registry . . . . . . . . . . . . . . . . . .
1.90 Listing the jamtur01 static_web Docker image . . . . . . . . . . .
1.91 Tagging our image for our new registry . . . . . . . . . . . . . . .
1.92 Pushing an image to our new registry . . . . . . . . . . . . . . . .
1.93 Building a container from our local registry . . . . . . . . . . . .
Version: v1.10.3 (462f469)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
43
43
44
45
45
46
46
47
48
48
49
50
50
51
52
52
53
53
54
54
55
56
62
63
64
65
66
66
67
67
72
Index
.dockerignore, 24
/var/lib/docker, 4
Automated Builds, 57
Build content, 47
Build context, 18, 24
.dockerignore, 24
Building images, 17
Bypassing the Dockerfile cache, 26
Context, 18
Debugging Dockerfiles, 25
Docker
Bind UDP ports, 33
Docker Hub, 5
Dockerfile
ADD, 46
ARG, 50
CMD, 34
COPY, 47
ENTRYPOINT, 37
ENV, 41
EXPOSE, 20, 33
FROM, 20
LABEL, 48
MAINTAINER, 20
ONBUILD, 51
RUN, 20
STOPSIGNAL, 49
USER, 43
VOLUME, 44
WORKDIR, 40
Running your own registry, 64
Security, 8
setting the working directory, 40
specifying a Docker build source, 23
tags, 7
docker
build, 17, 18, 21, 22, 50
no-cache, 26
-f, 23
context, 18
commit, 15
history, 28
images, 4, 9, 28, 65
inspect, 16, 33, 49, 52
login, 13
logout, 14
port, 31, 33
ps, 30
pull, 6, 9
push, 55, 61, 66
73
Index
rm, 63
rmi, 61, 63
run, 1, 8, 11, 21, 25, 30, 34, 35, 67
entrypoint, 39
expose, 21
-P, 33
-e, 42
-u, 44
-w, 40
set environment variables, 42
search, 10
tag, 66
Docker Content Trust, 8
Docker Hub, 5, 6, 10, 55, 57
Logging in, 13
Private repositories, 55
Docker Hub Enterprise, 5
Docker Inc, 8
Docker Trusted Registry, 5
Dockerfile, 17, 52, 57, 68
DSL, 17
exec format, 20
template, 27
Registry
private, 64
Supervisor, 37
tags, 7
Trusted builds, 57
Union mount, 2
exec format, 20
GitHub, 57
HTTP_PROXY, 64
HTTPS_PROXY, 64
NO_PROXY, 64
Port mapping, 20
Private repositories, 55
proxy, 64
Version: v1.10.3 (462f469)
74
Thanks! I hope you enjoyed the book.
Copyright 2015 - James Turnbull <>

The Docker Book

Uploaded by

Document Informationclick to expand document informationIntroducion and sample explain about Dock.

Document Informationclick to expand document information

Copyright:

Available Formats

The Docker Book

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Docker Book

Uploaded by

Copyright:

Available Formats

The Docker Book

Some rights reserved. No part of this publication may be reproduced, stored in a

Version: v1.10.3 (462f469)

$ sudo docker run -i -t --name another_container_mum ubuntu \

This command will launch a new container called another_container_mum from

Chapter 1: Working with Docker images and repositories

What is a Docker image?

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

Figure 1.1: The Docker filesystem layers

Chapter 1: Working with Docker images and repositories

Listing Docker images

$ sudo docker images

c4ff7513909d 6 days ago

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

Figure 1.2: Docker Hub

Chapter 1: Working with Docker images and repositories

$ sudo docker pull ubuntu:12.04

$ sudo docker images

5506de2b643b 3 weeks ago

0b310e6bf058 5 months ago 127.9 MB

precise 0b310e6bf058 5 months ago 127.9 MB

Chapter 1: Working with Docker images and repositories

$ sudo docker run -t -i --name new_container ubuntu:12.04 /bin/

Chapter 1: Working with Docker images and repositories

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

Listing 1.6: Docker run and the default latest tag

$ sudo docker run -t -i --name next_container ubuntu /bin/bash

$ sudo docker pull fedora:20

$ sudo docker images fedora

7d3f07f8de5f 6 weeks ago 374.1 MB

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

$ sudo docker pull fedora:21

This would have just pulled the fedora:21 image.

Searching for images

$ sudo docker search puppet

DESCRIPTION STARS OFFICIAL AUTOMATED

Chapter 1: Working with Docker images and repositories

$ sudo docker pull jamtur01/puppetmaster

$ sudo docker run -i -t jamtur01/puppetmaster /bin/bash

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

Building our own images

We dont generally actually create new images; rather, we build new

Creating a Docker Hub account

Chapter 1: Working with Docker images and repositories

Figure 1.3: Creating a Docker Hub account.

Version: v1.10.3 (462f469)

Chapter 1: Working with Docker images and repositories

Listing 1.13: Logging into the Docker Hub

$ sudo docker login

Your credentials will be stored in the $HOME/.dockercfg file. Since

Using Docker commit to create images

$ sudo docker run -i -t ubuntu /bin/bash

Version: v1.10.3 (462f469)