Choosing a Base Image
Recall from the discussion in Chapter 2 that a Docker image is defined using a Dockerfile, which is a set of commands that are executed to create the image. Commands can include tasks such as downloading and installing applications or packages, copying files, setting environment variables, configuring what to execute when a container is started, and more. Each command in a Dockerfile is built as a separate layer and Dockerfile commands are stacked on top of one another in a hierarchy of layers. What this means is that development teams can take advantage of layering to create a base image that includes any shared components or configuration settings. Teams can start with this base image and customize as needed for improved reusability.
Choosing a base image for your microservice depends on a number of factors. The first consideration is whether you’re planning to run on specialized hardware. For example, if you are building an IoT (Internet of Things) solution with Docker, one option to consider is the Resin.IO base images (https://hub.docker.com/u/resin/), which are specially tuned images that can run on devices like the Raspberry Pi or Intel Edison.
For a minimalist starting point, Alpine is a popular Linux image that is only 5 MB in size. The key benefit to Alpine is not only its small size, but that it includes a number of packages available via the Alpine Package Kit (APK) that add on key features so you can get exactly the minimum dependencies your application needs. For more information, see http://wiki.alpinelinux.org/.
If you do need full control, you don’t have to use the official images. You can build your own base Dockerfile (using “FROM scratch,” a reserved word for an empty image) as this provides you full control over how you’re your image is created. Along with full control comes the responsibility to fully maintain and patch your Docker image.
The most common choice for base images for teams is to start with official base images from Docker Hub (http://hub.docker.com). There are a number of official images for programming languages like ASP.NET, Node, Go, Python, Java, and so on. The advantage to this approach is that someone else is responsible for the security, maintenance, performance, and versioning of the images. There is a level of trust involved here as you are trusting that the maintainers of the official image have made it secure, optimized for performance, and are regularly maintaining the image. The other benefit is that the official repository include a collection of images, grouped using tags, that include different configurations. For example, the official Java repository has tagged images that include different Java Runtime Environment (JRE) versions, like Open JDK 6, 7, or 8.
For many of the official platform images, you’ll find a number of tags that can be confusing to developers new to Docker or Linux. For example, Figure 4.1 shows some of the different tags used in the official Node image at https://hub.docker.com/_/node/.
Let’s review these tags, as you’ll find many of them are commonly used in other Docker Hub images:
• latest: The latest version of the image. If you do not specify a tag when pulling an image, this is the default.
• slim: A minimalist image that doesn’t include common packages or utilities that are included in the default image. Choose this image if the size of the image is important to your team, as the slim image is often half the size of the full image. Another reason to use the slim image is that smaller images inherently have a smaller attack surface, so they are generally considered more secure.
• jessie/wheezy/sid/stretch: These tags represent codenames for either versions or branches of the Debian operating system, named after characters from the Toy Story movie. jessie and wheezy represent Debian OS versions 6.0 and 7.0 respectively, and sid is the codename for the unstable trunk, and stretch is the codename for the testing branch.
• precise/trusty/vivid/wily: These tags represent codenames for versions 12.04 LTS, 14.04 LTS, 15.04, and 15.10 of the Ubuntu operating system.
• onbuild: The onbuild tag represents a version of the image that includes onbuild Dockerfile commands which are designed to be used as a base image for dev and test. In normal Dockerfile commands, the execution happens when the image is created. Onbuild Dockerfile commands are different in that execution is deferred, and instead is executed with the downstream build.