Skip to content

Latest commit

 

History

History
277 lines (197 loc) · 8.23 KB

image-builder.adoc

File metadata and controls

277 lines (197 loc) · 8.23 KB

Image Builder

1. Overview

When installing Red Hat Enterprise Linux from scratch, the traditional methods are:

  • Use the DVD ISO

  • Use the BOOT ISO with network accessible repos

  • Use the pre-built KVM Guest images (qcow2)

Leveraging additional tools and services (ie: pxe, dhcp, kickstart, ansible automation, ipmi, redfish, etc…​) the process can be heavily automated and turned into a completely hands-free task. We have doing this for decades.

Starting with Red Hat Enterprise Linux 8, now there is a new method for creating RHEL images to add to your toolbox: Image Builder.

Image Builder is a collection of tools that create custom RHEL images in a variety of formats for compatibility with major cloud providers and virtualization technologies. Meaning, you can design an OS blueprint and then specify the target platfrom to create an appropriate image (ie: VMWare, AWS, Openstack, KVM, etc…​).

As of Red Hat Enterprise Linux 8.3, the osbuild-composer backend replaces lorax-composer and provides more reliable backend and more predictable output images.
ℹ️
Cross-distribution image building, such as building a CentOS image on RHEL is not supported.
ℹ️
You CAN create images of multiple RHEL minor releases that are different from the host (ex: RHEL 8.4, RHEL 8.5) with osbuild-composer but to doing so requires additional repo configurations which are not available in this workshop environment.
ℹ️
Internet connectivity is not a prerequisite, however Image Builder is configured to connect to Red Hat CDN by default and must modified to work in an isolated environment or when connected to a Red Hat Satellite server.

2. Installation and Configuration

ℹ️
Please note that all software has been pre-installed and configured. These steps are provided as reference material only.

As mentioned above, when RHEL 8.3 was released the Image Builder backend was replaced with another toolset called 'osbuild'. At the time of the design and validation of this lab, the feature set and configuration options of 'osbuild' are not compatible with this workshop environment. Thus, we will stick with the lorax backend for now but other than the installation and setup the operational commands remain the same.

To prevent possible installation conflicts (overrides), we specifically exclude 'osbuild' components when installing the lorax-composer.

yum install --exclude=osbuild* -y lorax-composer composer-cli

Ensure everything is stopped.

systemctl stop lorax-composer.socket

Next we need to enable and start the lorax-composer.socket service

systemctl enable --now lorax-composer.socket

Finally check the service status.

systemctl status lorax-composer.socket

3. Create a Blueprint

Blueprints are defined by a TOML configuration file. A sample has been provided to get us started with a very basic definition.

cat /usr/local/etc/imagebuilder-sample.toml
name = "sample-webserver"
description = "standard apache httpd webserver"
version = "0.0.1"

[customizations.services]
enabled = ["httpd"]

[[modules]]
version = "2.4.*"
name = "httpd"

[[modules]]
version = "2.4.*"
name = "mod_ssl"

[[packages]]
version = "*"
name = "openssh-server"

[[packages]]
version = "*"
name = "rsync"

Looking over the bludprint, it should be apparent that this image blueprint builds on a standard RHEL base by:

  • enabling the httpd service

  • adding a few packages

Now we need to push the blueprint to our image builder catalog.

composer-cli blueprints push /usr/local/etc/imagebuilder-sample.toml

4. List Blueprints

composer-cli blueprints list
example-atlas
example-development
example-http-server
sample-webserver

A nice quick way to determine if the local Image Builder can resolve all dependencies for the blueprint is to run it thorugh a depsolve. Here you can also see a full list of rpms that will be installed on the image.

composer-cli blueprints depsolve sample-webserver

If everything is in order, you output should look something like this.

blueprint: sample-webserver v0.0.1
    acl-2.2.53-1.el8.x86_64
    audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64
    basesystem-11-5.el8.noarch
    bash-4.4.19-14.el8.x86_64
    brotli-1.0.6-3.el8.x86_64
    bzip2-libs-1.0.6-26.el8.x86_64
    ca-certificates-2020.2.41-80.0.el8_2.noarch
    chkconfig-1.13-2.el8.x86_64
    coreutils-8.30-8.el8.x86_64
...SNIP...

If you see errors or packages that can not be resolved, this is likely a problem with the osbuild repo configuration(s). Let your instructor know and hopefully this can be fixed.

5. Compose a Blueprint

We are now ready to compose the blueprint into an image.

composer-cli compose start sample-webserver qcow2
Compose 812019dd-20e5-4528-a99b-09fbe47ca2d8 added to the queue
composer-cli compose status
composer-cli compose list
812019dd-20e5-4528-a99b-09fbe47ca2d8 FINISHED sample-webserver 0.0.1 qcow2

It may take a few minutes, but eventually you should see a "FINISHED" status

6. Retrieve the QCOW Image

We need to grab a copy of the image and put it in the right place for our platform.

cd /var/lib/libvirt/images

Take a moment to identify the UUID of the created image.

composer-cli compose list
812019dd-20e5-4528-a99b-09fbe47ca2d8 FINISHED sample-webserver 0.0.1 qcow2

Here is a helpful way to store the last FINISHED image UUID to an environment variable.

export IMAGE_UUID=$(composer-cli compose list | grep -m 1 FINISHED | awk '{print $1}')

Now use the UUID from your ouput to extract the QCOW image.

composer-cli compose image $IMAGE_UUID

Finally you can rename it to something a little more convinient

mv $IMAGE_UUID-disk.qcow2 vmguest.qcow2

7. Conclusion

Minus a few customizations, your image is now ready for deployment.

The next unit covers the native virtualization technology included with RHEL and will utilize this image to deploy the sample-webserver.

8. Additional Resources