In this post, we’re going to show you how to use Red Hat Universal Base Image (UBI) in conjunction with a couple of different cloud services including the Red Hat Container Catalog, Azure Pipelines, and Red Hat Quay.io to continuously build images for use by developers and production alike. Here’s what the architecture looks like:

Image building architecture

The UBI base container image is first consumed from the trusted Red Hat Container Catalog, pulled into Azure Pipelines to build a new layered image, and finally pushed into Red Hat Quay.io for consumption by Podman, Red Hat OpenShift or any other Kubernetes service. This is a pipeline which uses infrastructure controlled by trusted sources from source to delivery.

Before we start, this tutorial doesn’t assume that you have too much knowledge about any of these tools, but it does assume a level of comfort with clicking around and hacking a bit. Also, these instructions could be used to develop a similar workflow with almost any container image build service. Let’s get started.

First, log into Red Hat Quay.io and create a robot account. This account will be used by Azure Pipelines to push images into Quay.io. Save this username and token for the ServiceConnection you will create in Azure Pipelines:

Creating a robot account for the pipeline

Once you have created a robot account, create a repository and give the robot read/write access to it:

Creating a repository and giving the robot read/write access to it.

Log into Github and forking an example repository that’s been created for this tutorial: fatherlinux/ubi-azure-pipelines.

Forking the github repository Edit the username and imageName to match what you create on Red Hat Quay.io:

Editing imagename and username

Now, let’s log into Azure Pipelines and create a new project:

Creating a new repository in Azure Pipelines

Select the fork of the GitHub repository:

Selecting a fork of the github repository
Now, select the existing Azure Pipelines YAML file:

Selecting the YAML file

Review the Azure Pipelines YAML file. Make sure the imageName variable matches your username and the repository you created on Quay.io. When complete, save the project (it’s an option next to run). You can always edit it later by connecting your Azure Pipelines account to GitHub:

Review pipeline YAML

Now, you have a project created and a pipeline within it. Navigate back up to the setting for the project, and go to the Service Connections Settings. Create a new Docker Registry Service Connection. This will authorize Azure Pipelines to push container images to your repository on Red Hat Quay.io:

Authorize Azure Pipelines to push container images to your repository on Red Hat Quay.io

Use the username and Token that we created in the first step at Red Hat Quay.io:

Use the username and Token that we created in the first step at Red Hat Quay.io

Now, run your pipeline and watch Azure Pipelines pull a fresh copy of UBI from the Red Hat Container Catalog, build a layer on top, and push it into Red Hat Quay.io. 

Pushing an image to Quay.io from Azure Pipelines.

Azure Pipelines will rebuild the image anytime you modify your GitHub repository, enabling a very GitOps oriented workflow. Notice, AzurePipelines will not automatically rebuild your image when new versions of the Red Hat UBI image are published, or RPM patches are released in the associated repositories. 

Now, go forth and build with a Cloud Native and DevSecOps mindset!


Sull'autore

At Red Hat, Scott McCarty is Senior Principal Product Manager for RHEL Server, arguably the largest open source software business in the world. Focus areas include cloud, containers, workload expansion, and automation. Working closely with customers, partners, engineering teams, sales, marketing, other product teams, and even in the community, he combines personal experience with customer and partner feedback to enhance and tailor strategic capabilities in Red Hat Enterprise Linux.

McCarty is a social media start-up veteran, an e-commerce old timer, and a weathered government research technologist, with experience across a variety of companies and organizations, from seven person startups to 20,000 employee technology companies. This has culminated in a unique perspective on open source software development, delivery, and maintenance.

Read full bio