Open cgwalters opened 3 years ago
One thing that came up is taking a container built using Dockerfile or equivalent, and having support for "cleaning it up", specifically by doing things like reproducible chunking. If we go this route, it'd also make sense to do the other things like SELinux labeling at that time too. xref https://github.com/ostreedev/ostree-rs-ext/issues/388
I could imagine having something like ostree container commit --from-image=quay.io/user/example:latest --content-mapping map.toml
where map.toml
is something that specifies a set of file paths mapping to a "chunk" or so.
I think we want two things:
ostree container image pull
and then you have an ostree commit. We could document this, but perhaps one would want to be in control of the ref, so it could be a separate verbThe second tool in particular would be a really useful way to avoid the need to RUN ostree container commit
(it's more in the domain of https://github.com/ostreedev/ostree-rs-ext/issues/388 )
As further musing related to my comment over here, would it be better to create something like ostree container image ingest
that functioned similar to ... pull
but did things like selinux relabelling and allowed you to specify a ref for the result?
@jeamland Yes - it'd be relatively straightforward to create a new command like ostree container image commit
which took a container image as input, performed labeling and other cleanup, and output a new container image.
It's basically moving to build time what we do on the client side today in store.rs
.
The core tradeoff is that there's another magic step needed before "push to registry" and shipping to client systems, but I suspect that wouldn't be very onerous for many places.
There's nothing conceptually stopping us from having tooling that takes a current container image (e.g. what's in
debian:stable
) and just makes it "ostree ready". Or even just dyanamically accepting a container image that has a kernel client side.This may be in scope at some point in the future.