3

In order to decrease Docker image build time on dynamically provisioned EC2 boxes I decided to use the following method: - run 'docker-compose build' on the master host nightly - clone whole /var/lib/docker dir from the master host to the new box - run 'docker-compose build' on the new box; and if relevant files wasn't modified, build should use cache. But - in fact Docker doesn't use cache. I noticed that build process on the new host produced different hash for the same file (I mean - for the file with the same content).

In this post https://hackernoon.com/working-with-the-docker-build-cache-to-autoscale-our-jenkins-nodes-37b63a3dd2a different mtime was explanation for docker cache invalidation. But as far as I tested, mtime doesn't affect hash value, produced by Docker build. What I'm missing?

Thanks, Vitaly

I'm using Docker version 18.06.1-ce and docker-compose version 1.23.1 on Ubuntu 16.04.

Vitaly Karasik DevOps
  • 316
  • 4
  • 18

1 Answers1

4

I believe docker calculates the checksum on the files using the tarsum spec. This includes the following headers:

  • 'name' - string
  • 'mode' - string of the base10 integer
  • 'uid' - string of the integer
  • 'gid' - string of the integer
  • 'size' - string of the integer
  • 'mtime' (Version0 only) - string of integer of the seconds since 1970-01-01 00:00:00 UTC
  • 'typeflag' - string of the char
  • 'linkname' - string
  • 'uname' - string
  • 'gname' - string
  • 'devmajor' - string of the integer
  • 'devminor' - string of the integer

Fields I would focus on include the filename (which should be case sensitive), file permissions (mode), owner (uid/gid), and size.

Note also that the mtime field is version specific, so if you originally built images on an older version of docker, the mtime could be included in the calculation.

BMitch
  • 231,797
  • 42
  • 475
  • 450