Name: From Container to Bare-Metal: Redefining OS Build with bootc
Uploaded: 2025-08-20T17:01:05.468Z
Duration: 7 min 51 s
Description: From Container to Bare-Metal: Redefining OS Build with bootc

Transcript for "From Container to Bare-Metal: Redefining OS Build with bootc": to Chainguard in container with Trust TikTok. Today, I'm gonna be talking about from container to bare metal, redefining OSB with with we'll see. My name is. I'm currently head of technology platform at BB Bank Vietnam. Technology platform is the team responsible for platform engineering, cloud platform, container, Kubernetes. We're also working on developer experience and a bit of security related to things. First of all, let me share with you a bit about context, the problem that we're having with traditional CB batching method. So first one, we do quarterly scan. Every quarter, our security team will conduct, security scan bank wide. The system owner, they are usually receiving reports of, like, tens of thousand CVE each time. They have also sold the hassle with our on premises setup. So whenever we do patching, we need to inform the infra operation team, ask them to create snapshot first, and then we perform the perform the patching. If something goes wrong, we ask the infra team to restore the backup for us. The third problem is that the mutable system, they are very hard to maintain. There's no atomic upgrade run back. And because of that, the system owner, they are usually very afraid to upgrade, you know, and they only upgrade it when they must have to, which is when the security team come knock the door. There's also a problem with the configuration drift and etcetera. Our wallop, they're they're currently spreading on both our data center and public clouds. So whatever solution that we choose, it has to work on clouds and on our own data center. We are gradually moving toward container, but the majority of the legacy system are still on virtual machine. The CVE problem on the container side is a lot easier, and we're currently using Chainguard container, the managed service from Chainguard for that. But for the VM one, it's still an open problem for us. So our previous previously, we were using HashiCorp Parker with Ansible to view our Google image, and it's very slow. It's usually taking about twenty to thirty minutes each view for each OS. If you are familiar with Parker, the way it work is like this. It will spin up a new virtual machine, a new VC two, and then as well, we do the hardening and other configuration, and then they snap sorted it. And it's very hard to extend. You have to be familiar with Ansible. And the pilot is not exactly easy. That's also the limitation with our operation setup, then where we need to inform the infra team for for the patching process. And it usually take time to push the update downstream. So we set the goal. We want to fix this problem once and for so the ultimate goal we want to to achieve is to eliminate the need for improving infra team. So, ideally, the system owner, they should be able to do it by their own. They should be able to do it safely, and they should be able to roll back, with confidence. We prefer to continue with Red Hat if possible, and we prefer to build a minimum image and extend from there the very same principle that we have with the content image. It should be easy to run back. It should view faster so that we can review more often, maybe even daily. And we would like to be able to push new data stream as soon as possible, maybe even automate it. So boot table container to the rescue. It's a new technology that allow the OCI container to encompass a complete operating system. The OCI container that you, usually know about, they consist of the base image and your operation on top of it. There's usually no kernel, no bullloader so that you can boot it. You can use it on bare metal. But the boot, the bootable container is a new one that encompass the whole thing, the complete operating system. The support is supporting to multiple output format, q code, raw, ISO, VMDK, AMI. You can use it on public cloud. You can use it on premises with VMware. The interesting bit about this one, this technology, is that they allow you to extend by writing Dockerfile, which everyone already familiar with. They are immutable, so we can run back easily with a single command. It also be a lot faster than Tucker and Ansible, and because of that, we could we are able to review very often when the new CPU arrives. So the the fact that bootable container are immutable, very easy to restore the OS back to the previously working stage. So if you want to update, you do boot c switch and then the image name. And if you want to run back, you type in boot c run back. Right? So the the way it work is just like imagine they are trying to swap the the operating system for you underneath. Red Hat also provide a booty effect apply a based, service if you want to enable up auto update if you want. So how do you get started from there? It's very easy. Just Dockerfile as in the image that we have in here. And what we have to do what you have to do is just you change the base image to bootable container image variant. In our case, we change it to the Red Hat version. You can view your own tool if you want. And the rest of that file is, they are typical Docker instruction. Very easy. So, the process before and after we adopt portable container, so the patching process is a lot easier. We don't have to inflow in file processing anymore. The system owner, they can just, use the Boosty CUI to operate it manually if they want. And if something goes wrong, they can just type in Boosty run by. We can even automate update it if we want. The patching frequency is a lot more frequent. Previously, we do it quarterly, but now we can do it monthly on production and even daily on non production. It also a lot easier to extend. We, the technology platform team, we maintain a repository, where we manage all the image, the good image for every team. If they want to create a new variant, they just have to open a more request, create a new folder, add their own Docker file, and then maybe even extend from our minimum one, and our pipeline will pick it up from there. Very easy. There are a few things to keep in mind as well because, you know, you're trending from mutable west to the mutable one. So ETC, they contain mutable persistent state by default. So, usually, e t ETC, they have, like, small configuration file you have in there. Another part that also persists by default is bar because, remember, bar may have, like, arbitrary large data. For example, if you progress, right, progress data usually stay in valid progress. So they they persist by default, though, so you can proceed your your database when you upgrade. So the result, we were able to achieve most of the goal that we originally set out to accomplish. There's no minimum version from Red Hat as of this talk yet. If you want to be a minimum person, you have to rip our stuff by yourself. Red Hat said that they are working on it. They will provide a minimum version later. And that's it for my talk. If you have many, any feedback, my email is right there. I'm also available on LinkedIn. Thank.