Docker

Writing Your First Dockerfile

 To automate building a Docker image, you decribe the building steps in a Docker
manifesto called the Dockerfile.

 This text file uses a set of instructions to describe which base image the new container
is based on,
 what steps need to be taken to install various dependencies and applications
 what files need to be present in the image, how they are made available to a container
 what ports should be exposed, and
 what command should run when a container starts, as well as a few other things
 Create a text file called Dockerfile in your working directory and write the following content
in it:
 FROM ubuntu:14.04
 ENTRYPOINT ["/bin/echo"]

 The FROM instruction tells you which image to base the new image off of.

 Here you choose the ubuntu:14.04 image from the Official Ubuntu repository in Docker Hub.

 The ENTRYPOINT instruction tells you which command to run when a container based on
this image is started. To build the image, issue a docker build command.
 You are now ready to run this container, specifying the image ID of the freshly built image and passing
an argument to it (i.e., Hi Docker !):
 $ docker run e778362ca7cf Hi Docker !
 Hi Docker !

 Amazing—you ran echo in a container! A container was started using the image that you built from this
two-line Dockerfile.

 The container ran and executed the command defined by the ENTRYPOINT instruction. Once this
command was finished, the container job was done and it exited. If you run it again without passing an
argument, nothing is echoed:

 $ docker run e778362ca7cf

 The docker build command has a couple of options to deal with intermediate containers:
 $ docker build -h

 Usage: docker build [OPTIONS] PATH | URL | -

 Build a new image from the source code at PATH

 --force-rm=false Always remove intermediate containers...

 --no-cache=false Do not use cache when building the ...
 -q, --quiet=false Suppress the verbose output generated...
 --rm=true Remove intermediate containers after ...
 -t, --tag="" Repository name (and optionally a tag)...
Docker Compose

 Compose is a tool for defining and running multi-container Docker applications. With
Compose, you use a YAML file to configure your application’s services.

 Then, with a single command, you create and start all the services from your configuration.

 For example, suppose you had an application which required NGNIX and MySQL, you
could create one file which would start both the containers as a service without the need to
start each one separately.
 Using Compose is basically a three-step process:

 Define your app’s environment with a Dockerfile so it can be reproduced

anywhere.

 Define the services that make up your app in docker-compose.yml so they can
be run together in an isolated environment.

 Run docker-compose up and Compose starts and runs your entire app.
Docker Tags

 Essentially you can use metadata to recognize versions of your Docker images
and to save more proven duplicates or variations on a key compilation.
Basically speaking, Dockertags provide helpful information about an image
variation/version.
Use of Docker Tags

 When building an image, we use the following command:

 docker build -t username/image_name:tag_name .

 We tell the Docker daemon to fetch the Docker file present in the current
directory (that’s what the . at the end does). Next, we tell the Docker
daemon to build the image and give it the specified tag. If you run docker
images, you should see an image whose repository is username/image_name
and tag is tag_name.
 Explicitly tagging an image through the tag command.
 docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

 This command just creates an alias (a reference) by the name of the

TARGET_IMAGE that refers to the SOURCE_IMAGE. That’s all it does. It’s like
assigning an existing image another name to refer to it. Notice how the tag is
specified as optional here as well, by the [:TAG] .
Docker Networking

 Docker takes care of the networking aspects so that the containers can
communicate with other containers and also with the Docker Host. If you do
an ifconfig on the Docker Host, you will see the Docker Ethernet adapter.

 This adapter is created when Docker is installed on the Docker Host.

 Listing All Docker Networks

 Inspecting a Docker network
 Creating Your Own New Network
Docker Networking

 When you install docker it creates three networks automatically - Bridge,

Host, and None. Of which, Bridge is the default network a container gets
attached to when it is run.

 The Bridge network assigns IPs in the range of 172.17.x.x to the containers
within it. To access these containers from outside you need to map the ports
of these containers to the ports on the host.
Docker Networking

 Another automatically created network is Host.

 Selecting the Host network will remove any network isolation between the
docker host and the containers.
 For instance, if you run a container on port 5000, it will be accessible on the
same port on the docker host without any explicit port mapping.

 Finally, the None network keeps the container in complete isolation, i.e. they
are not connected to any network or container.
Docker Networking
Bridge Network

 In terms of networking, a bridge network is a Link Layer device which forwards traffic
between network segments.

 A bridge can be a hardware device or a software device running within a host

machine’s kernel.

 In terms of Docker, a bridge network uses a software bridge which allows containers
connected to the same bridge network to communicate, while providing isolation
from containers which are not connected to that bridge network.

 The Docker bridge driver automatically installs rules in the host machine so that
containers on different bridge networks cannot communicate directly with each other.
Host Mode

 In the ‘host’ mode, the containers run in the host network namespace and use
the host IP address.

 To expose the container outside the host, the container uses a port from the
host’s port space.

 This means that you need to manage the ports that containers attach to since
they are all sharing the same port space.
Bridge Mode

 The ‘bridge’ mode offers an improvement over the ‘host’ mode.

 In ‘bridge’ mode, containers get IP addresses from a private

network/networks and are placed in their own network namespaces.

 Because the containers are in their own namespace, they have their own port
space and don’t have to worry about port conflicts
Docker Networking
Docker Networking

 Use docker network inspect to view configuration details of the container

networks on your Docker host. The command below shows the details of the
network called bridge.
Summary

 User-defined bridge networks are best when you need multiple containers to
communicate on the same Docker host.

 Host networks are best when the network stack should not be isolated from
the Docker host, but you want other aspects of the container to be isolated.

 Overlay networks are best when you need containers running on different
Docker hosts to communicate, or when multiple applications work together
using swarm services.
Communicate Between Docker
Containers
 Containers are designed to be isolated. But they can send and receive requests
to other applications, using networking.

 Most container-based applications talk to each other using networking. This

basically means that an application running in one container will create a
network connection to a port on another container.

 Docker creates virtual networks which let your containers talk to each other. In
a network, a container has an IP address, and optionally a hostname.

 You can create different types of networks depending on what you would like to
do.