Skip to content
This repository has been archived by the owner. It is now read-only.

WIP - Docker image size improvements. #198

Closed

Conversation

@glogiotatidis
Copy link
Contributor

@glogiotatidis glogiotatidis commented Jun 16, 2015

  • Current size 597MB
  • New size 259

Rebuilds debian packages on every requirements.txt change.
We need to fix /static/revision info.

@glogiotatidis glogiotatidis force-pushed the glogiotatidis:docker-size-improvements branch 6 times, most recently from 0c411a7 to 2062c16 Jun 16, 2015
- Current size  597MB
- New size 259

Rebuilds debian packages on every requirements.txt change.
We need to fix /static/revision info.
@glogiotatidis glogiotatidis force-pushed the glogiotatidis:docker-size-improvements branch from 2062c16 to 4a533a1 Jun 16, 2015
@glogiotatidis glogiotatidis changed the title WIP - Docker size improvements. WIP - Docker image size improvements. Jun 17, 2015
@glogiotatidis
Copy link
Contributor Author

@glogiotatidis glogiotatidis commented Jun 17, 2015

This is one way to lighten our docker image size. The base principle is to remove development packages which are not needed to the file image.

To achieve this we need to install the needed debian development packages, install python dependencies and finally remove the debian packages all in one RUN.

Things to note:

  • Packages that are needed in the final image must be explicitly apt-get installed, otherwise they will be removed on apt-get autoremove. For example we need libjpeg62-turbo-dev to install Pillow and then we can remove it. But we need libjpeg62-turbo in the final image. Instead of apt-get installing only libjpeg62-turbo-dev, which will bring together libjpeg62-turbo as a dependency, we need to apt-get install both. Otherwise when libjpeg62-turbo-dev gets removed, then apt-get autoclean will remove its dependencies, including libjpeg62-turbo
  • This is based of debian:jessie which supports python 3.4 and it's a smaller image.
  • Every time we change python dependencies we need to run the giant build step which will take more time and needs more MBs to download.

I generally don't like this approach as it complicates the Dockerfile and it feels more error prone. We also lose caching of some layers. This lead me to build #199

@jgmize comments, ideas, questions?

@glogiotatidis glogiotatidis mentioned this pull request Jun 17, 2015
@jgmize
Copy link
Contributor

@jgmize jgmize commented Jun 18, 2015

I appreciate all your explanations on the reasoning behind these changes and their results, but I agree with your summary:

I generally don't like this approach as it complicates the Dockerfile and it feels more error prone. We also lose caching of some layers. This lead me to build #199

This was a useful exercise, but your docker-squash approach in #199 seems to have more promise.

@glogiotatidis
Copy link
Contributor Author

@glogiotatidis glogiotatidis commented Jun 24, 2015

Closing this in favor of #199

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants