In the previous blog post of the building docker images series we had a look at Docker image build pipelines. We revealed typical problems and looked at how to overcome some by utilizing multistage builds.
In part 4 of this series we work with an addition to the Docker tooling which is BuildKit.
Let’s recap what we have covered in this blog post series so far. In Building a Docker Image we had a look at the anatomy of a Docker image. And Optimizing a Docker Image shed some light on optimizations when building an image.
This post continues where we left off with Building a Docker Image. We are looking into how we can optimize the process of building a Docker image. This optimization can aim at reducing the size of images built or the time it takes for packaging an image.
This post starts a series of articles taking a deep dive on building Docker images. But before we look at building a Docker image let’s briefly recap the essentials we need to know about container images.
A Docker image is built up from a series of layers where each layer represents an instruction in the image’s Dockerfile. When Docker materializes an image and creates a container from this image, a storage driver handles the details about the way these layers interact with each other. Different storage drivers are available, which have advantages and disadvantages in different situations (e.g. AUFS, overlay, overlay2, btrfs,zfs). All drivers have in common that they use stackable image layers and the copy-on-write (CoW) strategy for writing files.
This is part 1 of a series of posts covering Docker in a Continuous Delivery environment.
Today I’m showing how simple it is to setup a continuous delivery build pipeline infrastructure using Docker. In an upcoming post we will look at Jenkins pipeline as code creating Docker images and running integration tests against Docker containers. The series will close with an article explaining how we can move all containers built throughout this series of posts in a Docker swarm environment.
This time we look at managing large numbers of compose projects.
When building complex infrastructure using docker-compose we soon end in a mess of scripts for starting, updating, etc. containers. I will try to describe an approach that has helped to get this done in a very structured way.
In this blog post we are looking into how we can create modular compose projects.
With docker-compose we can describe a bunch of containers and container related resources such as networks and volumes that make up an application. All this is usually going into a docker-compose.yml file.
