Verify Docker Images Build By Docker-In-Docker

Using Docker, deployments are more reliable and faster than ever. But how about the docker images build? Containers don’t have any silver bullets. It shifts installation instability from deployment cycle to image build cycle.

I would expect a general solution for the verification of all docker images build. And it should work across different projects. This means less time and effort. Certainly, save money!


With endless development, we need to rebuild docker images occasionally:

  1. Install new packages
  2. Update existing packages to a new version.
  3. Reconfigure or tune services via config files or similar ways.

Rebuilding old images may fail in many ways:

  1. Unexpected manual steps. It would be frustrating, if we can’t build images purely from Dockerfile.
  2. Package installation with latest versions may incur incompatible issues.
  3. Package installation with specific versions fail. They might have been marked as obsoleted in the repo.
  4. Outage of dependent services, etc.

See more about this: 5 Common Failures Of Package Installation

1.1 Why Docker-In-Docker?

I choose to use Docker-In-Docker to verify image build. Why? Yes, I know many people are strongly against dind(docker-in-docker). Like this one.[1]

With my years’ experience, I’m confident that dind is very capable for this scenario:

  1. Super easy to setup and run. Literally we only need to use “docker run”, then perform tests.
  2. Leave no trace or garbage in docker host. If using a shared host, people’s daily work might be disturbed by our tests.

For your convenience, I’ve published a docker image(See Dockerfile).GitHub

# Pull docker image
docker pull denny/docker:v1.0

# Start a container to build images inside
docker run -t -d --privileged -h dockerimages \
  --name docker-images denny/docker:v1.0 /usr/bin/dockerd

# Login to the container
docker exec -it docker-images bash

# Download a dockerfile for test purpose
wget -O /root/java_v1_0.dockerfile \

# Build docker image inside current container
cd /root/
docker build -f java_v1_0.dockerfile -t denny/java:v1.0 --rm=true .

# Verify docker images
docker images | grep denny/java

1.2 Suggestions Of Running DIND

  1. Don’t use devicemapper as your storage driver. By default, containers can only have 10GB disk. Yes, we could mount volume for big folders. Still, inconvenient.
  2. Stop containers first, before decommission. At the end of testing, make sure we stop containers first, then stop dockerd and finally destroy the env.
  3. When building multiple images, the sequence matters. Let’s say, image B might depends on image A. If image A is public, do we still need to care about the test sequence? The answer is yes. We need to build B based on latest A, instead of the version in docker hub.
  4. Speed up image build by loading frequently used golden images first. The pre-loading would not only save us lots of time, but also the false negatives of network turbulence.
# Export docker image
docker save ubuntu:14.04 > ubuntu_1404.tar.gz
# Import docker image
docker load -i ubuntu_1404.tar.gz

1.3 What About Sensitive Files?

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.