docker-squash ftw!

[glogiotatidis]

Current docker image size ~600mb
After docker-squash ~350mb

See also http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/

[glogiotatidis]

This approach utilized docker-squash a third party tool written in go, which squashes some layers of a docker image into one, instead of all layers into one with docker export | docker import. The main advantage of this approach over the is that it allows us to re-use the base image for new builds and in other apps.

Notes:

• Since we are going to squash the layers we can write a more readable Dockerfile, which installs the needed debian packages in one step, then in another install the python packages and finally in other steps removes packages and files not needed in production. Tip: removing /usr/share/docs and /usr/share/man saves you around 50 megs.
  • The docker-squash utility it needs obviously to be available in the build server. It also needs to run as root. I added in /usr/local/bin in our server and updated sudoers to allow jenkins to run this command without a password. If we go this way I'll update the ansible playbook to automatically install docker-squash.
  • Changes in the build script are needed to run docker-squash after building the image. Note that image gets squashed before running any tests, to make sure that it is not missing anything. Then the squashed image gets uploaded to docker hub.
  • Since docker-squash is post-build step we can still take full advantage of docker caching.

The final docker image weights around 350Mb, of which the 120Mb is the python base image and the rest is masterfirefoxos code + dependencies.

My concern with both #198 and this approach is that on every python dependency change the amount of data contributors have to download is bigger than the current size. This is not a problem for this project but something to keep in the back of our minds for other projects.

@jgmize comments, ideas, questions?

[jgmize]

I like this approach; I think it has some real potential, and I really appreciate your detailed explanations in this PR and in #198. :)

My concern with both #198 and this approach is that on every python dependency change the amount of data contributors have to download is bigger than the current size.

If a contributor is building images locally from the dockerfile because they're adding new dependencies, then they'll still have caching of previously built layers.

I think we might want to also consider creating a separate squashed "base image" that only includes the installed dependencies, and leaves out the COPY . /app step, which isn't necessary for development since that will be in a volume. Then we could have a separate Dockerfile for deployment that does a FROM mffosbase:tag and then COPY masterfirefoxos /app. I think that would allow us to leverage layer caching better for both dev and deploy. We can try that later though; I think this is a pretty big improvement already as it is.

[jgmize]

I think some judicious use of escaped newlines would help the readability here ;)

Also, would you mind filing a PR to https://github.com/mozilla/webprod-jenkins to install docker-squash?

[glogiotatidis]

OK I test-deployed this pr and works fine. I'm going to merge this and PR against webprod-jenkins with docker-squash updates too.