-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for bootc install --with-overlay quay.io/exampleuser/someoverlay:latest
#190
Comments
I think what would also help a lot here is integrated "factory reset" support. The baseline implementation of this idea would be like kickstart - unpacked and applied at install time - it persists but the "original" input is not referenced thereafter or tracked. But taking it one step up, we could easily also record the reference to the input, and add a This would get us really close to a "immutable infrastructure but with easy in-operating system reprovisioning" flow. |
Would make a nice demo as well 👍 |
Another thing we could consider by default is treating things as if we had This would certainly unblock a lot of "obvious" flows like I have a bit of a fear it'd lead to confusion down the line, but it could probably be overcome with docs. And probably some sort of command to "re-synchronize"? Like |
Interesting idea on |
I think the base image needs to have a bunch of VOLUME and CMD added Specifically VOLUME /var and VOLUME /var/roothome and /var/home. 'CMD /sbin/init' Since the goal is to run/test images based on the base images as OCI containers we need to ensure that they work easily when run with --privileged mode. |
@cgwalters What's the plan with this one? After we switch to |
In the short term...today implicitly in a
Thinking about this a bit more if we constrain things such that we're just doing things in By far the biggest thing here that this pushes towards is an architecture where For the bib case, this configuration may not be desirable in a registry. Putting this all together, we could just add |
PR in #267 |
One thing I noticed while looking at this is currently Having the /etc writes done via bootc keeps things consistent there. |
Right now the b-i-b case is really just scoped to users, correct? (Obviously Anaconda and That's so tiny that I wonder if we aim to do a general mechanism right now (i.e. "write arbitrary files") versus just chaining together a Man, SSH keys are a messy topic...while thinking about this I did CentOS/centos-bootc#154 which would notably break with what b-i-b is doing today, but work very nicely if we setup the keys via systemd This topic of SSH keys also tangentially relates to things we could do by default with |
The ergonomics around glomming together sysusers.d and tmpfiles.d are pretty low though...we could support something like |
I think it would be extremely desirable if the references could be tracked and subsequently manageable separately (as in removed and updated) from the underlying OS image. This would allow instance specific configuration info to be nicely buildable and manageable and also separating the instance "state" from the runtime environment. |
I've been advocating general configmap and secret support for a while.
However, the way CoreOS does things today with Ignition is basically allowing the admin to inject "day 1 unmanaged state" that is decoupled from the image/host. And actually, that's how Anaconda kickstart works too.
There's a lot of advantages to configmap-in-registry around supporting "day 2" changes too. However, it will require workflow and tooling changes to adapt.
One key thing I'm narrowing in on is the basic use case of "inject a ssh key into an existing golden image" - a thing I think we really want to support. And we do today via e.g. Anaconda or other installers.
But I think we should support this more natively via
bootc install
too.So here's my strawman: the
--with-overlay
argument takes a container image reference and operates only at install time. A very key difference from the configmap approach is that the image must drop files into/etc
and/var
. This gives us immediate, direct support for SSH keys by injecting e.g./var/roothome/.ssh/authorized_keys
.Migrating from Ignition
But actually the neat thing with this is it provides a very seamless adaptation of existing Ignition configuration! We've already prototyped out support for extracting an Ignition configuration to its set of files via
ignition-apply
, so it'd literally look like:Then push that to a registry as
quay.io/exampleuser/someoverlay:latest
, and one can dobootc install --with-overlay quay.io/exampleuser/someoverlay:latest
and then one can switch to installing via bootc without needing to change all the bits in the Ignition config to move to/usr
content etc.So any tools (e.g. OpenShift MCO) that act on "day 2" management for this "unmanaged state" can seamlessly continue to work - but we avoid the need to e.g. host Ignition servers.
The text was updated successfully, but these errors were encountered: