Chapter 11. Pushing a container to a registry and embedding it into an image


With RHEL image builder, you can build security hardened images using the OpenSCAP tool. You can take advantage of the support for container customization in the blueprints to create a container and embed it directly into the image you create.

To embed a container from registry.access.redhat.com registry, you must add a container customization to your blueprint. RHEL image builder pulls the container during the image build and stores the container into the image. The default local container storage location depends on the image type, so that all support container-tools, such as Podman, are able to work with it.

Prerequisites

  • You have created a blueprint.

Procedure

  • Customize your blueprint with the container :
[[containers]]
source = "registry.access.redhat.com/ubi10/ubi:latest"
name =  "_<local_name>_"
tls-verify = true
Copy to Clipboard Toggle word wrap
  • source - Mandatory field. It is a reference to the container image at a registry. This example uses the registry.access.redhat.com registry. You can specify a tag version. The default tag version is latest.
  • name - The name of the container in the local registry.
  • tls-verify - Boolean field. The tls-verify boolean field controls the transport layer security. The default value is true.

    To access protected container resources, you can use a containers-auth.json file.

11.2. The Container registry credentials

The osbuild-worker@.service is a template service that can start multiple service instances. By default, the osbuild-composer service always starts with only one local osbuild-worker, specifically osbuild-worker@1.service. The osbuild-worker service is responsible for the communication with the container registry.

Prerequisites

  • Access to quay.io registry. This example uses the quay.io container registry as a target registry, but you can use a container registry of your choice.

Procedure

  1. Enable the service by setting up the /etc/osbuild-worker/osbuild-worker.toml configuration file.
  2. Restart the osbuild-worker service, because it reads the /etc/osbuild-worker/osbuild-worker.toml configuration file only once, during the osbuild-worker service start.

    $ systemctl restart osbuild-worker@*
    Copy to Clipboard Toggle word wrap
  3. Optional: To stop the service instance, restart the systemd service:

    $ systemctl restart osbuild-worker@*
    Copy to Clipboard Toggle word wrap

    With that, you restart all the started instances of osbuild-worker, specifically osbuild-worker@1.service, the only service that might be running.

  4. In the /etc/osbuild-worker/osbuild-worker.toml configuration file, locate in the containers section the auth_field_path entry that is a string referring to a path of a containers-auth.json file and used to access protected resources. The container registry credentials are only used to pull a container image from a registry, when embedding the container into the image. For example:

    [containers]
    auth_file_path = "/etc/osbuild-worker/containers-auth.json"
    Copy to Clipboard Toggle word wrap

You can push container artifacts, such as RHEL for Edge container images directly, directly to a container registry after you build it, by using the RHEL image builder CLI.

Prerequisites

  • Access to quay.io registry. This example uses the quay.io container registry as a target registry, but you can use a container registry of your choice.

Procedure

  1. Set up a registry-config.toml file to select the container provider. The credentials are optional.

    provider = "<container_provider>"
    [settings]
    tls_verify = false
    username = "<admin>"
    password = "<your_password>"
    Copy to Clipboard Toggle word wrap
  2. Create a blueprint in the .toml format. This is a blueprint for the container in which you install an nginx package into the blueprint.

    name = "simple-container"
    description = "Simple RHEL container"
    version = "0.0.1"
    [[packages]]
    name = "nginx"
    version = "*"
    Copy to Clipboard Toggle word wrap
  3. Push the blueprint:

    # composer-cli blueprints push blueprint.toml
    Copy to Clipboard Toggle word wrap
  4. Build the container image, by passing the registry and the repository to the composer-cli tool as arguments.

    # composer-cli compose start simple-container container "quay.io:8080/osbuild/repository" registry-config.toml
    Copy to Clipboard Toggle word wrap
    • simple-container is the blueprint name.
    • container is the image type.
    • quay.io:8080/osbuild/repository is the target registry, osbuild is the organization and repository is the location to push the container when it finishes building. Optionally, you can set a tag. If you do not set a value for :tag, it uses the :latest tag by default.

      Note

      Building the container image takes time because of resolving dependencies of the customized packages.

  5. After the image build finishes, the container you created is available in quay.io.

Verification

  1. Open quay.io. and click Repository Tags. You can see details about the container you created, such as:

    • Last modified
    • Image size
    • The manifest ID that you can copy to the clipboard.
  2. Copy the manifest ID value to build the image in which you want to embed a container.

After you have created the container image, you can build your customized image and pull the container image into it. For that, you must specify a container customization in the blueprint, and the container name for the final image. During the build process, the container image is fetched and placed in the local Podman container storage.

Prerequisites

Procedure

  1. Create a blueprint to build a qcow2 image. The blueprint must contain the [[containers]] customization.

    name = "image"
    description = "A qcow2 image with a container"
    version = "0.0.1"
    distro = "rhel-10"
    [[packages]]
    name = "podman"
    version = "*"
    [[containers]]
    source = "registry.access.redhat.com/ubi10:8080/osbuild/container/container-image@sha256:manifest-ID-from-Repository-tag: tag-version"
    name =  "source"
    tls-verify = true
    Copy to Clipboard Toggle word wrap
  2. Push the blueprint:

    # composer-cli blueprints push <blueprint_image>.toml
    Copy to Clipboard Toggle word wrap
  3. Build the container image:

    # composer-cli start compose <image> qcow2
    Copy to Clipboard Toggle word wrap
    • image is the blueprint name.
    • qcow2 is the image type.

      Note

      Building the image takes time because it checks the container on quay.io registry.

  4. To check the status of the compose:

    # composer-cli compose status
    Copy to Clipboard Toggle word wrap

    A finished compose shows the FINISHED status value. To identify your compose in the list, use its UUID.

  5. After the compose process is finished, download the resulting image file to your default download location:

    # composer-cli compose image <uuid>
    Copy to Clipboard Toggle word wrap

    Replace UUID with the UUID value shown in the previous steps.

    You can use the qcow2 image you created and downloaded to create a VM.

Verification

  1. Locate the resulting qcow2 image.
  2. Start the qcow2 image in a VM. See Creating a virtual machine from a KVM guest image.
  3. The qemu wizard opens. Login in to the qcow2 image by entering the username and password. These can be the username and password you set up in the .qcow2 blueprint in the customizations.user section, or created at boot time with cloud-init.
  4. Run the container image and open a shell prompt inside the container:

    # podman run -it registry.access.redhat.com/ubi10:8080/osbuild/<repository>/bin/bash/
    Copy to Clipboard Toggle word wrap

    registry.access.redhat.com is the target registry, osbuild is the organization, and repository is the location to push the container when it finishes building.

  5. Check that the packages you added to the blueprint are available:

    # type -a nginx
    Copy to Clipboard Toggle word wrap

    The output shows you the nginx package path.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat