Real-world Problem: The Nightmare of “Repetitive Installations”
Last year, my team took on a project to deploy a cluster of 30 servers for a bank. The requirements were extremely strict: every server had to have an identical security configuration, a pre-installed suite of monitoring tools, all unnecessary services disabled, and it had to be a 100% offline installation.
Initially, I chose the traditional method of configuring a master template and then using Clonezilla to “clone” it. The result was terrible. As soon as the hardware generation differed, drivers would fail. Managing subsequent patches also became a heavy burden. If you’ve ever had to plug a USB drive into every single server or stay up all night running post-installation scripts for dozens of VMs, you’ll understand the urge to change careers immediately.
Why Are Old Methods Falling Short?
Practical deployment experience shows that methods like creating VM Templates or using Shell Scripts reveal many risks:
- Lack of consistency: Scripts frequently fail halfway through due to repository changes or unstable network connections.
- High maintenance overhead: Every time you need to add a package to the base installation, you almost have to start from scratch or edit an endless Kickstart file.
- Platform fragmentation: Manually maintaining 3-4 different formats for VMware, AWS, and physical machines takes triple the effort.
Reviewing Popular Current Solutions
Before finding the “perfect solution,” I threw myself into all sorts of tools:
- Kickstart: Very powerful, but the configuration files are extremely hard to read; just one missing dash can break the entire process.
- HashiCorp Packer: An excellent tool for professional DevOps, but the technical barrier and pipeline are quite complex for quick and simple needs.
- Manual Image: Installing manually and then exporting to QCOW2. This method is only suitable for scales under 5 machines and is completely unscalable.
Image Builder (osbuild-composer): A Lifesaver for Sysadmins
After 6 months of hands-on experience, I believe Image Builder is the most worthwhile tool to use on CentOS Stream 9. This is a solution inherited from RHEL that allows you to define a single “Blueprint.” From there, the system automatically exports various formats ranging from ISO and QCOW2 for KVM to AMI for AWS and VHD for Azure.
Step 1: Installing Core Components
To get started, you need to install osbuild-composer. I recommend using the Cockpit Web interface for more intuitive management, helping to reduce the need to memorize too many complex command lines.
# Install Image Builder and the Cockpit plugin
sudo dnf install -y osbuild-composer composer-cli cockpit-composer bash-completion
# Activate the services immediately
sudo systemctl enable --now osbuild-composer.socket cockpit.socket
# Load bash-completion to support command suggestions
source /etc/bash_completion.d/composer-cliStep 2: Accessing the Management Interface
If the server already has Cockpit installed, access https://<Server-IP>:9090. You will see the Image Builder item in the left menu. All operations from selecting packages to building the image will be performed here.
Step 3: Designing the Blueprint – The System “Blueprint”
A Blueprint is a definition file containing a list of packages, users, and configurations. Suppose I need to create a standard ISO for a Web Server with Docker and Vim pre-integrated.
- Select Create Blueprint and name it
web-server-base. - In the Packages section, find and add
docker-ce,vim, andgit. - In the Customizations section, add a User and paste your SSH key for remote login immediately after installation.
If you are a fan of the command line (CLI), create a blueprint.toml file with simple content like this:
name = "web-server-base"
description = "Standard installation for Web Server"
version = "0.0.1"
[[packages]]
name = "vim"
version = "*"
[customizations.services]
enabled = ["sshd"]Then, push this configuration into the system using the command:
composer-cli blueprints push blueprint.tomlStep 4: Build and Export the Final Image
This stage is fully automated. You just need to click Create Image and choose the desired output format:
- Installer ISO: Used for installing on physical machines via USB, running automatically from A-Z without intervention.
- Guest Device (QCOW2): For KVM or Proxmox. You just import it and run, skipping the time-consuming OS installation step.
The build process usually takes 5-10 minutes. The system will automatically download packages from the official repos, so the speed depends on your internet connection.
Important Notes to Avoid Pitfalls
Here are a few real-world experiences to help you save hours of debugging:
- Check Repositories: Image Builder can only fetch packages from active repositories. To install Docker, you must add the Docker repo to CentOS first.
- Disk Space: The build process is very storage-intensive at
/var/lib/osbuild-composer. Ensure the/varpartition has at least 20GB of free space. - Read logs when errors occur: If the status reports Fail, use the command
composer-cli compose log <UUID>. The logs here are very detailed and will usually point out which dependency you are missing.
Using Image Builder makes the deployment process significantly more professional and effortless. Instead of spending 2 hours configuring each server, it now takes only a few minutes to have a 100% accurate installation image. If you are running CentOS Stream 9, try this tool immediately to upgrade your workflow.
