Excessive Docker image size ~ 1GB+
dlehammer opened this issue · comments
Hi bonob gurus,
It's my impression the bonob application handles mapping between the Subsonic API and Sonos API, which I presume is handled by a modest amount of code.
So I was wondering why the Docker image is so large, ex. simojenki/bonob:v0.6.2, when compared to seemingly larger applications like Navidrome.
$ sudo docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
deluan/navidrome 0.49.3 125b6caaca75 2 weeks ago 125MB
simojenki/bonob v0.6.2 8d2fc3284c9d 11 months ago 1.11GB
Besides the assumed larger attack surface, I'm using a bit of a space-constrained environment, so a smaller image would be greatly appreciated 🙏
Yes, that is a bit larger that it should be. I'll try and see where all the space went.
Hi @simojenki,
Thanks for taking the time to reply.
Looking at the Dockerfile, I get the impression that the "build" alias is utilized to create a build environment and the subsequent FROM is intended to package the application inside a clean image.
Looking into the v0.6.2 container I get the impression that the build environment is included in the published image.
$ sudo docker exec -it bonob /bin/sh
$ git --version
git version 2.30.2
$ yarn --version
1.22.18
$ du --human-readable --max-depth=1 | sort --human-numeric-sort --reverse
du: cannot read directory './etc/ssl/private': Permission denied
du: cannot read directory './root': Permission denied
du: cannot read directory './var/cache/ldconfig': Permission denied
du: cannot read directory './var/cache/apt/archives/partial': Permission denied
du: cannot read directory './proc/tty/driver': Permission denied
du: cannot access './proc/16210/task/16210/fd/3': No such file or directory
du: cannot access './proc/16210/task/16210/fdinfo/3': No such file or directory
du: cannot access './proc/16210/fd/4': No such file or directory
du: cannot access './proc/16210/fdinfo/4': No such file or directory
1.2G .
888M ./usr
260M ./bonob
16M ./var
8.0M ./lib
5.2M ./opt
5.2M ./bin
4.3M ./tmp
3.6M ./sbin
2.0M ./etc
20K ./home
8.0K ./run
4.0K ./srv
4.0K ./root
4.0K ./mnt
4.0K ./media
4.0K ./boot
0 ./sys
0 ./proc
0 ./dev
Hope this helps a little 🤓
Ive reduced the image size to ~485MB. Unfortunately I don't think I can remove much more from it, turns out that node.js dependencies are huge.
You can test this with the simojenki/bonob:master image.
Hi @simojenki,
Thanks for the effort, it's a impressive optimization as far as I'm concerned 🤓
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
simojenki/bonob master a321fbdf46c2 39 hours ago 485MB
node 16-bullseye-slim 6d9347ba850a 6 days ago 191MB
simojenki/bonob v0.6.2 a9528c636a4a 11 months ago 1.16GB
Looking inside /
$ du --human-readable --max-depth=1 | sort --human-numeric-sort --reverse
509M .
295M ./usr
178M ./bonob
9.6M ./var
8.7M ./lib
5.2M ./opt
5.2M ./bin
4.3M ./tmp
4.0M ./sbin
1004K ./etc
24K ./home
8.0K ./run
4.0K ./srv
4.0K ./root
4.0K ./mnt
4.0K ./media
4.0K ./lib64
4.0K ./boot
0 ./sys
0 ./proc
0 ./dev
Looking at /bonob
$ du --human-readable --max-depth=1 | sort --human-numeric-sort --reverse
178M .
177M ./node_modules
436K ./web
300K ./src
Albeit I'm no Node-developer, I skimmed the package.json, and seems to me like some dependencies are defined twice.
Once with prefix ex. "@types/express": "^4.17.17" and subsequently without "express": "^4.18.2" ~ also the versions differ.
Perhaps there's a possible gain by trimming the dependencies 🤔
Those @types dependencies are the type defs for the respective js library so that typescript knows what the types are.
I'm not sure why the versions don't track each other, I guess because the type defs only need to change when an interface changes.
Hi @simojenki,
Thanks for taking the time to answer, that makes sense (~ not that the dependencies are so bulky, but I have heard that Node projects can get large fast 🤠).
I think the cefdf5e improvement is sufficient for now.
I'm closing this issue, and looking forward to a tagged release 🙏