A Few Good Practices

Let’s finish with a few best practices. This isn’t a full list, and the advice applies to local and cloud builds.

Leverage the build cache

BuildKit uses a cache to speed up builds. The best way to see the impact is to build a new image on a clean Docker host and then repeat the same build immediately after. The first build will pull images and take time to build layers. The second build will instantly complete because the layers and other artifacts from the first build are cached and leveraged by later builds.

If you use a local builder, the cache is only available to other builds on the same system. However, your entire team can share the cache on Docker Build Cloud.

For each build, the builder iterates through the Dockerfile one line at a time, starting from the top. For each line, it checks if it already has the layer in its cache. If it does, a cache hit occurs, and it uses the cached layer. If it doesn’t, a cache miss occurs, and it builds a new layer from the instruction. Cache hits are one of the best ways to make builds faster.

A closer look at caches

Let’s take a closer look. Assume the following Dockerfile: