The installation of Docker varies greatly between operating systems, but for most systems, there are detailed instructions at https://docs.docker.com/engine/installation/. Two levels of Docker are generally available: the Community Edition (CE) and the Enterprise Edition (EE). While slightly different, for almost everything that we will work on in this book, the Community Edition is perfectly functional and will suffice in every way. Once you reach levels of scale where you need much more advanced features, such as security scans, LDAP, and technical support, the Enterprise Edition might make sense. As would be expected, the Enterprise Edition is not free, and you can take a look at https://www.docker.com/pricing to see how these editions differ.

For our examples and any OS-specific commands in this book, from here on, we will be using Ubuntu's Long...

Often in general work with containers, you will likely have to figure out what is going on with a container that is running, but docker ps is not good enough to provide you with all the information you need to figure things out. For these cases, the first command to use is docker logs. This command displays any output that the container has emitted, including both stdout and stderr streams. For the following logs, I started the same NGINX container from before and accessed its hosted page on localhost:

$ docker run -d \
             -p 8080:80 \
             nginx
06ebb46f64817329d360bb897bda824f932b9bcf380ed871709c2033af069118

$ # Access the page http://localhost:8080 with your browser

$ docker logs 06ebb46f
172.17.0.1 - - [02/Aug/2017:01:39:51 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox...

Now that we know a little bit about how to get around containers, this is a good place to try out creating our own container. To start building a container, the first thing that we need to know is that the default filename that Docker looks for when building images is Dockerfile. While you can use different names for this main configuration file, it is highly discouraged though in some rare cases, you might not be able to avoid it - if, for example, you need a test suite image and the main image build files in the same folder. For now, we will assume you just have a single build configuration, and with that in mind, how about we see what one of these basic Dockerfile looks like. Create a test folder somewhere on your filesystem and put this into a file named Dockerfile:

FROM ubuntu:latest

RUN apt-get update -q && \
    apt-get install -qy iputils...

This is probably where we start diverging from other Docker materials out there that practically assume that with just this basic knowledge, the rest of the work is a cakewalk when it is really nothing like that. It is not rocket science, but these simple examples really do not do enough to get us where we need to be, so we will use a practical example based a bit on our previous work with NGINX and create a container that uses this web server image to provide and serve up content that we will bake into the image.

To begin creating our web server, we need...

Our last example was decently comprehensive but it left out some important Docker commands that we should also know, so we will use another example, albeit reworking the web server solution in a slightly less optimal way, to both show them used and to explain what they do. In the process, we will go a bit deeper and see whether we can make as many parts of the service on our own.

We will start this example with creating a clean directory and creating the same test file we used earlier:

$ mkdir ~/python_webserver
$ cd ~/python_webserver

$ echo "Just a test file" > test.txt

Now we will create our bit-more-complex Python-based web server container by putting the following content in the Dockerfile:

FROM python:3

# Add some labels for cache busting and annotating
LABEL version="1.0"
LABEL org.sgnn7.name="python-webserver"

...