Language: English

Making Image Builds and Delivery Faster

Replaced buildx --load into the Docker daemon followed by docker push with a direct push to the registry, cutting the dev CD pipeline by 46%; layer caching and removing a wasteful Dockerfile copy shaved the build further.

While tidying up the CD pipeline for the dev environment, I found waste in how container images were built and transferred. The revision-switching story is split off into the deploy succeeded, but the revision never switched.

The image was being transferred twice

The first implementation loaded the image into the Docker daemon with buildx and then pushed it to the registry.

buildx --load  (67秒)
  ↓ Docker daemon
docker push    (40秒)
  ↓ Registry
deploy

Even with a warm cache, this double transfer alone costs 107 seconds. Since all we want is for the image to sit in the registry, there’s no reason to route it through the local daemon.

buildx --push
  ↓ Registry
deploy

Switching to a direct push from buildx to the registry brought the backend’s whole dev CD down from 3 min 48 s to 2 min 02 s. That’s 1 minute 46 seconds saved — a 46% reduction.

I slimmed down the image itself, too. The backend image went from 365MB to 153MB (a 58% reduction). The smaller what you transfer, the faster both build and deploy get.

Build waits on the CI side

On the CI side as well, I cut the waiting around image builds:

Added buildx GitHub Actions layer cache to the Docker builds
Removed the builder copying itself in the frontend Dockerfile (about 23 seconds per build)

Every one of these lines up in the same direction: fewer transfers, and smaller things to transfer and rebuild.