We will use the Dockerfile of training/webapp from the Docker Education Team to build a Docker image. The next few steps will show us how to build this web application:

Now that we have made a Docker image, let's push it to a repository to share and deploy across other Docker hosts. The default installation of Docker pushes images to Docker Hub. Docker Hub is a publicly hosted repository of Docker, Inc., where anyone with an account can push and share their Docker images. The following steps will show us how to do this:

Now that we have successfully pushed our Docker image, it will be available in Docker Hub. We can also get more information about the image we pushed in its Docker Hub page, which is similar to that shown in the following image. In this example, our Docker Hub URL is https:// hub.docker.com/r/hubuser/webapp:

Docker Hub is a good place to start hosting our Docker images. However, there are some cases where we want to host our own image repository. For example, when we want to save bandwidth when pulling images to our Docker hosts. Another reason could be that our Docker hosts inside a datacenter may have firewalled off the Internet. In Chapter 2, Optimizing Docker Images, we will discuss in greater detail how to run our own Docker registry to have an in-house repository of Docker images.

Once our Docker images are built and pushed to a repository, such as Docker Hub, we can pull them to our Docker hosts. This workflow is useful when we first build our Docker image in our development workstation Docker host and want to deploy it to our production environment's Docker host in the cloud. This removes the need to rebuild the same image in our other Docker hosts. Pulling images can also be used to grab the existing Docker images from Docker Hub to build over our own Docker images. So, instead of cloning the Git repository as we did earlier and redoing the build in another one of our Docker hosts, we can pull it instead. The next few steps will walk us through pulling the hubuser/webapp Docker image that we just pushed earlier:

In the training/webapp example, its Docker container is run as a web server. To have the application serve web traffic outside its container environment, Docker needs information on which port the application is bound to. Docker refers to this information as exposed ports. This section will walk us through how to expose port information when running our containers.

Going back to the training/webapp Docker image we worked on earlier, the application serves a Python Flask web application that listens to port 5000, as highlighted here in webapp/app.py:

import os
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello():
    provider = str(os.environ.get('PROVIDER', 'world'))
    return 'Hello '+provider+'!'
if __name__ == '__main__':
    # Bind to PORT if defined, otherwise default to 5000.
    port = int(os.environ.get('PORT', 5000))
    app.run(host='0.0.0.0', port=port)

Correspondingly, the Docker image makes the Docker host aware that the application is listening on port 5000 via the EXPOSE instruction in the Dockerfile, which can be described as follows:

FROM ubuntu:14.04
MAINTAINER Docker Education Team <[email protected]>
RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get \
        install -y -q python-all python-pip 
ADD ./webapp/requirements.txt /tmp/requirements.txt
RUN pip install -qr /tmp/requirements.txt
ADD ./webapp /opt/webapp/
WORKDIR /opt/webapp
EXPOSE 5000
CMD ["python", "app.py"]

Now that we have a basic idea of how Docker exposes our container's ports, follow the next few steps to run the hubuser/webapp container:

In addition to the EXPOSE instruction, exposed ports can be overridden during runtime with the --expose=[] flag. For example, use the following command to have the hubuser/webapp application expose ports 4000-4500:

dockerhost$ docker run -d --expose=4000-4500 \
                          --name app hubuser/webapp
dockerhost $ docker ps
CONTAINER ID   IMAGE      ...              PORTS                   NAMES
ca4dc1da26d    hubuser/webapp:latest  ...  4000-4500/tcp,5000/tcp  app
df3e6b788fd8   hubuser/webapp:l...         5000/tcp                ourapp

This ad hoc docker run flag is useful when debugging applications. For example, let's say our web application uses ports 4000-4500. However, we normally don't want these ranges to be available in production. We can then use --expose=[] to enable it temporarily to spin up a debuggable container. Further details on how to use techniques such as this to troubleshoot Docker containers will be discussed in Chapter 7, Troubleshooting Containers.

Exposing only makes the port available inside the container. For the application to be served outside its Docker host, the port needs to be published. The docker run command uses the -P and -p flags to publish a container's exposed ports. This section talks about how to use these two flags to publish ports on the Docker host.

$ ssh dockerhost
dockerhost$ docker run -d -p 127.0.0.1:80:5000 training/webapp
dockerhost$ curl http://localhost
Hello world!
dockerhost$ exit
logout
Connection to dockerhost closed.
$ curl http://dockerhost
curl: (7) Failed connect to dockerhost:80; Connection refused

The published ports described in the previous section also allow containers to talk to each other by connecting to the published Docker host ports. Another way to directly connect containers with each other is establishing container links. Linked containers allow a source container to send information to the destination containers. It enables the communicating containers to discover each other in a secure manner.

In this section, we will work with the --link flag to connect containers securely. The next few steps give us an example of how to work with linked containers:

What happened during the linking process was that the Docker host created a secure tunnel between the two containers. We can confirm this tunnel in the Docker host's iptables, as follows:

dockerhost$ docker inspect -f "{{ .NetworkSettings.IPAddress }}" \
                           source
172.17.0.15
dockerhost$ docker inspect -f "{{ .NetworkSettings.IPAddress }}" \
                           destination
172.17.0.28
dockerhost$ iptables -L DOCKER
Chain DOCKER (1 references)
target     prot opt source         destination         
ACCEPT     tcp  --  172.17.0.28    172.17.0.15       tcp dpt:5000
ACCEPT     tcp  --  172.17.0.15    172.17.0.28       tcp spt:5000

In the preceding iptables, the Docker host allowed the destination container called destination (172.17.0.28) to accept outbound connections to port 5000 of the source container called source (172.17.0.15). The second iptable's entry allows the container called source to receive connections to its port 5000 from the container called destination.

In addition to the secure connections established by the Docker host between containers, the Docker host also exposes information about the source container to the destination container through the following:

These two sources of information will be further explored in the next section as an example use case of working with interactive containers.

By specifying the -i flag, we can specify that a container running in the foreground is attached to the standard input stream. By combining it with the -t flag, a pseudoterminal is also allocated to our container. With this, we can use our Docker container as an interactive process, similar to normal shells. This feature is useful when we want to debug and inspect what is happening inside our Docker containers. Continuing from the previous section, we can debug what happens when containers are linked through the following steps: