Docker Best Practices: Create Production Docker Images

Docker images are fundamentally hold the initialization point of a production critical implementation in Docker eco system. Docker images can effectively reduce a lot of effort you put to build a Developer/Staging/Production environment from the ground up.

Docker is getting more exiting over traditional infrastructure implementations while it leverages the extended capabilities of LXC, cgroups, namespaces and Linux Kernel.

You can refer following guide to create a production ready Docker images in 5 steps.

Prerequisites

Following guide will require basic knowledge about Dockerfiles and Docker images. Additionally, you may have basic knowledge about Docker.

Step 1: Use light weight Base Docker Images

If you plan to use Docker at highly critical production systems, where you cannot afford a downtime of a few seconds, then first thing you have to choose is a light weight base image for your custom docker image.

If you run a CoreOS Kubernetes cluster to manage Docker containers in a production environment, you need to ensure that light weight docker images are presented.

If a pod terminated unexpectedly, there is a good chance that Kubernetes will spawn a new pod in a new node. In that case, new node will need to pull the image from the beginning. If the image was bulky, you will experience a delay in pod creation, which eventually leads to service downtime.

Alpine would be a good choice because it is a minimal Docker image based on Alpine Linux with a complete package index and only around 5 MB in size!

REPOSITORY  TAG  IMAGE ID     CREATED     SIZE
 alpine      3.3  d1a6a7bfda63 3 weeks ago 4.81 MB

Alpine vs Ubuntu

We’ll install mysql-client package in both Alpine and Ubuntu base images and identify the size difference.

Alpine

• Create a new Dockerfile for Alpine.

FROM alpine:3.3
 RUN apk add --no-cache mysql-client
 ENTRYPOINT ["mysql"]

• Build Docker image from the above Dockerfile

# docker build -t alpine-mysql-cli:0.1 .

• Check the size of the image. It’s just around 38 MB

# docker images
 REPOSITORY             TAG  IMAGE ID      CREATED        SIZE
 alpine-mysql-cli  0.1  83ef90a1cc0c      2 minutes ago  37.3 MB

Ubuntu

• Create a new Dockerfile for Ubuntu.

