It's been a while since I have written anything new! But I'm excited to finally share why that has been the case and what I have been working on.
For the past year, I have been building, with my friend and colleague, a new remote Docker build service that provides blazing fast compute and persistent intelligent caching with zero-configuration. We call it Depot. It is a drop-in replacement for
docker build and is compatible with the entire existing container eco-system.
After running many platform and infrastructure teams across different companies over the past three years we have run into the same types of problems surrounding Docker images.
First, writing a
Dockerfile (the file format that defines how an image should be assembled) is quite simple for naive things. But it is very easy to get wrong in subtle ways that cause your build times to explode. Slowing down the delivery pipeline and decreasing productivity. The only way to solve that problem is to gain expertise in learning the very intricate details of the format to optimize your build performance.
Second, BuildKit (the engine that backs Docker) has rudimentary caching. If one layer in the assembly changes between build X and Y, the entire cache gets invalidated at that point. Causing the entire build to be redone from the point where the invalidation occurred.
Third, existing solutions don’t make it easy to reuse the same cache. Nine times out of ten build caches are kept locally on developers machines. Totally inaccessible to other developers for reuse. On top of that, current CI systems restrict the amount of disk space you can have. Meaning your cache might be unusable if it doesn't fit on disk. Often times saving/loading of cache in existing systems can take away any performance benefits you may have seen. Making it very hard to maintain a stable cache that your CI system can use.
We built Depot to solve all these problems.
Underneath the hood, our build machines provide fast compute with higher specs than generic CI providers and fast persistent storage. We provision build machines for remote Docker builds to have at least 4 CPUs, 8 GB of memory, and a 50 GB SSD. Allowing builds that use
depot build to complete 2-3 times faster than traditional
docker build. You can check out the benchmarks for yourself.
A cool thing about a remote build service is that time savings from caching is shared. Because all builds for a given project (i.e.
Dockerfile) share a fast remote builder with persistent cache, everyone gets to use the cache. No need to rebuild if nothing changed between my build and yours, just download the result. Another bonus, Docker no longer consumes your laptop's CPU during builds!
But we didn't stop there. We also wanted to solve the problem of multi-architecture builds. Almost no CI providers today allow you to build native ARM container images. You often have to build them yourself (on an M1 Mac, for example). Or provision a special CI process that builds images on an ARM CPU.
depot build, we detect the architecture of the machine requesting a new build and route it to a builder with the same architecture. No more emulation needed. Get a container image that runs natively. You can also build and push dual x86 / arm64 multi-architecture images to supported registries.
We are also building a more intelligent caching system. Naive caching requires optimizing a
Dockerfile and paying the price to climb that learning curve. We want caching to be smarter without any extra work. We are working on an intelligent caching tier that is dependency aware. Meaning we can more often reuse layers in an image, even if the one before it changed.
We are currently in closed beta as we iterate with our initial users. We have a lot of big ideas we want to incorporate in future versions that are going to speed up the container image build process even more.
If you would like to give Depot a try on your own, please feel free to sign up for an account. We are adding more users into the closed beta each week, so watch your email for your invite. If you want to follow along with what we are doing, you can give our Twitter account a follow.