-
Notifications
You must be signed in to change notification settings - Fork 204
-
Again, proxying a question asked in a live chat:
Is there a way to change a Bootc enabled machine to a traditional dnf enabled machine?
Use case, I have an offline environment of a few CentOS machines that’s using DNF mirrors for updates. We don’t have capacity to upgrade the infrastructure to support Bootc... yet, but soon
As an interim option we’re looking to see if we can leverage the IaC & GitOps etc benefits that Bootc provides to build and deploy the machines, but change to traditional ways to maintain them. I know this can be done with a number of tools like Packer, but we’re invested in Bootc & the containers ecosystem and would rather have an interim solution before we move to full Bootc in the next 12/24 months.
Beta Was this translation helpful? Give feedback.
All reactions
This came up in a RHT internal discussion a while back. It would be possible yes...however, did you investigate setting transient root? https://containers.github.io/bootc/filesystem.html#enabling-transient-root If you don't need dnf upgrade kernel and such to persist across reboot, then I think one can get pretty far at letting usual ansible/chef style workflows to operate. One thing some people do is embed ansible playbooks (or equivalent) in their image, that run on first boot each time. This can be a useful stepping stone - move the config management you can to build time, keep the stuff that needs runtime specific config (e.g. something parsing MAC addresses or contacting an inventory...
Replies: 2 comments 2 replies
-
This came up in a RHT internal discussion a while back. It would be possible yes...however, did you investigate setting transient root? https://containers.github.io/bootc/filesystem.html#enabling-transient-root If you don't need dnf upgrade kernel and such to persist across reboot, then I think one can get pretty far at letting usual ansible/chef style workflows to operate. One thing some people do is embed ansible playbooks (or equivalent) in their image, that run on first boot each time. This can be a useful stepping stone - move the config management you can to build time, keep the stuff that needs runtime specific config (e.g. something parsing MAC addresses or contacting an inventory server) at runtime.
Beta Was this translation helpful? Give feedback.
All reactions
-
That said, we could add a mode to bootc install where it just unpacks the container into the root filesystem as is - no ostree stuff, and everything would be writable at runtime etc. This would mean dnf|apt upgrade would Just Work, etc.
Only a few bits of bootc would be used here; mostly the bootloader writing parts, etc. It'd basically be the bootc install parts.
It honestly would likely be relatively straightforward to do. It's just more the longer term cost of supporting it and adding another option into our already complex matrix.
My hope is that transient root provides enough of a bridge for people who want this today instead.
Beta Was this translation helpful? Give feedback.
All reactions
-
Thanks for the response Colin.
We have looked at the root/etc transients, but I don't think they meet the requirement for these use cases. The limiting factor is enabling infrastructure i.e the ability to do out of bands updates. DNF mirrors and the assurance of the packages is mature in most ops processes, whereas the equivalnent for OCI images isnt there yet. Having a feature like this will allow teams utilise the common bootc patterns for developing, building, maintaining (and so on) the OS images but with the ability to deploy them on exisiting (traditional) infrastructure.
Beta Was this translation helpful? Give feedback.
All reactions
-
By the way, I'd be very interested in this feature. I think it would be useful. How I would use it at least is everytime a new Fedora release came out, I would "bootc install" the new version of Fedora, but in between that, I'd probably do "make install"
s hacky developer-type things I like doing to test stuff (and I generally still want those hacks to persist across reboot). But everynow and then I would "bootc install" a clean system (probably at least between Fedora releases).
There's some things that are just easier to develop and test for on a persistent mutable system. But the ability to clean up your system with a pre-defined Containerfile and a "bootc install" would be neat...
It gives a user complete control of when they want a clean system vs a system with hacks (and reboots not getting in the way of that auto-cleaning up transient roots, etc.).
I remember for a very brief time, I used to keep personal install scripts for myself for new systems (and anyone who's tried to do this, probably realises it's not worth it, because as the months go buy, things change). Containerfiles are much better than that because at least you can do a build-time tests via "podman build" before the script actually effects your running host system.
Beta Was this translation helpful? Give feedback.