I've been following the development of the ostree native containers pretty closely, first as a member of the CoreOS team and now as a member of the RHEL for Edge team, but never had a chance to really try it myself.
So I took a few hours here and there over the last few days to build a small project using the ostree native container functionality. I wanted to create a variant of Fedora CoreOS (FCOS) that has the Image Builder (https://www.osbuild.org/) service layered on top. I also wanted to keep the FCOS layered image up-to-date without any intervention on my part.The result is a repo that contains:
- a Butane (https://coreos.github.io/butane/) config to generate the initial Ignition (https://coreos.github.io/ignition/) config to provision a "vanilla" FCOS system
- a Containerfile that layers the Image Builder bits on top of the "vanilla" FCOS image
- a GitHub workflow to automatically build and push an updated layered image to Quay
- a hacky systemd service to rebase the "vanilla" system to the new layered image
- a hacky systemd service to check for updates to the layered image and apply it to the running system
It seems to work in testing, but I only just deployed it "for reals" today, so we'll see if the hands-off update mechanism works the way I want it.
Overall, the user experience of using a Containerfile to define customizations to the OS was really smooth for this use case. I can definitely see how I could expand this workflow to do more testing of the layered image before promoting it to the Quay registry, too.
I'm definitely looking forward to seeing how this project progresses in the future.
On Tue, Sep 27, 2022 at 6:09 PM Colin Walters <walters@xxxxxxxxxx> wrote:
We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer in Fedora 36 and a lot has happened since then.
One of the biggest things is that rpm-ostree now knows how to intelligently generate reproducible "chunked" container images.
I'll describe this by also highlighting another big change; Fedora CoreOS is now shipped as a properly manifest listed container image alongside the other Fedora images on quay.io:
https://quay.io/repository/fedora/fedora-coreos
And if you dig into the tags, on the UI, clicking through to the stable/amd64 image, check out e.g.
https://quay.io/repository/fedora/fedora-coreos/manifest/sha256:0d100d21bbe885d638de1847eeacfed7903ed5b9aec5832730d12cad0dbb6f58
Note that e.g. linux-firmware (by far the largest single chunk) is split into its own layer - and this layer is generated in a reproducible fashion (ostree canonicalizes all timestamps to zero in particular). What this means is that these images share storage on the registry and client side.
Another way to say this is that it means you get a natural "delta-like" flow; if e.g. there's a security update to podman, you only download the layer containing podman (plus a metadata layer), not everything else.
This isn't the same as more proper deltas (as e.g. ostree static deltas enable) but it has the powerful benefit of applying everywhere that Docker/OCI containers go (e.g. when you pull the image via podman/docker or Kubernetes, that *also* applies there).
You may see this effort sometimes called "CoreOS Layering" but it really has little to do with "CoreOS", and https://pagure.io/releng/issue/11047 is a ticket which proposes shipping e.g. quay.io/fedora/fedora-silverblue for example. (I know for a number of people I've talked to this idea of building your desktop as an container image server side is powerfully appealing, and this makes it real)
On that topic there's also https://bugzilla.redhat.com/show_bug.cgi?id=2125655 which shouldn't be too hard to put together.
But back to Fedora CoreOS, another thing that's happened recently is https://github.com/coreos/coreos-layering-examples has matured and has many functional examples of using this.
We're getting increasingly close to the point where I want to call this all stable, so it's a great time if you haven't to kick the tires and try it out!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
