|
|
|
|
|
by mathfailure
775 days ago
|
|
I don't understand how it works. Did I guess it right that it basically processes Containerfile and instead of producing a .tar artifact (which is what container images usually are) it produces .qcow2/.ami/.raw/.iso/.vmdk file which in case of .qcow2/.raw/.vmdk can be used by a virtualization software to start up a VM with a disk mounted from that file? Will the changes made inside a session with such a VM persist? or will they get lost (which is the default behavior with containers)? Container's filesystem may be as narrow as a single binary file, surely a VM with such a filesystem won't be able to boot - where will it take the OS (with the kernel, drivers and other stuff) from? |
|
2) you push that container image to some registry
3) you use the bootc image container to create an qcow file from the image you have built (or you install the image on a bare metal system)
4) you boot up the virtual machine or bare metal system, which now includes "bootc" utilties too
5) from this point on you can update the container image you have created in step 1) and you automatically roll forward the booted virtual machine or bare metal system to the latest image you have relased (or rollback, if your updated image breaks stuff) using the included bootc utility
Currently the image that supports this seems to be limited to centos:stream9, or rhel9:
https://www.redhat.com/en/blog/image-mode-red-hat-enterprise...