Docker Part 2: Building Images

The previous post in this series on Docker looked at starting up containers built from predefined images provided by Docker Hub. In this, the second in the series, I’ll look at creating customized images tailored to my specific requirements. I’ll also look at how my custom image can be pushed to Docker Hub for others to use.

To recap, this series covers:

  1. Running Containers: Installing Docker and starting containers;
  2. Building Images (this post);
  3. Disposable Containers: Using containers to run a short-lived job rather than a long-lived service;
  4. Composing an Environment Stack: Creating an environment composed of multiple linked containers.

Containers and Images

A Docker Container is the equivalent of a Virtual Machine (VM). It has a file system and a network connection. Services and jobs can be run from a container. Containers can be started, stopped, inspected and networked to other containers.

A Docker Image is a snapshot of a container. It defines the state of a container at a given time – usually the initial state. From this snapshot or image, a container can be started. Indeed, one image could be used to start up multiple containers.

The previous post in this series focused on running containers. This one focuses on defining images to create the containers.

There are two ways to create a new Docker image. The first is to take a snapshot of a running container using the docker commit command. The second is to create a Dockerfile which contains a list of instructions required to create the image. This is usually preferable to manually configuring a container and then taking a snapshot as it is repeatable and the Dockerfile is human readable. This post will cover only creation from a Dockerfile and not the docker commit command.

Database Image

In the previous post, we created a MySQL database container by starting the official MySQL 5.6 image and then performing a few manual steps to initialize it for our application. If we create a custom image though, we can start the container already initialized and ready to go. When the database starts up for the first time, we want the application’s schema already created and a user called ‘spanners’ ready for the application to connect as.

The Dockerfile looks like this:

The first line tells Docker that our image should be based on the official MySQL 5.6 image. Everything that follows will be built on top of that image.

The next line copies the contents of the local docker-entrypoint-initdb.d/  directory into the containers /docker-entrypoint-initdb.d/  directory. When the MySQL container starts it will look for this directory and run any scripts inside it. We can use this to initialize the schema for our application. Our schema creation script looks like this:

Finally, three environment variables are created in the container using the ENV  keyword. These are used to have the MySQL container create a database schema, username and password. Again, the official MySQL image takes care of this for us. It is also possible to set the root password in this way but I’ve chosen not to.

Webserver Image

In the previous post, we created a webserver image by starting the official Tomcat 7 image and then copying in some config files. Again, we can create a custom image so that the container starts up with everything it needs.

The first line here tells Docker that this image is based on the official Tomcat 7 (with JRE 8) image. The following three ADD  commands add a context.xml  file, tomcat-users.xml  and the MySQL driver jar into the container’s Tomcat directory.

Finally, we want to RUN  the wget  command to download the application war and place it in Tomcat’s webapps directory. This means that when the container starts up Tomcat, the Spanners-MVC application will already be deployed.

Building and running the images

Dockerfiles must be built using the docker build command before the images can be run. The following commands build the database and webserver images:

The -t  switch tags the image with a name (spanners-database / spanners-webserver) and the dot at the end tells docker to build the Dockerfile in the current directory.

The two images are now ready to run:

The switches used are exactly the same as the ones we used to start the official MySQL / Tomcat images as described in part 1 of this series.

Publishing images to Docker Hub

The two images just built exist only on the machine that built them. The can be shared with other Docker users by publishing them to Docker Hub or some other Docker repo. One way to do this is to use the docker push command as described in the Docker Tutorial.

It’s also possible to automatically build and publish images whenever its definition is updated. This can be done by creating an Automated Build on Docker Hub. In this way, a Docker Hub (image) repository can be linked to a GitHub or Bitbucket (source code) repository. Whenever the source Dockerfile is updated in GitHub / Bitbucket, Docker Hub will build the updated image.

The source files for the Spanners containers are available on my GitHub repo. The associated automated builds are on my Docker Hub repo.

Running the published container images

The container images described in this tutorial are available from my Docker Hub account (hotblac) and have been tagged with a version number (3.2). They can be run directly from the Docker Hub automated build by referring to them by their full name:

This starts to show the power of Docker. From any machine running Docker, it is possible to run the Spanners-MVC web application using just these two commands. It is not necessary to manually install a database or webserver on the host machine. It’s also not necessary to download and build the application source code or even the Docker image definitions. The whole application and its environment stack is available – already built – from Docker Hub. This means that the application can be started quickly and consistently on any developer workstation, on any physical server or on cloud based infrastructure.

In the next article in the series, we’ll look at using ‘disposable’ Docker containers to run a short lived jobs, specifically building and deploying the application from source code.

 

4 Comments

  • Pingback: Docker Part 1: Running Containers « Don't Panic!

  • Pingback: Docker Part 3: Disposable Containers « Don't Panic!

  • Terri
    October 17, 2016 - 11:36 pm | Permalink

    Hi, I’m just getting started with docker and this is a very helpful tutorial. I’m puzzled by the use of $CATALINA_HOME in the tomcat Dockerfile. Would you mind explaining that?

    • October 18, 2016 - 7:54 pm | Permalink

      Hi Terri! $CATALINA_HOME is a Docker environment variable set by the Tomcat 7 Docker image which I’ve extended from. It evaluates to /usr/local/tomcat in the container. Docker allows you to refer to environment variables using this syntax and I’ve used it to refer to directories relative to the Tomcat home directory. See the Dockerfile reference for more info on environment replacement.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *