Repository navigation
[RFC] Record installed slices in --root and install only what's missing #10
Description
Currently it's not efficient to use chisel for an image that's based on another image that was also built using chisel. This is related to the current lack of any metadata/database of installed slices in the final images.
There's a desire to have 2 kind of images for some programming language environments (for example .NET or Go):
runtime-depsimage: This image contains required dependencies to run self-contained applications compiled from an language SDK. Examples are self-contained application bundles in .NET or static binaries in Golang. These final products have no dependencies on the language runtime as they bundle it. But they still require libraries on which the language runtime depends.runtimeimage: This image is super-set ofruntime-depscontaining language runtime in addition to its dependencies.
The way we currently use chisel is something a little bit more complex than this illustrative example (that also pretends chisel is in PATH):
FROM ubuntu:22.04 as builder
RUN chisel cut --release ubuntu-22.04 --root /rootfs slice1_libs slice2_libs
FROM scratch
COPY --from=builder /rootfs /
If we apply this for the 2 images described above, we would end up with something like the following 2 Dokcerfiles.
For runtime-deps image:
FROM ubuntu:22.04 as builder
RUN chisel cut --release ubuntu-22.04 --root /rootfs libc6_libs libgcc-s1_libs libstdc++6_libs
FROM scratch
COPY --from=builder /rootfs /
For runtime image (here .NET is used as an example):
FROM ubuntu:22.04 as builder
RUN chisel cut --release ubuntu-22.04 --root /rootfs-dotnet dotnet-runtime-6.0_libs
FROM runtime-deps
COPY --from=builder /rootfs-dotnet /
Even though we base our final runtime image on runtime-deps, we effectively overwrite everything that was installed in runtime-deps. Chisel cannot know that dependencies of dotnet-runtime-6.0 have already been installed so whole dependency tree is populated in /rootfs-dotnet.
In this simple example one could suggest to not base runtime image on runtime-deps image but instead build it from scratch. But more complex runtime-deps image could have something more in addition to root filesystem created by chisel, e.g.:
FROM ubuntu:22.04 as builder
RUN chisel cut --release ubuntu-22.04 --root /rootfs libc6_libs libgcc-s1_libs libstdc++6_libs \
&& echo app:x:999:999:app:/nonexistent:/nonexistent >/etc/passwd \
&& echo app:x:999: >/etc/group
FROM scratch
COPY --from=builder /rootfs /
ENV DOTNET_VERSION=6.0
Here it makes sense to base runtime image on runtime-deps image (above) because of the additional files created outside of chisel and ENV directives. (There could be also HEALTHCHECK, PORTS and other directives that we would like to inherit in runtime image.)
It'd be nice if chisel had an ability to record what has already been installed, and install only missing dependencies that were not recorded. It's a bit complicated by the fact that we execute chisel in stage container that doesn't have access to the image on top of which we want to copy new slices. But that can be solved by copying the suggested chisel metadata/database into the stage container, e.g. like this:
FROM ubuntu:22.04 as builder
COPY --from=dotnet-runtime-deps /var/lib/chisel.db /rootfs-dotnet/var/lib/chisel.db
RUN chisel cut --release ubuntu-22.04 --root /rootfs-dotnet dotnet-runtime-6.0_libs
FROM runtime-deps
COPY --from=builder /rootfs-dotnet /
Now chisel could read state of /rootfs-dotnet from /rootfs-dotnet/var/lib/chisel.db (or wherever we decide to store the metadata).
One major problem with this is that it'll probably break the assumption that scripts run in a closed world and will lead to non-determinism. Currently each chisel run creates new world from scratch and so scripts runs can be scheduled to produce deterministic output. With such split installation it would no longer hold.
Activity
[-][RFC] Store and use installed slices metadata in `--root`[/-][+][RFC] Record installed slices in `--root` and install only what's missing[/+]cjdcordeiro commentedon Aug 24, 2022
Additional piece of information wrt security monitoring:
mthalman commentedon Aug 24, 2022
I have a post which describes a workaround for this issue.
loewenstein commentedon Oct 9, 2022
#25 got closed with
Can't seem to find those smaller feature requests linked here though.
rebornplusplus commentedon Oct 3, 2024
Update: we added Chisel manifest support in #142.
lbussell commentedon Oct 4, 2024
@rebornplusplus is there an ETA for a new release with this feature?
rebornplusplus commentedon Oct 4, 2024
I don't have the exact date, but I believe it should be within the next few weeks. We are currently fine-tuning a few stuffs (#150, #159, #162) in preparation to a v1.0.0 release.
rebornplusplus commentedon Oct 9, 2024
@lbussell v1.0.0 is released!
cjdcordeiro commentedon Oct 10, 2024
Indeed, v1.0.0 is out :)
Closing this issue as:
norrisjeremy commentedon Dec 4, 2024
@rebornplusplus @cjdcordeiro Where would a user go to learn how to use this new "Chisel manifest" feature?
I'm not finding any seeing any obvious documentation and when I execute
chisel cut ...using the new 1.0.0 release, I'm not seeing any sort of manifest being generated?Am I misunderstanding how this feature should work?
cjdcordeiro commentedon Dec 4, 2024
Hi @norrisjeremy
@rebornplusplus is working on bootstrapping dedicated documentation pages for Chisel. We're hoping to get the first draft ready within the next 2 weeks.
In the meantime, the manifest is an opt-in feature that you can solicit via the
base-files_chiselslice. Just add that slice and you'll get the manifest created.This post should help you: https://discourse.ubuntu.com/t/chisel-manifest-is-supported-in-newly-released-v1-0-0/48944
norrisjeremy commentedon Dec 4, 2024
Hi @cjdcordeiro,
Excellent, thanks! Adding the
base-files_chiselslice was the missing piece of the puzzle I was looking for.Thanks,
Jeremy
polarathene commentedon Mar 13, 2025
So this opt-in slice needs to be used each time with
chisel cutto update the manifest? Was it meant to avoid writing / extracting content that was unchanged?I tried to leverage it within a
Dockerfilethat had the sameRUNtwice, and the 2nd RUN layer had the same layer weight as a result.cjdcordeiro commentedon Mar 14, 2025
@polarathene the creation of the manifest is indeed a opt-in for the time being. By being a slice-driven opt-in, it also gives users the ability to write the manifest in another path.
We still need to do some work to allow the manifests to be handled properly on consecutive
chisel cuts. It's more than just a simple "merge", so I'm afraid this capability may still take some time to land.polarathene commentedon Mar 14, 2025
That's fine, is there a tracking issue I can subscribe to?
cjdcordeiro commentedon Mar 18, 2025
Here: #208