You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would these hooks run inside the container that's run as part of the RUN, or is this all running on the host? If it's inside the container, would this be similar to a custom SHELL (to set a custom entry point for RUN steps)?
I'd like to propose a hooking mechanism for
RUN
instructions of Dockerfile.e.g.,
buildctl build \ --frontend dockerfile.v0 \ --opt hook="$(cat hook.json)"
with
hook.json
as follows:This will let the frontend treat
RUN foo
as:RUN \ --mount=from=example.com/hook,target=/dev/.dfhook \ --mount=type=secret,source=something,target=/etc/something \ /dev/.dfhook/entrypoint foo
docker history
will still show this asRUN foo
.Note
The proposed json schema may change.
See the PR for the latest status:
RUN
instructions #4669Use cases
Reproducible builds
A hook can be used for wrapping
apt-get
command to usesnapshot.debian.org
for reproducing package versions without modifying the Dockerfile.The
/dev/.dfhook/entrypoint
script can be like this:A hook may also push/pull dpkg blobs to an OCI registry (or whatever) for efficient caching.
Cross-compilation
xx-apt
, etc. (https://github.com/tonistiigi/xx) can be reimplemented as a hook.Malware detection
A hook may use seccomp, etc. to hook the syscalls and detect malicious actions, etc.
Enterprise networking
Enterprise networks often require installing a MITM proxy cert.
This can be easily automated with a hook.
FAQs
The text was updated successfully, but these errors were encountered: