I’m building a custom CoreOS derivative using coreos-assembler. However, I have no idea how to provide Over-The-Air updates to instances running that derivative.
I’m getting a bunch of output files from the build, mainly an ostree OCI-archive which I have no idea what to do with. I do not want to rpm-ostree rebase a provisioned system - this is related to this question.. I’d prefer a classic non-OCI-approach as it’s still used by current releases of Fedora CoreOS.
I am following this article but at the time of writing, the build created other output files instead of the OCI archive. However, nowadays it seems the OCI archive is the new standard way of publishing ostrees - but only in some places of the rpm-ostree/ostree/CoreOS documentation. Unfortunately, it’s hard to wrap your head around these many documentations which lack certain aspects to the point it’s frustrating and discouraging to spend more time guessing.
That said, is there an official way of distributing updates to (custom coreos-assemblered) CoreOS instances, without having to rebase (and/or without OCI images?).
Easiest is to just take and push the output ociarchive to a container registry. Once your systems have been rebased to follow that registry:tag then an sudo rpm-ostree upgrade will just work.
When you get an answer to your other question then out of the box the systems will follow that registry:tag.
Unfortunately the rpm-ostree upgrade is manual (unless you automate it). If you want highly controlled updates you’d try to figure out how to run your own cincinnati update server and point zincati at that server.
I didn’t know that zincati needs a cincinnati server. So even if went the traditional way of hosting my own rpm-ostree remote, am I right that this would prevent automatic updates from happening as I would also have to host a cincinnati update server?
a service knows about the update and applies the update
When we are talking about OCI versus OSTree it only covers part 1.. For part 2. Fedora CoreOS maintains an update graph (see fedora-coreos-streams/updates/stable.json at main · coreos/fedora-coreos-streams · GitHub for an example of how the update graph is defined) that let’s the client know the best path to take from point A to point F. So part 2. could be covered by zincati + cincinnati or it could be covered by just scripting an rpm-ostree upgrade on a timer.
When you start building your own OSTree you also own your updates. You could make it as simple or as complex as you like.
I’m not sure if this covers your use case, but Jorge Castro has worked quite a bit on customizing Fedora ostree variants, and that includes a toolkit and GitHub workflows to set this up for automatic updates from a container registry:
In particular, they have a base config for CoreOS (with additions) already: