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. Code can be found here - https://github.com/miabbott/fcos-image-builder 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 <walt...@verbum.org> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