FROM ubuntu:14.04
 RUN apt update 
     && apt install -y mysql-client 
     && rm -rf /var/lib/apt/lists/*
 ENTRYPOINT ["mysql"]

• Build Docker image from the above Dockerfile

docker build -t ubuntu-mysql-cli:0.1 .

Check the size of the image. It’s 232 MB

# docker images
 REPOSITORY        TAG  IMAGE ID          CREATED             SIZE
 ubuntu-mysql-cli  0.1  07925b1a1a2d      About a minute ago  232 MB

Based on the results above, you can clearly see the size difference is significant between these two images. You would be the judge to select your base image according to the above results.

Step 2: Reduce intermediate layers

A Docker image is a series of layers which combines using Union File System as a single image. This layered approach is one of the reasons Docker is so lightweight. When you change a Docker image, such as when you update an application to a new version, a new layer is built and replaces only the layer it updates. The other layers remain unchanged. To distribute the update, you only need to transfer the updated layer. Docker determines which layers need to be updated at runtime.

Keep in mind that each Docker instruction creates a new layer within the image.

Some examples of Dockerfile instructions are:

• FROM Specify the base image
• LABEL Specify image metadata
• RUN Run a command
• ADD Add a file or directory
• ENV Create an environment variable
• CMD Specify the process to run when launching a container from this image

It’s a best practice to reduce the usage of same instructions multiple times, which will eventually reduce the number of intermediate layers. As a result, it will automatically reduce the creation of intermediate containers as well. This approach will create a slightly smaller image than a multi layered image.

You can identify the layers of an existing image by exploring the image history.

docker history <image id>

The Bad way

An example for bad usage of Docker instructions.

FROM ubuntu:14.04

# Update system
RUN apt update -y
RUN apt upgrade -y

# Setup SSH server
RUN apt install -y openssh-server
RUN mkdir /var/run/sshd

# Start SSH server
CMD /usr/sbin/sshd -D

Have a closer look on the below output of above example Dockerfile. You would see four intermediate containers regarding multiple usage of RUN command.

# docker build -t ubuntu-ssh:0.1 .
 Sending build context to Docker daemon 4.608 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
 ---> 736f02dfa6f4
Step 1 : RUN apt update -y
 ---> Using cache
 ---> 8ff33eb64936
Step 2 : RUN apt upgrade -y
 ---> Using cache
 ---> b0718fadb1cf
Step 3 : RUN apt install -y openssh-server
 ---> Using cache
 ---> 3e97f3093be5
Step 4 : RUN mkdir /var/run/sshd
 ---> Using cache
 ---> f55248152d6e
Step 5 : CMD /usr/sbin/sshd -D
 ---> Using cache
 ---> f7a298d09023
Successfully built f7a298d09023

The Best practice

An example of Docker instructions following best practices.

FROM ubuntu:14.04
# Update system and setup SSH Server
RUN apt update –y
 && apt install -y openssh-server \
 && mkdir /var/run/sshd
# Start SSH server
CMD /usr/sbin/sshd -D

Refer the below output regarding the above example Dockerfile. You would see only one intermediate container spawned for the combined usage of RUN commands.

# docker build -t Ubuntu_ssh .
Sending build context to Docker daemon 4.608 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
 ---> caf6f807d6c0
Step 1 : RUN apt-get update -y  && apt-get install -y openssh-server  && mkdir /var/run/sshd
 ---> Using cache
 ---> 6623fcc73d6b
Step 2 : CMD /usr/sbin/sshd -D
 ---> Using cache
 ---> 1ad9952a507b
Successfully built 1ad9952a507b

Step 3: Choose specific versions

Since image creation demands the availability of various online resources such as the base image, packages etc; it’s a good practice to choose specific versions in Docker instructions. It will keep things nice and steady for a production implementation.

Imagine if we use Ubuntu latest as the base image. It will use the currently available latest Ubuntu image for our custom Docker image. Additionally, we will setup all the software components based on the same Ubuntu version.

FROM ubuntu

When Ubuntu update the latest tag with a newer base image in Docker Hub, then you might experience some package dependency issues or incompatibilities in your production Docker image.

If you want to build an image from Ubuntu, it’s recommended to use a specific Ubuntu version rather than using the latest version.

FROM ubuntu:16.04

Always choose specific package versions to install within custom image

Avoid using generic package installation instructions, which is not recommended like following example.

apt install mysql-server

A recommended package installation example is as following.

apt install mysql-server-5.5

Step 4: Do not include sensitive data

Using sensitive data such as Database credentials and API keys would be a challenging task in Docker.

Do not hard code any type of login credentials within a Docker image

To overcome this limitation, we can use environment variables effectively. We’ll consider a production scenario regarding a Drupal custom Docker image.

• Create a Dockerfile for Drupal image as follows. We use Entrypoint to run Apache in foreground while setting up Drupal MySQL DB credentials from the same ENTRYPOINT executable.

FROM debian:jessie
 MAINTAINER user@yourdomain.com
 
 # Install Apache 2.4, PHP 5.6, mysql-client-5.5
 RUN apt update && 
  apt upgrade -y && 
  apt install vim apache2 mysql-client-5.5 
  php5 php5-cli php5-common php5-curl php5-gd php5-imagick 
  php5-json php5-ldap php5-mcrypt php5-memcache php5-memcached 
  php5-mysql php5-readline php5-xmlrpc libapache2-mod-php5 php-pear -y && 
  a2enmod rewrite proxy proxy_http ssl
 
 # Copy custom files
 COPY entrypoint.sh /usr/local/bin/entrypoint
 ADD drupal.tar.gz /var/www/html/
 
 # Exposing Apache
 EXPOSE 80 443
 
 # Start entrypoint
 ENTRYPOINT ["entrypoint"]

• Let’s have a look about Drupal MySQL DB settings below. You should leave the credentials blank to be replaced by the environment variables.

$databases = array (
  'default' =>
  array (
  'default' =>
  array (
  'database' => '',
  'username' => '',
  'password' => '',
  'host' => '',
  'port' => '',
  'driver' => 'mysql',
  'prefix' => '',
  ),
  ),
 );

• Now refer the entrypoint.sh below to determine how we can use environment variables to replace DrupalMySQL DB credentials in runtime.

#!/bin/sh
 set -e
 
 # Apache gets grumpy about PID files pre-existing
 rm -f /var/run/apache2.pid
 
 # Define Drupal home file path
 DRUPAL_HOME="/var/www/html"
 
 # Define Drupal settings file path
 DRUPAL_SETTINGS_FILE="${DRUPAL_HOME}/sites/default/settings.php"
 
 # Check the avilability of environment variables
 if [ -n "$DRUPAL_MYSQL_DB" ] && [ -n "$DRUPAL_MYSQL_USER" ] && [ -n "$DRUPAL_MYSQL_PASS" ] && [ -n "$DRUPAL_MYSQL_HOST" ] ; then
  echo "Setting up Mysql DB in $DRUPAL_SETTINGS_FILE"
 # Set Database
  sed -i "s/'database' *=> *''/'database' => '"$DRUPAL_MYSQL_DB"'/g" $DRUPAL_SETTINGS_FILE
 # Set Mysql username
  sed -i "s/'username' *=> *''/'username' => '"$DRUPAL_MYSQL_USER"'/g" $DRUPAL_SETTINGS_FILE
 # Set Mysql password
  sed -i "s/'password' *=> *''/'password' => '"$DRUPAL_MYSQL_PASS"'/g" $DRUPAL_SETTINGS_FILE
 # Set Mysql host
  sed -i "s/'host' *=> *''/'host' => '"$DRUPAL_MYSQL_HOST"'/g" $DRUPAL_SETTINGS_FILE
 fi
 
 # Start Apache in foreground
 tail -F /var/log/apache2/* &
 exec /usr/sbin/apache2ctl -D FOREGROUND

• Finally, you can simply define the environment variables during the Docker runtime as follows.

docker run -d -t -i
 -e DRUPAL_MYSQL_DB='database' 
 -e DRUPAL_MYSQL_USER='user' 
 -e DRUPAL_MYSQL_PASS='password' 
 -e DRUPAL_MYSQL_HOST='host' 
 -p 80:80 
 -p 443:443 
 --name <container name>
 <custom image>

Now we have a custom Docker image without any sensitive data included, which can be shared publicly without any security concerns.

Step 5: Run CMD/Entypoint from a non-privileged user

It’s always a best practice to run production systems using a non-privileged user, which is better from security perspectives as well.

You might have to set proper file ownership to run some programs from a non-privileged user.

You can simply put USER entry before CMD or ENTRYPOINT in Dockerfile as follows.

# Set running user of ENTRYPOINT
 USER www-data
 # Start entrypoint
 ENTRYPOINT ["entrypoint"]