Subscribe to the feed

I remember when I carried around a set of DVDs with different operating system disks. Eventually, that became a stack of flash drives with the installers. Nowadays, I don't need to worry about that as much because I utilize the Red Hat Enterprise Linux (RHEL) image builder tool to manage my operating system lifecycle.

You've heard us talk a lot about the future of RHEL and the installation experience. Overhauling your server lifecycle process may as well start at the very beginning with image creation. Image builder supports multiple formats and destinations.

So, how do you decide which tool to use? What formats should you keep updated? Let's break it down step-by-step:

Steps for using RHEL image builder

1) Choose a platform

Before you start deciding what packages to install or how many gigabytes to make your /tmp partition, you need to ask yourself a few questions.

The main question is: Where will this workload be run? Physical, public or private cloud, or edge?

  • Is this for a data warehouse running on a storage-dense physical server?
  • Is this an IoT collection point on a light pole somewhere?
  • Is this a Word Press site with minimal resource requirements running on AWS?

The answer to these questions will help you through the first step. Which platform will my workload run on? From here, you can correctly provision users' accounts for the cloud or bare metal servers.

2) Select your image builder tool

Select your RHEL image builder tool

Now that you know what your workload is and what the platform will be, you can choose which of the two tools to use:

Technically, there are three tools: the service, the private web UI and the private command line tool. How do you decide?

If you plan on a public, multicloud deployment, it will make sense to take advantage of the service. However, if you are 100% on-premises, why not use the on-prem tool?

One caveat: The service tends to get new features faster because the on-premise tools are only updated during minor RHEL releases (every six months).

3) Create a blueprint

Now that you know the what and the where, it is time to start building a blueprint. This process varies considerably based on your needs. Here is the basic rundown:

First, choose your destination(s).

RHEL image builder: select the target destination(s)

Second, configure your system registration and enable Red Hat Insights.

RHEL image builder: configure your system registration and enable Red Hat Insights

Next, define your file system layout.

RHEL image builder: define your file system layout

Then, select some packages.

RHEL image builder: select some packages

Finally, give your template a name, and you’ll be ready to start building.

RHEL image builder: give your template a name

4) Build your image

Now that you have a blueprint defined, you can create images across various platforms. The best part is that these images will be virtually identical!

Image builder supports a variety of image types from cloud templates (for instance, AMIs on Amazon) to private clouds (like VMDKs for VMware), and Linux-specific formats (IE qcow2 or ISO installer).

You can schedule multiple formats to be built in parallel, ensuring that all your golden images are identical.

RHEL image builder: build your image

5) Deploy your instance

You've got the blueprints and the destination—now it's time to deploy. This could mean uploading the vmdk file to your ESX host, the qcow2 file to a Linux file server for deployment as virtual machines, or copying over a GCP image into your organization on Google's cloud.

These templates can be used as one-offs or as the basis for thousands of identical servers!

Extra credit

Imagine taking this process to the next level: Automate the builds. The image builder service has an API that you could make scripted, scheduled calls on a daily, monthly or quarterly basis—whatever meets your needs. Like any other sysadmin tool, the command line can easily be scripted via cron or run regularly by an operations team.

Automating image builder tasks ensures that not only are your images identical across multiple platforms, but it also makes sure that they receive the latest updates and don't end up stale.

Wrap up

Following these five steps, you can tackle one of the most frustrating projects a systems administrator deals with: defining and maintaining images across disparate and disconnected environments. 

Stay tuned for more content around golden images right here on the Red Hat Enterprise Linux blog. Interested in digging deeper? Check out the Enable SysAdmin blog for hands-on tutorials!

About the author

Eric "The IT Guy" Hendricks is a Technical Marketing Manager for Red Hat Enterprise Linux, as well as the host of "Red Hat Enterprise Linux Presents," a podcaster, and open source advocate. Hendricks started out in 2007 as a Systems Administrator specializing in Linux before moving into technical marketing.
Read full bio

Browse by channel

automation icon


The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon


The latest on the world’s leading enterprise Linux platform

application development icon


Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech