At Okteto we are very passionate about increasing developer productivity. We were looking for ways to improve our container build times when we came across an amazing project, BuildKit. BuildKit helps us build Docker images faster than ever.
But when getting started we found that there were very few practical examples on how one could optimize their Dockerfiles with Buildkit - so we thought why not change that? This article is going to be about how you too can optimize your Docker builds using Buildkit caches!
The first question which arises is, why even bother with optimizing your Dockerfiles? Well, the thing is that containers have revolutionized how we build, ship, and run our applications these days. So much so that containers are now heavily integrated into the development cycle and are built over and over - manually or in CI pipelines for testing and live previews.
The biggest quality of life improvement that comes with better image build times is faster testing and review cycles. The quicker everyone can see and test the changes they make, the more the productivity of the team would increase! We have first-hand witnessed this for our website, but more on that later.
Before we look at how we can speed up build times using BuildKit, let's first see how a standard Dockerfile for Webpack should look like.
# Dockerfile FROM node:16 as build WORKDIR /usr/src/app COPY package.json yarn.lock ./ RUN yarn install COPY . . RUN yarn build FROM nginx:alpine COPY --from=build /usr/src/app/dist /usr/share/nginx/html EXPOSE 80
This Dockerfile uses a
build step to build the final artifacts, and then, it copies the artifacts to an
In order to optimize the Dockerfile instructions cache, we are purposefully first copying
yarn.lock to install the runtime dependencies. We don't copy over everything else in this same step since most of the commits don't change the yarn dependencies, allowing this step to be cached in those cases leading to better build times! But this is already a commonly known best practice and BuildKit would help us optimize the process even more.
The next thing we do is to
COPY all our remaining files from our local folder to our
WORKDIR. Our changes would be made to one of these files so this means that
yarn build is always executed unlike the
yarn install instruction above.
Remember to configure your
.dockerignorefile. In this case, adding
.dockerignorefile will dramatically reduce the time to send your build context to the docker daemon. This is even more relevant if your build is running on a remote server.
Now that we've looked at how a standard Dockerfile for Webpack looks like, let's see how we can leverage BuildKit caches to further reduce our build times. BuildKit enables us to configure cache folders for the
RUN instructions in our Dockerfile.
Contents of the BuildKit cache directories persist between builder invocations without invalidating the instruction cache. BuildKit also takes care of compatibility - our builds would work with any contents of the cache directory. This is necessary since another build may overwrite the cache files or GC may clean it if more storage space is needed.
# Dockerfile.buildkit FROM node:16 as build WORKDIR /usr/src/app COPY package.json yarn.lock ./ RUN --mount=type=cache,target=/root/.yarn YARN_CACHE_FOLDER=/root/.yarn yarn install COPY . . RUN --mount=type=cache,target=./node_modules/.cache/webpack yarn build FROM nginx:alpine COPY --from=build /usr/src/app/dist /usr/share/nginx/html EXPOSE 80
What this means is that
yarn install and
yarn build will be much faster. This is because their contents will be cached now onwards instead of them being run from scratch every time like earlier.
Please note that we've not covered the installation process for BuildKit in this article since it's fairly simple and is documented well here.
The improvement in build times we saw for our website after using BuildKit was phenomenal! Have a look yourself.
The first graph shows the performance improvement we saw whenever we changed a dependency of our website and the second one shows the boost we got from using BuildKit when making code changes.
This means if you're building your images 100 times a day, you save more than 1 hr 23 mins of build time every day!
We hope you too can now appreciate how powerful BuildKit is. A change of only two lines of code in your Dockerfile can dramatically decrease your image build times! We hope this article was useful and you too are now able to optimize your Docker builds.