345
Docker Building (lemmy.ml)
submitted 1 year ago by to c/programmerhumor@lemmy.ml
50 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 1 year ago (1 child)

Ah thanks, I do have another question actually! So aside from speeding up builds by parallelizing different stages, so that

FROM alpine AS two
RUN sleep 5 && touch /a
FROM alpine AS one
RUN sleep 5 && touch /b
FROM alpine AS three
COPY --from=two /a /a
COPY --from=one /b /b

takes 5 iso 10 seconds, are there any other ways buildkit speeds up builds?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago

    Yeah! So the first thing that BuildKit provides that greatly improves build time is that it will detect and run the two stages (one, two) in parallel so the wall-clock time for your example is 5s (excluding any overhead). Without BuildKit, these would be built serially resulting in a wall-clock time of 10s (excluding any overhead).

    Additionally, BuildKit uses a content-based cache rather than a step-by-step key cache used by classical Docker. This content-based cache is intelligently reused across different builds and even re-ordered instructions. If you were to build then rebuild your example, the sleep steps would be skipped entirely as those steps are fully completed and unchanged in the content-based cache from the previous build. It will detect changes and re-build accordingly.

    Lastly, (albiet not a BuildKit feature directly) is to leverage inline build caching for things such as dependencies so they are persisted to your filesystem and mounted during build time such that you don't have to fetch them constantly. This isn't really necessary if leveraging BuildKit fully since the content-based cache will also handle the dependencies and only pull if changed. i.e:

    RUN --mount=type=cache,target=/root/.cache \
    your-build-command
  • permalink
  • fedilink
  • source
  • parent