Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 10. Using Red Hat subscriptions in builds

Use the following sections to run entitled builds on OpenShift Container Platform.

10.1. Creating an image stream tag for the Red Hat Universal Base Image
Link kopieren

To use Red Hat subscriptions within a build, you create an image stream tag to reference the Universal Base Image (UBI).

To make the UBI available in every project in the cluster, you add the image stream tag to the 

openshift
namespace. Otherwise, to make it available in a specific project, you add the image stream tag to that project.

The benefit of using image stream tags this way is that doing so grants access to the UBI based on the 

registry.redhat.io
credentials in the install pull secret without exposing the pull secret to other users. This is more convenient than requiring each developer to install pull secrets with 
registry.redhat.io
credentials in each project.

Procedure

  • To create an 

    ImageStreamTag
    in the 
    openshift
    namespace, so it is available to developers in all projects, enter: 

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

    You can alternatively apply the following YAML to create an 

    ImageStreamTag
    in the 
    openshift
    namespace: 

    apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: ubi
  namespace: openshift
spec:
  tags:
  - from:
      kind: DockerImage
      name: registry.redhat.io/ubi8/ubi:latest
    name: latest
    referencePolicy:
      type: Source

  • To create an 

    ImageStreamTag
    in a single project, enter: 

    $ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest
    Tip

    You can alternatively apply the following YAML to create an 

    ImageStreamTag
    in a single project: 

    apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: ubi
spec:
  tags:
  - from:
      kind: DockerImage
      name: registry.redhat.io/ubi8/ubi:latest
    name: latest
    referencePolicy:
      type: Source

10.2. Adding subscription entitlements as a build secret
Link kopieren

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. The entitlement secret is automatically created by the Insights Operator.

Tip

When you perform an Entitlement Build using Red Hat Enterprise Linux (RHEL) 7, you must have the following instructions in your Dockerfile before you run any 

yum
commands: 

RUN rm /etc/rhsm-host

Procedure

  1. Add the etc-pki-entitlement secret as a build volume in the build configuration’s Docker strategy: 

    strategy:
  dockerStrategy:
    from:
      kind: ImageStreamTag
      name: ubi:latest
    volumes:
    - name: etc-pki-entitlement
      mounts:
      - destinationPath: /etc/pki/entitlement
      source:
        type: Secret
        secret:
          secretName: etc-pki-entitlement

10.3. Running builds with Subscription Manager
Link kopieren

10.3.1. Docker builds using Subscription Manager
Link kopieren

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

Prerequisites

The entitlement keys must be added as build strategy volumes.

Procedure

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

FROM registry.redhat.io/ubi8/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

10.4. Running builds with Red Hat Satellite subscriptions
Link kopieren

10.4.1. Adding Red Hat Satellite configurations to builds
Link kopieren

Builds that use Red Hat 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 and entitlement key as a build volumes: 

    strategy:
  dockerStrategy:
    from:
      kind: ImageStreamTag
      name: ubi:latest
    volumes:
    - name: yum-repos-d
      mounts:
      - destinationPath: /etc/yum.repos.d
      source:
        type: ConfigMap
        configMap:
          name: yum-repos-d
    - name: etc-pki-entitlement
      mounts:
      - destinationPath: /etc/pki/entitlement
      source:
        type: Secret
        secret:
          secretName: etc-pki-entitlement

10.4.2. Docker builds using Red Hat Satellite subscriptions
Link kopieren

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

Prerequisites

  • You have added the entitlement keys and Satellite repository configurations as build volumes.

Procedure

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

FROM registry.redhat.io/ubi8/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

10.5. Running entitled builds using SharedSecret objects
Link kopieren

You can configure and perform a build in one namespace that securely uses RHEL entitlements from a 

Secret
object in another namespace.

You can still access RHEL entitlements from OpenShift Builds by creating a 

Secret
object with your subscription credentials in the same namespace as your 
Build
object. However, now, in OpenShift Container Platform 4.10 and later, you can access your credentials and certificates from a 
Secret
object in one of the OpenShift Container Platform system namespaces. You run entitled builds with a CSI volume mount of a 
SharedSecret
custom resource (CR) instance that references the 
Secret
object.

This procedure relies on the newly introduced Shared Resources CSI Driver feature, which you can use to declare CSI Volume mounts in OpenShift Container Platform Builds. It also relies on the OpenShift Container Platform Insights Operator.

Important

The Shared Resources CSI Driver and The Build CSI Volumes are both Technology Preview features, which are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

The Shared Resources CSI Driver and the Build CSI Volumes features also belong to the 

TechPreviewNoUpgrade
feature set, which is a subset of the current Technology Preview features. You can enable the 
TechPreviewNoUpgrade
feature set on test clusters, where you can fully test them while leaving the features disabled on production clusters. Enabling this feature set cannot be undone and prevents minor version updates. This feature set is not recommended on production clusters. See "Enabling Technology Preview features using feature gates" in the following "Additional resources" section.

Prerequisites

  • You have enabled the 
    TechPreviewNoUpgrade
    feature set by using the feature gates.
  • You have a 
    SharedSecret
    custom resource (CR) instance that references the 
    Secret
    object where the Insights Operator stores the subscription credentials.

  • You must have permission to perform the following actions:

    • Create build configs and start builds.
    • Discover which 
      SharedSecret
      CR instances are available by entering the 
      oc get sharedsecrets
      command and getting a non-empty list back.
    • Determine if the 
      builder
      service account available to you in your namespace is allowed to use the given 
      SharedSecret
      CR instance. In other words, you can run 
      oc adm policy who-can use <identifier of specific SharedSecret>
      to see if the 
      builder
      service account in your namespace is listed.
Note

If neither of the last two prerequisites in this list are met, establish, or ask someone to establish, the necessary role-based access control (RBAC) so that you can discover 

