Docker Base Images

What are base images?

Every application running inside a container is built upon a foundation. This foundation is called the base image and supports everything above it. A virtual machine requires an operating system that is used by the application running inside it, and in a similar way a containerized application requires a base image.

The choice of base image is very important and the decision needs to be made with due care and attention. A good choice of base image gives your application room to grow and change as your requirements grow and change. A bad choice of base image will restrict your application and can result in costly rewriting and refactoring.

A base image is often a minimized installation of a regular server operating system, like Debian, Ubuntu or CentOS. Unused or unnecessary components  are removed or not installed. This leads to an image that has minimal support requirements, a small attack surface, and is easy to test and validate. It can then be used to create intermediate images to support particular software ecosystems, for example Java.

Continue reading “Docker Base Images”

Kubernetes: Why does it matter?

I wrote an article for about Kubernetes: Kubernetes: Why does it matter?

Developing and deploying cloud-native applications has become very popular—for very good reasons. There are clear advantages to a process that allows rapid deployment and continuous delivery of bug fixes and new features, but there’s a chicken-and-egg problem no one talks about: How do you get there from here? Building the infrastructure and developing processes to develop and maintain cloud-native applications—all from scratch—are non-trivial, time-intensive tasks.

Container of the Week – scratch

There’s literally not much to say about the scratch container as it’s completely empty! This container is usually only used when creating a base container from an external root filesystem in combination with the ADD command.

A Dockerfile that does this would look like:

FROM scratch
ADD rootfs.tar /

The root filesystem can be created outside of Docker or downloaded from a third party.  For example when creating a base container using Debian the root filesystem can be created with debootstrap. The ADD command takes the tarball and extracts it into the container.

Mass-Deleting Docker Images

I’m having a cleanup of my Docker images and there’s a bit of a mismatch between the output format of docker images and the input of docker rmi. I don’t however want to delete everything, only a selection of images.

Luckily there’s a –format argument to docker images which allows an output format to be specified.  Here’s the trick:

$ docker images --format "{{.Repository}}:{{.Tag}}" | \
    grep :foo \
    xargs docker rmi

This command deletes all images with the tag “foo”, something which is tricky using the standard output format.

The documentation for the docker images command has all the details.

Do Docker Users Have a Container Size Fetish?

There is a rather unhealthy obsession, in my opinion, in the Docker community about developing the smallest possible container size. Obviously you don’t want your container to contain hundreds of megabytes of useless junk, but perhaps we have passed the point of diminishing returns. It turns out that it is less expensive to have files in your base image that aren’t used than it is to have duplicated files in higher layers.

Continue reading “Do Docker Users Have a Container Size Fetish?”

Container of the Week – jenkins

This post is part of a series where we examine a different container image each week.  See previous Containers of the Week here. This week’s image is the official image for the Jenkins project, an open source application for building, deploying and automating software.

Running Jenkins inside a container is a simple task, but I’m going to give you a few tips to improve your Jenkins experience with Docker.

Continue reading “Container of the Week – jenkins”

Antifragility and max_fail_percentage in Ansible

In his book, Antifragile, Nassim Nicholas Taleb describes and develops the concept of antifragility – the property of a system to increase in robustness in response to faults or failures. In the computing world, errors often propagate a long way from their source. A simple memory allocation failure dozens of levels deep inside an application can bubble up and cause a long process to be interrupted and waste hours of work. This is pretty much the definition of a fragile system.

Recently I came across the Maximum Failure Percentage option in Ansible that is part of the Rolling Updates feature and was thinking about how it could be used to build antifragile systems for deploying and updating software.

Continue reading “Antifragility and max_fail_percentage in Ansible”

Container of the Week – factorish/syslog

Welcome to another episode of Container of the Week! This time we are going to look at a utility container that assists you in debugging container operation or just helping to understand what’s going on.

Sometimes testing out a new container or troubleshooting is a simple matter of using “docker logs“. Unfortunately some containers do not log very much to standard output but instead use syslog. The factorish/syslog container can be used to start a simple syslog container in a few seconds to aid troubleshooting a container setup.

Continue reading “Container of the Week – factorish/syslog”