-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Docker API instead of Docker CLI #85
Conversation
This reverts commit 5bd35d8.
Should the Docker image use distroless instead of buster-slim? The resulting image is only 28.4MB instead of 78.8MB. |
Distroless seems fine. Alpine is another option (this seems to indicate that Alpine is somehow smaller than distroless). Another option is to switch to musl and produce a fully static binary with no dependencies, and then use I'll review this as soon as I can. Thanks for bringing it back! I know it's mostly the same as before, so I just need to look at the parts that have changed due to #73. |
I did a release build using x86_64-unknown-linux-musl and the resulting Docker image was 9.48 MB, but I needed to install an additional Rust target and Ubuntu package. Distroless is larger because it contains libc and libstdc++ and libopenssl.
|
LGTM. I'll release this now, and any changes to the Docker base image can be made separately as people see fit. |
@mac-chaffee Now that this has landed, would you like to try out the latest version of Docuum (v0.12.0) and confirm that the issue you noticed before no longer occurs? |
@stepchowfun Looks good! And it's a lot faster too, I guess due to not having to spawn so many
|
This uses the Docker API via the Bollard crate instead of calling out to the Docker CLI and parsing JSON output.
Why do this?
The main motivation behind this is so the call to remove an image can tell when the image could not be deleted due to a conflict (eg dependent images still exist) and then be reasonably sure that the amount of used space has not decreased to an acceptable level so the amount of free space does not need to be recalculated before attempting the next deletion. I estimate the change to skip recalculating space usage made Docuum run 10x faster catching up on a build agent that was used for builds that produced many docker layers over many multistage builds, which when not catching up could still reduce impact on builds that are triggering Docuum to clean up.
That behavior change is not part of this PR. I want to keep this level of refactoring separate from behavior changes.
This is the same code as last time, with some changes from https://github.com/mac-chaffee/docuum/tree/BACKUP2, and an updated version of Bollard which should not have the same problems with BuildKit.
Status: Ready
Fixes: N/A