Nice!
Our docker builds are getting slow despite using kaniko, does depot has a better caching than kaniko?
How so?
Our docker builds are getting slow despite using kaniko, does depot has a better caching than kaniko?
How so?
Both Kaniko and BuildKit can be run in rootless mode - we are not doing this, instead we give every builder access to an isolated VM, so builds are a bit quicker as well by avoiding some of the security tricks that rootless needs to work.
To make this performant we keep a certain number of spare "warm" machines ready for build requests so that you don't have to pay the instance launch time penalty yourself.
> I think we solved it with buildkit cache
One big thing we're doing here, if you're familiar with BuildKit cache, is providing builds a stable cache SSD that's reused between builds. This means we support all of BuildKit's caching features, including things like cache mounts that aren't directly supported in ephemeral CI environments. Plus Depot doesn't need to save or load the cache to a remote store like S3 or GitHub Actions cache, instead the previous cache is immediately available on build start.
This may not be any better or different than what you're doing, I just wanted to mention the detail for anyone familiar with trying to make BuiltKit more performant.
> the setup you are describing, if I understand correctly might be a no-go for enterprise customers
Fwiw, I know at least buildbuddy operates in a similar space (hosted bazel cache/builds, client/server style).
In that deployment model, the Depot control plane passes changes to make in the customers environment via a small agent they run in their account. Here is some docs we put together for anyone that wants to go into a bit more of the details: https://depot.dev/docs/self-hosted/architecture