search

sseefried / docker-build-ghc-android

A Dockerfile to build a GHC 7.8.3 ARM cross compiler for Android development
58 stars 13 forks source link

compresss image layers #1

Closed gregwebs closed 9 years ago

gregwebs commented 9 years ago

If you ADD everything at once and chain commands together with && instead of doing many RUNs, the resulting image may be a lot smaller.

sseefried commented 9 years ago

There's actually a really good reason I decided not to do this. I was developing the build script as I went along. (More precisely I was chopping up a large build script built by others). I wanted to make sure that each part of the script worked without failure before moving on to the next. And because some of the parts took upwards of 30 minutes I didn't want to force Docker to ever have to go back to a checkpoint before one of those long builds.

Unfortunately, if I went back to an ADD command and now added a new file (or it was an ADD command using a wildcard e.g. "ADD user-scripts/* ...") then Docker (correctly) detected that this was different to the command I ran before and started the build process from that checkpoint even though several long running actions had successfully built afterwards.

I just really, really, really didn't want to do this so I sacrificed build script elegance (and now I find image size) for my sanity.

If you look carefully I also had to beef up the environment one more time with set-env-1.sh which just sources set-env.sh. Of course this is inelegant. But it meant I didn't have to sit through 45 minutes of building again, which was a small price to pay.

Personally, once the image is built I don't care about the intermediate images, but I don't want to edit the Dockerfile because I want this script to be somewhat futureproof. I want people to be able to roll back, edit the scriptlet that is giving them grief, and run from that point again which people won't be able to do if it's all compressed into one big "RUN" command connected with the "&&" operator.

gregwebs commented 9 years ago

A solution then could be to have a second Dockerfile that is used for unloading to Dockerhub. Unfortunately the closest tool I cam find to this is https://github.com/dqminh/docker-flatten

sseefried commented 9 years ago

That looks interesting and sounds like a good idea. It seems there are two distinct use cases for Docker here:

  1. Using Docker as a system for aiding the development of build scripts.
  2. Deploying a complete system with a minimal number of intermediate images.