This is a cache of https://docs.openshift.com/container-platform/4.2/builds/running-entitled-builds.html. It is a snapshot of the page at 2024-11-28T02:36:09.728+0000.
Using Red Hat subscriptions in builds | Builds | OpenShift Container Platform 4.2
×

Creating an ImageStreamTag to the Red Hat Universal Base Image

To use Red Hat subscriptions within a build, you should create an ImageStream to reference the universal base image (UBI).

Builds that reference the UBI directly from registry.redhat.io will require a pull secret.

Prerequisites
  • You must create a pull secret for registry.redhat.io, and link it to a user project.

Procedure
  • To create an imagestreamtag in a single project:

    $ oc tag --source=docker registry.redhat.io/ubi7/ubi:latest ubi:latest
  • To create an imagestreamtag in the OpenShift Container Platform namespace, making it available to developers in all projects:

    $ oc tag --source=docker registry.redhat.io/ubi7/ubi:latest ubi:latest -n openshift

Adding subscription entitlements as a build secret

Builds that use Red Hat subscriptions to install content must include the entitlement keys as a build secret.

Prerequisites

You must have access to Red Hat entitlements through your subscription, and the entitlements must have separate public and private key files.

Procedure
  1. Create a secret containing your entitlements, ensuring that there are separate files containing the public and private keys:

    $  oc create secret generic etc-pki-entitlement --from-file /path/to/entitlement/{ID}.pem \
    > --from-file /path/to/entitlement/{ID}-key.pem ...
  2. Add the secret as a build input in the build configuration:

    source:
      secrets:
      - secret:
          name: etc-pki-entitlement
        destinationDir: etc-pki-entitlement

There are two paths to pulling in the base RHEL image:

  • Add the pull secret to registry.redhat.io to your project.

  • Create an imagestream in the OpenShift namespace for the RHEL-based image. This makes the imagestream available across the cluster.

Running builds with Subscription Manager

Adding Subscription Manager configurations to builds

Builds that use the Subscription Manager to install content must provide appropriate configuration files and certificate authorities for subscribed repositories.

Prerequisites

You must have access to the Subscription Manager’s configuration and certificate authority files.

Procedure
  1. Create a ConfigMap for the Subscription Manager configuration:

    $ oc create configmap rhsm-conf --from-file /path/to/rhsm/rhsm.conf
  2. Create a ConfigMap for the certificate authority:

    $ oc create configmap rhsm-ca --from-file /path/to/rhsm/ca/redhat-uep.pem
  3. Add the Subscription Manager configuration and certificate authority to the BuildConfig:

    source:
        configMaps:
        - configMap:
            name: rhsm-conf
          destinationDir: rhsm-conf
        - configMap:
            name: rhsm-ca
          destinationDir: rhsm-ca

Docker builds using Subscription Manager

Docker strategy builds can use the Subscription Manager to install subscription content.

Prerequisites

The entitlement keys, subscription manager configuration, and subscription manager certificate authority must be added as build inputs.

Procedure

Use the following as an example Dockerfile to install content with the Subscription Manager:

FROM registry.redhat.io/rhel7:latest
user root
# Copy entitlements
COPY ./etc-pki-entitlement /etc/pki/entitlement
# Copy subscription manager configurations
COPY ./rhsm-conf /etc/rhsm
COPY ./rhsm-ca /etc/rhsm/ca
# Delete /etc/rhsm-host to use entitlements from the build container
RUN rm /etc/rhsm-host && \
    # Initialize /etc/yum.repos.d/redhat.repo
    # See https://access.redhat.com/solutions/1443553
    yum repolist --disablerepo=* && \
    subscription-manager repos --enable <enabled-repo> && \
    yum -y update && \
    yum -y install <rpms> && \
    # Remove entitlements and Subscription Manager configs
    rm -rf /etc/pki/entitlement && \
    rm -rf /etc/rhsm
# OpenShift requires images to run as non-root by default
user 1001
ENTRYPOINT ["/bin/bash"]

Running builds with Satellite subscriptions

Adding Satellite configurations to builds

Builds which use Satellite to install content must provide appropriate configurations to obtain content from Satellite repositories.

Prerequisites
  • You must provide or create a yum-compatible repository configuration file that downloads content from your Satellite instance.

    Sample repository configuration
    [test-<name>]
     name=test-<number>
     baseurl = https://satellite.../content/dist/rhel/server/7/7Server/x86_64/os
     enabled=1
     gpgcheck=0
     sslverify=0
     sslclientkey = /etc/pki/entitlement/...-key.pem
     sslclientcert = /etc/pki/entitlement/....pem
Procedure
  1. Create a ConfigMap containing the Satellite repository configuration file:

    $ oc create configmap yum-repos-d --from-file /path/to/satellite.repo
  2. Add the Satellite repository configuration to the BuildConfig:

    source:
        configMaps:
        - configMap:
            name: yum-repos-d
          destinationDir: yum.repos.d

Docker builds using Satellite subscriptions

Docker strategy builds can use Satellite repositories to install subscription content.

Prerequisites

The entitlement keys and Satellite repository configurations must be added as build inputs.

Procedure

Use the following as an example Dockerfile to install content with Satellite:

FROM registry.redhat.io/rhel7:latest
user root
# Copy entitlements
COPY ./etc-pki-entitlement /etc/pki/entitlement
# Copy repository configuration
COPY ./yum.repos.d /etc/yum.repos.d
# Delete /etc/rhsm-host to use entitlements from the build container
RUN rm /etc/rhsm-host && \
    # yum repository info provided by Satellite
    yum -y update && \
    yum -y install <rpms> && \
    # Remove entitlements
    rm -rf /etc/pki/entitlement
# OpenShift requires images to run as non-root by default
user 1001
ENTRYPOINT ["/bin/bash"]

Squash layers with docker builds

Docker builds normally create a layer representing each instruction in a Dockerfile. Setting the imageOptimizationPolicy to SkipLayers will merge all instructions into a single layer on top of the base image.

Procedure
  • Set the imageOptimizationPolicy to SkipLayers:

strategy:
  dockerStrategy:
    imageOptimizationPolicy: SkipLayers

Additional resources