$ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest -n openshift
Use the following sections to run entitled builds on OpenShift Container Platform.
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.
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
You can alternatively apply the following YAML to create an
|
To create an ImageStreamTag
in a single project, enter:
$ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest
You can alternatively apply the following YAML to create an
|
Builds that use Red Hat subscriptions to install content must include the entitlement keys as a build secret.
You must have access to Red Hat entitlements through your subscription. The entitlement secret is automatically created by the Insights Operator.
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
|
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
Docker strategy builds can use the Subscription Manager to install subscription content.
The entitlement keys must be added as build strategy volumes.
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
Builds that use Red Hat Satellite to install content must provide appropriate configurations to obtain content from Satellite repositories.
You must provide or create a yum
-compatible repository configuration file that downloads content from your Satellite instance.
[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
Create a ConfigMap
containing the Satellite repository configuration file:
$ oc create configmap yum-repos-d --from-file /path/to/satellite.repo
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
Docker strategy builds can use Red Hat Satellite repositories to install subscription content.
You have added the entitlement keys and Satellite repository configurations as build volumes.
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
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.
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 https://access.redhat.com/support/offerings/techpreview/. The Shared Resources CSI Driver and the Build CSI Volumes features also belong to the |
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.
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 |
Grant the builder
service account RBAC permissions to use the SharedSecret
CR instance by using oc apply
with YAML content:
Currently, |
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
Create the RoleBinding
associated with the role by using the oc
command:
oc create rolebinding
command$ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
Create a BuildConfig
object that accesses the RHEL entitlements.
BuildConfig
object definitionapiVersion: 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
Start a build from the BuildConfig
object and follow the logs with the oc
command.
$ oc start-build my-csi-bc -F
Some sections of the following output have been replaced with |