Docker Build Cache: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(→TODO) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache | |||
* https://www.baeldung.com/linux/docker-build-cache | |||
=Internal= | =Internal= | ||
* [[Docker_Concepts#Build_Cache|Docker Concepts]] | * [[Docker_Concepts#Build_Cache|Docker Concepts]] | ||
* [[Docker build#The_Build_Process|docker build & | * [[Docker build#The_Build_Process|docker build | The Build Process]] | ||
=Overview= | =Overview= | ||
The Docker build cache is used during the [[Docker_build#The_Build_Process|image build process]]. | |||
If the Dockerfile does not change, and if none of its instructions are ADD or COPY, the corresponding cached image will be used. If a line in Docker file had changed, the build process will rebuild the layers from that line onward. | |||
As the Dockerfile instructions are evaluated in order, Docker inspects the [[Docker Build Cache#Overview|build cache]], looking for cached layers that can be reused, instead of building a duplicate image from scratch. | |||
The commands are matched against cached images, according to the following rules: | |||
* Starting with a parent image that is already in the cache, the next instruction is compared against all cached child images derived from that parent image, to see if one of them was built using ''the exact same instruction''. If no such child image exists, the cache is invalidated. | |||
* The literal instruction - the text of the command - is used in comparison (presumably the cache maintains those instructions), with the exception of [[Dockerfile#ADD|ADD]] and [[Dockerfile#COPY|COPY]]. | |||
* In case of [[Dockerfile#ADD|ADD]], [[Dockerfile#COPY|COPY]], the contents of the files to be copied are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. The corresponding files in cache are also checksummed and the checksums are compared. If anything changed in the file - content or metadata - the cache is invalidated. | |||
* Aside from [[Dockerfile#ADD|ADD]] and [[Dockerfile#COPY|COPY]] commands, cache checking does not look at the file arguments to determine a cache match. The following commands '''require''' [[Docker_build#--no-cache|--no-cache=true]] to be effective: | |||
** <tt>RUN yum -y update</tt> | |||
** <tt>RUN apt-get -y update</tt> | |||
** <tt>git clone</tt> | |||
* The FROM instruction is not affected by the --no-cache argument. If the base image is present in the machine, it will not be pulled again. It can be forced to be pulled with [[Docker_build#--pull|--pull]]. | |||
* Once the cache is invalidated (which happens if the cache cannot be used for a particular layer), all subsequent layers will not be loaded from cache and the corresponding Dockerfile commands generate new layers. | |||
The build cache can be explicitly invalidated if the docker build [[#--no-cache|--no-cache]] command line option is used. | |||
If a cached image was used, the build command output states that: | |||
Step 2/5 : COPY ./loop /opt/loop | |||
---> '''Using cache''' | |||
---> 171da11cf0ef | |||
Latest revision as of 21:52, 21 October 2020
External
- https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache
- https://www.baeldung.com/linux/docker-build-cache
Internal
Overview
The Docker build cache is used during the image build process.
If the Dockerfile does not change, and if none of its instructions are ADD or COPY, the corresponding cached image will be used. If a line in Docker file had changed, the build process will rebuild the layers from that line onward.
As the Dockerfile instructions are evaluated in order, Docker inspects the build cache, looking for cached layers that can be reused, instead of building a duplicate image from scratch.
The commands are matched against cached images, according to the following rules:
- Starting with a parent image that is already in the cache, the next instruction is compared against all cached child images derived from that parent image, to see if one of them was built using the exact same instruction. If no such child image exists, the cache is invalidated.
- The literal instruction - the text of the command - is used in comparison (presumably the cache maintains those instructions), with the exception of ADD and COPY.
- In case of ADD, COPY, the contents of the files to be copied are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. The corresponding files in cache are also checksummed and the checksums are compared. If anything changed in the file - content or metadata - the cache is invalidated.
- Aside from ADD and COPY commands, cache checking does not look at the file arguments to determine a cache match. The following commands require --no-cache=true to be effective:
- RUN yum -y update
- RUN apt-get -y update
- git clone
- The FROM instruction is not affected by the --no-cache argument. If the base image is present in the machine, it will not be pulled again. It can be forced to be pulled with --pull.
- Once the cache is invalidated (which happens if the cache cannot be used for a particular layer), all subsequent layers will not be loaded from cache and the corresponding Dockerfile commands generate new layers.
The build cache can be explicitly invalidated if the docker build --no-cache command line option is used.
If a cached image was used, the build command output states that:
Step 2/5 : COPY ./loop /opt/loop ---> Using cache ---> 171da11cf0ef