Your objective is not just to copy the resulting image from machine 1 to machine 2.
instead you want to copy the layers of the build cache itself to the 2nd machine.
Honestly, that’s a tough one!
I don’t even know in which subfolder of the docker data-root (see docker info) the build cache is located, Lets assume for a moment that it makes more sense to copy the build cache, instead of the resulting image (which could be reused as a base image in a different Dockerfile): you would need to identify and copy the originaly used base image by its checksum, the build cache itself and have an identical graphdriver on both machines. Even though if this approach succeeds, there is not guaranty that the docker engine on the 2nd host is picking up the pieces and putting them properly together. I am afraid this approach is high likey to mess up the metadata of the 2nd instance instead. If you can afford to whipe your Docker data-root if an attempt failed, you could try until you succeed… But if you don’t have the luxury to start with a scratch system, I would definitly not even try it a single time.
If i were in your shoes, I would create my own tag of the target image on machine 1 and actualy save it and load it on the 2nd instance. Since you already have an image with the final steps included beeing ready to be used as a base image, you could easily create another Dockerfile that uses this particualar image to do whatever you feel is missing.
Offtopic update: also be carefull with java8 in the container, as the default behavior is to read the cpu and ram information from the kernel directly and not from the cgroup settings for the container. If you start restricting the CPU/RAM for the container, you might encounter surprises like degraded performance or oom-kills. Java9 support cgroups limits, which are backported to java8 update 132. Though they needs to be enable via JAVA_OPTS specificly!
