making Docker image smaller

[elreydetoda]

Hello :slightly_smiling_face: ,

Thank you for the awesome project! I noticed that when I was building the docker image that it was ~2.5Gbs, and I was curious if I could make it any smaller.

I know that a common trick in the docker community is to add --no-install-recommends to apt-get ( here is Canonical ( creators behind ubuntu ) mentioning how they reduced their image size by 60% just for that one addition ). Personally, I only do this when I notice that the image size is starting to get bigger. As a byproduct of this, I did have to add a few more packages ( which were implicitly installed with the recommended before ), so I added python3-dev, python-dev, python3-setuptools, python-setuptools, python3-wheel, and python-wheel.

Also, I know a lot of projects remove the apt cache folder of /var/lib/apt/lists/* every time they run an apt-get install. They do that because if you don't clear that folder out every it will commit those files in that steps size ( more on that here ).

So, after adding those two I also added RUN python3 -m pip install --upgrade pip , to close #162 because it was preventing me from building.

When I ran the build again it has reduced the size to ~1.8Gbs instead of the previous 2.5 before.

Here are the test results from the original build ( before my additions, except for adding the pip upgrade ( because it wouldn't build without it ) ), and here are the results I got from the tests with all my additions. ( got them by running the run-tests.sh script )

I used these two versions ( original & mine ) to remove the timestamps at the front so I could vimdiff them and see if there were any major differences ( I didn't notice any ).

If you want I could ( in another PR ) try to make the image size even smaller by trying a multi-stage build approach.

Let me know if there is anything else I should explain, or if you want me to make that other PR. :grin:

[lanjelot]

Bro thanks for working on this it's been on my mind as well. I think it would be best to try and use alpine instead though, would you like to give that a go?

[elreydetoda]

Bro thanks for working on this it's been on my mind as well. I think it would be best to try and use alpine instead though, would you like to give that a go?

Ya, I can definitely give it a try :slightly_smiling_face:

I know that particularly for python, alpine can sometimes be troublesome ( more here ), so would you mind if I use the python3-slim variant? Based on this section of the article ubuntu is also a pretty good alternative ( and might be faster according to this, but IMO it is very marginal ) but the python3-slim variant will let you easily upgrade/pin versions of python3 depending on your development wants.

[elreydetoda]

Hey @lanjelot, are you for sure wanting to keep the python2 support? Since py2 has gone EOL I can only imagine supporting it will keep getting even more difficult. For example debian has removed python2-pip completely from their repos:

# apt install python-pip
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package python-pip is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  python3-pip
E: Package 'python-pip' has no installation candidate

I can only imagine other distros will eventually follow that lead and remove it from their repos as well.

[elreydetoda]

Also, one thing that will be very painful and potentially fragile for the alpine image (if we went with that route), is all the community contributed packages that ubuntu/debian already have (i.e. ike-scan, ninja-build, etc..) which we would have to re-implement on alpine. So, this repo would have to stay up to date ( relatively ) with when these packages have update, breaking changes, etc... which is a lot more extra work specifically so we could use alpine.

I don't know if I would be able to come up with how to do all that stuff and in a maintainable way to hand off to you, without it being a manual process of vetting updates.

[lanjelot]

Thanks for looking into this mate, if going with alpine is going to require too much work, what about going with the multi-stage build approach you mentioned in your first comment?