Flock 2024 Bootable Containers A deep dive into image based OS

This talk will cover all of the concepts of bootable containers. Will talk about bootc containers, Podman Desktop Features. Ai Lab Recipes and other features to enable building complex machine servers via containerfile workflow.
This talk was originally presented at Flock 2024 in Rochester, NY by Dan Walsh.
You can view the details of this talk at: cfp.fedoraproj...
The full conference schedule can be viewed at: cfp.fedoraproj...
Other Flock talks can be found in the playlist: • Flock 2024 Talks
To learn more about Flock, visit the Conference Website: flocktofedora.org
---
🖥️ Download your favorite Fedora edition now:
fedoraproject....
🫂 Become a part of the Fedora community:
docs.fedorapro...
#fedora #linux #flocktofedora

[@Elektron1c97]

31:48 I think this is also the question what I'm mostly interested in. From my point of view, if you wanna get rid of the whole 'day 1 vs day 2' thing you'd have to be okay to push out a new image and upgrade all the hosts.
In a kubernetes environment that would make sense as you can schedule the nodes to reboot without impacting the actual workload. But if you're gonna allow drift you're still gonna run a config management like ansible or puppet in some way to have the transient change be applied.
So I would love to know how people especially in datacenters handle this, do they build the base image and then manage the config on it using a config management. Or do they build an image for each specific host that inherits from the base image, but then yet again you will need to reboot to have the actual config applied from your image.
I absolutely love the ideas and work that they put into this. I'm just seeing this work very well for containerized workloads, but not for legacy type applications without having a config management still in place.

[@stemid85]

If the registry is updated with a new image and automatic updates are disabled in the server for change management purposes for example, then all you need to do is trigger a reboot. In a DC you can simply use Ansible to trigger reboots across groups of hosts.

[@Elektron1c97]

@@stemid85 I think my key point is: You still have day 1 vs day 2. It feels like it's gonna be less like base OS config drift especially looking at the atomic ways. But to me, this mostly improves handling of updates (similar to CoreOS) but it won't get rid of your config management at the end of the day. Which is fine? Especially looking at older types of servers that have some legacy app running that won't be containerized.
For container only hosts (especially Kubernetes), you could probably get away with only using the image to configure each host (from IPs to authentication, everything) and just booting the nodes everytime you want to change configs.

[@pylotlight]

neat

[@pylotlight]

Really must mention how bad the audio is tho.. come on guys, for a room full of IT leaders, surely someone can figure out a better AV setup.

[@fedora]

Thank you for the feedback. We are always working to improve.