SharedSecret
CR instances and enable service accounts to use 
SharedSecret
CR instances.

Procedure

  1. Grant the 

    builder
    service account RBAC permissions to use the 
    SharedSecret
    CR instance by using 
    oc apply
    with YAML content:

    Note

    Currently, 

    kubectl
    and 
    oc
    have hard-coded special case logic restricting the 
    use
    verb to roles centered around pod security. Therefore, you cannot use 
    oc create role …​
    to create the role needed for consuming 
    SharedSecret
    CR instances.

    Example oc apply -f command with YAML Role object definition

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. Create the 

    RoleBinding
    associated with the role by using the 
    oc
    command:

    Example oc create rolebinding command

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. Create a 

    BuildConfig
    object that accesses the RHEL entitlements.

    Example YAML BuildConfig object definition

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: my-csi-bc
  namespace: my-csi-app-namespace
spec:
  runPolicy: Serial
  source:
    dockerfile: |
      FROM registry.redhat.io/ubi8/ubi:latest
      RUN ls -la /etc/pki/entitlement
      RUN rm /etc/rhsm-host
      RUN yum repolist --disablerepo=*
      RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
      RUN yum -y update
      RUN yum install -y openshift-clients.x86_64
  strategy:
    type: Docker
    dockerStrategy:
      volumes:
        - mounts:
            - destinationPath: "/etc/pki/entitlement"
          name: my-csi-shared-secret
          source:
            csi:
              driver: csi.sharedresource.openshift.io
              readOnly: true
              volumeAttributes:
                sharedSecret: my-share-bc
            type: CSI

  4. Start a build from the 

    BuildConfig
    object and follow the logs with the 
    oc
    command.

    Example oc start-build command

    $ oc start-build my-csi-bc -F

    Example 10.1. Example output from the oc start-build command

    Note

    Some sections of the following output have been replaced with 

    …​
     

    build.build.openshift.io/my-csi-bc-1 started
Caching blobs under "/var/cache/blobs".

Pulling image registry.redhat.io/ubi8/ubi:latest ...
Trying to pull registry.redhat.io/ubi8/ubi:latest...
Getting image source signatures
Copying blob sha256:5dcbdc60ea6b60326f98e2b49d6ebcb7771df4b70c6297ddf2d7dede6692df6e
Copying blob sha256:8671113e1c57d3106acaef2383f9bbfe1c45a26eacb03ec82786a494e15956c3
Copying config sha256:b81e86a2cb9a001916dc4697d7ed4777a60f757f0b8dcc2c4d8df42f2f7edb3a
Writing manifest to image destination
Storing signatures
Adding transient rw bind mount for /run/secrets/rhsm
STEP 1/9: FROM registry.redhat.io/ubi8/ubi:latest
STEP 2/9: RUN ls -la /etc/pki/entitlement
total 360
drwxrwxrwt. 2 root root 	80 Feb  3 20:28 .
drwxr-xr-x. 10 root root	154 Jan 27 15:53 ..
-rw-r--r--. 1 root root   3243 Feb  3 20:28 entitlement-key.pem
-rw-r--r--. 1 root root 362540 Feb  3 20:28 entitlement.pem
time="2022-02-03T20:28:32Z" level=warning msg="Adding metacopy option, configured globally"
--> 1ef7c6d8c1a
STEP 3/9: RUN rm /etc/rhsm-host
time="2022-02-03T20:28:33Z" level=warning msg="Adding metacopy option, configured globally"
--> b1c61f88b39
STEP 4/9: RUN yum repolist --disablerepo=*
Updating Subscription Management repositories.


...

--> b067f1d63eb
STEP 5/9: RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
Repository 'rhocp-4.9-for-rhel-8-x86_64-rpms' is enabled for this system.
time="2022-02-03T20:28:40Z" level=warning msg="Adding metacopy option, configured globally"
--> 03927607ebd
STEP 6/9: RUN yum -y update
Updating Subscription Management repositories.

...

Upgraded:
  systemd-239-51.el8_5.3.x86_64      	systemd-libs-239-51.el8_5.3.x86_64
  systemd-pam-239-51.el8_5.3.x86_64
Installed:
  diffutils-3.6-6.el8.x86_64           	libxkbcommon-0.9.1-1.el8.x86_64
  xkeyboard-config-2.28-1.el8.noarch

Complete!
time="2022-02-03T20:29:05Z" level=warning msg="Adding metacopy option, configured globally"
--> db57e92ff63
STEP 7/9: RUN yum install -y openshift-clients.x86_64
Updating Subscription Management repositories.

...

Installed:
  bash-completion-1:2.7-5.el8.noarch
  libpkgconf-1.4.2-1.el8.x86_64
  openshift-clients-4.9.0-202201211735.p0.g3f16530.assembly.stream.el8.x86_64
  pkgconf-1.4.2-1.el8.x86_64
  pkgconf-m4-1.4.2-1.el8.noarch
  pkgconf-pkg-config-1.4.2-1.el8.x86_64

Complete!
time="2022-02-03T20:29:19Z" level=warning msg="Adding metacopy option, configured globally"
--> 609507b059e
STEP 8/9: ENV "OPENSHIFT_BUILD_NAME"="my-csi-bc-1" "OPENSHIFT_BUILD_NAMESPACE"="my-csi-app-namespace"
--> cab2da3efc4
STEP 9/9: LABEL "io.openshift.build.name"="my-csi-bc-1" "io.openshift.build.namespace"="my-csi-app-namespace"
COMMIT temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
--> 821b582320b
Successfully tagged temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
821b582320b41f1d7bab4001395133f86fa9cc99cc0b2b64c5a53f2b6750db91
Build complete, no image push requested
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben