Closed TJM closed 4 years ago
A tool that we have been using lately on our docker images is "dive"
https://github.com/wagoodman/dive
$ CI=true dive docker.bintray.io/jfrog/artifactory-pro:6.9.0
Fetching image... (this can take a while with large images)
Parsing image...
Analyzing image...
efficiency: 79.0840 %
wastedBytes: 254108946 bytes (254 MB)
userWastedPercent: 23.4734 %
Run CI Validations...
Using default CI config
FAIL: highestUserWastedPercent: too many bytes wasted, relative to the user bytes added (%-user-wasted-bytes=0.23473385927040877 > threshold=0.1)
SKIP: highestWastedBytes: rule disabled
FAIL: lowestEfficiency: image efficiency is too low (efficiency=0.7908404361184976 < threshold=0.9)
Result:FAIL [Total:3] [Passed:0] [Failed:2] [Warn:0] [Skipped:1]
@TJM - we are aware of this and have plans to improve this in the future.
BTW - I also love the dive
tool. Very useful!
So, if you build the Docker image outside of the application build, you can just download it directly from the release repo. This was the "solution" I used when I was working around #129 .
As I mentioned in that issue, the best solution (in my opinion) is probably to create a .tar.gz instead of or in addition to the .zip during the build. That way you can use "ADD" instead of "COPY" and just skip the unzip step all together, and not end up with two copies of the application in the Docker image. You could choose whether or not to distribute the .tar.gz publicly, but its probably not useful for much more than building the docker image. (shrug)
~tommy
7.x does not have this issue I guess. With that I am closing this, as this repo is under deprecation.
Using default CI config
Image Source: docker://docker.jfrog.io/jfrog/artifactory-pro:7.x.feature
Fetching image... (this can take a while for large images)
Analyzing image...
efficiency: 99.9975 %
wastedBytes: 44859 bytes (45 kB)
userWastedPercent: 0.0051 %
Inefficient Files:
Count Wasted Space File Path
2 31 kB /var/opt/jfrog/artifactory/etc/system.full-template.yaml
2 8.8 kB /entrypoint-artifactory.sh
2 4.3 kB /var/opt/jfrog/artifactory/etc/system.basic-template.yaml
2 121 B /etc/passwd
2 116 B /var/opt/jfrog/artifactory/etc/access/keys/trusted/README.md
2 68 B /var/opt/jfrog/artifactory/etc/access/keys/README.md
2 66 B /var/opt/jfrog/artifactory/etc/security/README.md
2 60 B /var/opt/jfrog/artifactory/bootstrap/README.md
2 44 B /var/opt/jfrog/artifactory/bootstrap/artifactory/tomcat/lib/README.md
2 40 B /etc/group
2 40 B /var/opt/jfrog/artifactory/etc/README.md
2 38 B /var/opt/jfrog/artifactory/etc/artifactory/plugins/README.md
2 0 B /usr/share/info
2 0 B /root
Results:
PASS: highestUserWastedPercent
SKIP: highestWastedBytes: rule disabled
PASS: lowestEfficiency
Result:PASS [Total:3] [Passed:2] [Failed:0] [Warn:0] [Skipped:1]
Thanks for fixing that :)
I realize you are probably building the docker image from an artifactory "source" directory, but currently your docker images are inefficient due to the:
... line. That file is later unzip'd and removed, but because it was copied in, the file is still part of the image. You could probably optimize that by "downloading" the zip file, then unzipping and removing it all in one "layer" (in one RUN command).
Another option might be "squashing" ? http://jasonwilder.com/blog/2014/08/19/squashing-docker-images/
I realize that the image is excessively bloated in other areas, right now, but I really notice this one as each new version of artifactory comes out I have to download it twice.
Tommy