Utilizing docker build cache #8
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
Every single time our deploy task is ran in CI we are performing a
docker build
from scratch and wait 3+ minutes for every deployment task. Just as we do for development, we can use Docker's build cache to drastically speed up this process by reusing unchanged layers from previously built images. The test I ran on staging completed a deploy in 13s!More context
For multistage Dockerfile definitions that we do for production, this requires registry cache strategy to be used, where cache artifacts are saved independently from the Docker image used to deploy the apps (which is a win win for us). A requirement for registry strategy is
docker buildx
driver instead of the defaultdocker build
.The caching strategy implemented in this PR looks like this:
main
branch, importmain
cache only and exportmain
cache onlymain
cache +branch
cache, exportbranch
cache only - this multi import allows us to still reuse most of the cache (if not all) for freshly created branches which in the first CI run still do not have branch specific cache of their ownWhen exporting cache the
mode=max
param is passed, which yields the maximum cache hit ratio for layers. The size of these cache artifacts are ~700MB per file. We'll generate 1 file for main branch and 1 for every other branch. We can experiment with other modes, likemode=min
to see the file size and cache hit ratio, if we think that size is a concern.After a successful build when new cache artifact get pushed, the previous artifact for that branch automatically becomes stale and untagged in the ECR. And since these stale/untagged files are of no use to us, we'll prune them at the end of every build. Here's how these stale artifacts appear in ECR, just as a
-
👇🏻Conclusion 🚀
By paying some price in ECR storage we can get almost instantaneous deploys, well worth trade imo. And with better defined ECR cleaning policies, we can free up space regularly by removing branches and cache artifacts every N amount of days that we agree on.