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”
I have been doing a bit of work on analysing the Docker official library images using the bashbrew tool. If you are an experienced Go developer then perhaps it’s obvious how to get it working but I had some trouble.
Here is a quick introduction to getting the bashbrew tool working.
Continue reading “Analysing Docker Library Images with Bashbrew”
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:
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.
This week we are going to look at a fairly popular container that is often used as a base for larger images – busybox. We’re also going to look at some of the upsides and downsides of busybox, a somewhat tempestuous project in the free software world.
Continue reading “Container of the Week – busybox”
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?”
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”
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”
If you are like me then you have probably written the following code a lot as the first command in your Dockerfile:
RUN apt-get update && apt-get install git wget
or maybe you need to build a C program to run in your container and use something like this:
RUN apt-get update && \
apt-get install autoconf automake gcc
It turns out that you can replace both of these scenarios with a base container image from the buildpack-deps
Continue reading “Container of the Week – buildpack-deps”
If you were lucky enough to go to DockerCon 2017 (I wasn’t) you might have seen the announcement of Moby and LinuxKit, Docker’s new framework for assembling specialised container systems. Traditionally a bare metal or virtual machine that runs Docker has run a “full service” distribution like Debian, Ubuntu or RedHat Linux. Docker and containerized applications are then installed and run on that server. LinuxKit gives us a quick and easy way of building an OS for the host machine that’s customised to run containers and not a lot else.
Continue reading “LinuxKit – the software-defined OS”
I recently wrote an article about command line completion for Docker. This is the parallel article for Kubernetes. The TLDR for command line completion in Docker was that it probably already works just fine. The same is not true for Kubernetes but is easily fixed.
Overall, the installation process for Kubernetes is still slightly complicated and there are many vendors making their own Kubernetes packages. Unfortunately the majority of the effort is focussed on installing and configuring the server-side components of Kubernetes. This makes sense given the complexity involved, but it leaves users of the command line client out of luck. There’s good news though as it’s very easy to install the pieces needed for command line completion for Kubernetes. Continue reading “Kubernetes Command Line Completion”