I started playing around with the container-native version of Kinoite and am very excited about the possibilities of this change to rpm-ostree. I am particularly excited about the prospect of easily creating custom images, layering in custom configurations and packages on top of the official OS container image.
As simple example, I’ve written a custom Containerfile that uses the base Quay.io Kinoite 37 image, RUNs rpm-ostree install to install some extra packages and ADDs some configuration files to the image. I’ve pushed this custom image to my own quay.io repository and have successfully rebased to it.
The trouble I’m finding is how to trigger a new custom build when a new official image is published. I’m wondering if this kind of use case is going to be considered, and if so will there be (or is there already) a way to trigger these kinds of custom builds?
I suppose this will be most/only beneficial to circumstances where Silverblue/Kinoite is going to be installed on a large number of machines that need the same configuration. I can see how this would be a pretty niche usecase.
You can just write a script that pulls the latest image, execute Dockerfile and push the result image into your repository and put in the cron to execute e.g once a day or once a week, how often you prefer to update your system. The Infrastructure that builds the base image works in the same way.
These images are intresting but I prefer to customize my system using package layering, it still works and is less complex.
You’d probably want to set up something like a Jenkins server somewhere to monitor the base image, and then rebuild your image and push it to Quay whenever the base image updates. You can also look at Gitlab CI / CD or Github Actions to also do this for you.
Yes indeed, and I’ve written the script to do it already. I was hoping there would be a way to trigger it though without resorting to a cron/timer and instead base it off of whenever the base image is updated. I just have the feeling that schedules are less optimal/efficient, though I suppose it would work fine.
Package layering works, of course. But I have 3 Kinoite machines currently and they all pretty much have the same configuration and I like to keep them more or less the same. I was thinking that with custom images, I can make the change in one place and the changes would propagate automatically to all machines with the next rpm-ostree update.
I can also see the usefulness of this if Silverblue/Kinoite become popular for institutional/educational deployments where systems would need to be synchronized. Having to run a rpm-ostree command on every machine would be a bigger undertaking when there are potentially hundreds of machines involved.
Thanks for sharing your experience, do you mind sharing your dockerfile somewhere? I’m planning on doing this myself with a github action to see how it goes!
I have the containerfile available in a GitHub repo (link below). It also has a mechanism for triggering new builds in quay.io. Although it works, it’s a real hack job and would really benefit from an “official” build trigger.
I took that idea for updating the container regularly and make a custom FCOS build using the ostree native containers to layer on an Image Builder install. The image is updated weekly and pushed to quay.io
The more I play with this the more I am thinking the opposite direction, it commoditizes custom builds!
I had been struggling with getting ostree-pitti-workstation going because I had never used anything like that before. Now I can reuse all my existing cloud knowledge (and existing documentation!) all the way to my client. My image built on the first try and I haven’t written a dockerfile in years. I’m looking forward to seeing how people customize stuff.
Follow on question for the folks working on this (If I should split this into a new topic please let me know):
I’m thinking if someone did a:
FROM silverblue:37
RUN "install rpmfusion and nvidia drivers"
And then just published the image, would that work how I would expect it to? Am I correct in assuming that if there was skew in whatever the nvidia driver and the kernel are would just result in a failed CI build, there wouldn’t need to have any of this ever hit my client, it would just stay on the last working build?
Also are there any limitations to what I can put in there? What happens if I slurp in a random ansible “set up my desktop” playbook? (Sorry been on the road with spotty internet so haven’t had a chance to go as deep as I’d like just yet!)
But not every input (mostly RPM) to those images change every day. rpm-ostree compose image (what we are/should be using to generate base images) has correct change detection.
Inspired by Jorges stuff I also tried this and it works nicely (this from a guy that has never even touched docker etc).
One thing I am having problems is using a specific “custom kernel” for my Asus laptop.
For this specific model to get all the “bells and whistles” working, I would need to use this kernel: lukenukem/asus-kernel Copr until 6.1 lands in near future.
I have been trying to look at the layering example for replacing the kernel. I can get the image to build fine on github but after ostree update, I get stuck in a black screen during boot.
I have used these commands previously to replace the kernel in “normal” Silverblue:
