Deploying OpenShift with Digital Rebar Platform (DRP)¶

This tutorial walks you through deploying a production OpenShift cluster using Digital Rebar Platform (DRP). It is organized into four parts:

1. Stage DRP Content — Get the right bits onto your DRP server
2. Configure a Tracking Repo — Store cluster state in Git for auditing and GitOps
3. Deploy an OpenShift Cluster — Create the cluster and let automation do the work
4. Access the Cluster — Retrieve credentials and verify health

Contents¶

• Prerequisites
• Firewall Requirements
• Part 1: Stage DRP Content
  • Step 1: Obtain Your Pull Secret
  • Step 2: Set the Pull Secret in the Global Profile
  • Step 3: Install DRP Content Packs
  • Step 4: Stage the OpenShift Version Artifacts
  • Step 5: Install the openshift-client-runner Context
• Part 2: Deploy an OpenShift Cluster
  • Step 6: Identify Your Machines
  • Step 7: Apply Hardware Profiles
  • Step 8: Configure Network Data
  • Step 9: Assign Machine Roles
  • Step 10: Create a Pool and Add Machines
  • Step 11: Gather Network Information
    • DNS and Load Balancer Options
  • Step 12: Create the Cluster
  • Step 13: Monitor Deployment
• Part 3: Access the Cluster
  • Step 14: Retrieve the kubeconfig
  • Step 15: Retrieve the kubeadmin Password
  • Step 16: Verify Cluster Health
  • Step 17: Access the Web Console
• Reference: Key Parameters
• Reference: Deployment Tasks
• Reference: Administrative Blueprints

Prerequisites¶

Before starting, confirm you have the following:

• DRP installed with a reachable static IP address accessible by all nodes
• If needed, add --static-ip <IP> to /etc/systemd/system/dr-provision.service
• drpcli installed and authenticated against your DRP endpoint
• A valid Red Hat account with an active OpenShift subscription
• Machines that meet minimum specs for your chosen cluster topology:

OpenShift supports three deployment topologies — choose the one that fits your environment:

Minimum hardware specs per node:

Firewall Requirements¶

The following outbound HTTPS connections must be allowed from your DRP server and cluster nodes. All connections use port 443.

DRP Server¶

Cluster Nodes (during and after installation)¶

Conditional¶

Part 1: Stage DRP Content¶

This section downloads and stages the OpenShift binaries, CoreOS ISO, and content pack onto your DRP server. If your DRP server can reach the internet this is largely automated. Airgap differences are called out inline.

Step 1: Obtain Your Pull Secret¶

OpenShift requires a pull secret to authenticate with Red Hat's container registries. You must obtain this before deploying.

1. Log in to Red Hat OpenShift Cluster Manager
2. Click Copy pull secret or Download pull secret
3. Save the JSON to a file on your DRP server, e.g. ~/pull_secret

The pull secret is a JSON object containing credentials for the following registries (example below):

{
  "auths": {
    "cloud.openshift.com": { "auth": "...", "email": "you@example.com" },
    "quay.io": { "auth": "...", "email": "you@example.com" },
    "registry.connect.redhat.com": { "auth": "...", "email": "you@example.com" },
    "registry.redhat.io": { "auth": "...", "email": "you@example.com" }
  }
}

Step 2: Set the Pull Secret in the Global Profile¶

By storing the pull secret in DRP's global profile, it is automatically available to all cluster deployments without needing to paste it every time.

drpcli profiles set global param openshift/pull-secret to - < ~/pull_secret

Verify it was saved:

drpcli profiles get global param openshift/pull-secret | head -5

You should see the auths JSON structure returned.

Step 3: Install DRP Content Packs¶

Four base content packs must be loaded into DRP before staging OpenShift artifacts. These provide the core tasks, boot environments, and OpenShift automation templates.

Connected environment:

drpcli catalog item install universal
drpcli catalog item install drp-community-content
drpcli catalog item install coreos
drpcli catalog item install openshift

drpcli contents upload universal.yaml
drpcli contents upload drp-community-content.yaml
drpcli contents upload coreos.yaml
drpcli contents upload openshift.yaml

Verify all four are loaded:

drpcli contents list | jq -r '.[].meta.Name' | grep -E 'universal|community|coreos|openshift'

Step 4: Stage the OpenShift Version Artifacts¶

The OpenShift content bundle provides DRP with the tasks, profiles, and templates needed to deploy a cluster. It also requires version-specific artifacts: the installer binary, CLI tools, and the CoreOS ISO.

Option A: Bootstrap via Self-Runner (Easiest)¶

If your DRP server can reach the internet, the easiest method is to use the DRP self-runner machine's bootstrap workflow. This downloads everything and installs the context container automatically.

SELF_RUNNER=drp-demo   # Replace with your self-runner machine name

drpcli machines update Name:$SELF_RUNNER '{ "Locked": false }'
drpcli machines addprofile Name:$SELF_RUNNER bootstrap-contexts
drpcli machines addprofile Name:$SELF_RUNNER bootstrap-openshift-client-runner
drpcli machines addprofile Name:$SELF_RUNNER bootstrap-openshift-contents
drpcli machines set Name:$SELF_RUNNER param openshift/bootstrap-versions to '["latest-4.21"]'

# Run the rebootstrap-drp blueprint
drpcli machines work_order add Name:$SELF_RUNNER rebootstrap-drp

Option B: Script-Based (Connected, More Control)¶

From the directory containing your OpenShift content repo, run the artifact generation script to download and stage all required files:

OS_VERSION=latest-4.21
./generate_openshift_artifacts.sh --version $OS_VERSION

This script: - Resolves latest-4.21 to the current stable release (e.g. 4.21.1) - Downloads the OpenShift installer, CLI tools, and mirror tool - Generates the version-specific content pack - Prints the path to the generated install.sh

Run the install.sh printed by the script to upload everything to DRP:

# The script output will show the actual version path, e.g.:
oc_content/4.21.1/install.sh

drpcli machines create fake-machine
drpcli templates render generate-openshift-artifacts.sh.tmpl Name:fake-machine \
  > generate_openshift_artifacts.sh
drpcli machines destroy Name:fake-machine
chmod +x generate_openshift_artifacts.sh

Option C: Airgap (DRP cannot reach the internet)¶

Use the --download flag to create an upload bundle on a system that can reach the internet, then transfer it to your DRP server.

On the internet-connected system:

OS_VERSION=latest-4.21
./generate_openshift_artifacts.sh --version $OS_VERSION --download
# Creates oc_content/bundles/openshift-upload-bundle-<VERSION>.tgz

Copy the bundle to your DRP server, then upload:

OS_VERSION=4.21.1   # Use the resolved version printed above
drpcli files upload openshift-upload-bundle-${OS_VERSION}.tgz --explode
drpcli files download redhat/openshift/openshift-cluster-${OS_VERSION}.yaml \
  as openshift-cluster-${OS_VERSION}.yaml
drpcli contents upload openshift-cluster-${OS_VERSION}.yaml

Verify the Content is Loaded¶

Confirm the version-specific profile is present:

drpcli profiles list Name re 'openshift-cluster-4*' | jq -r '.[].Name'

You should see openshift-cluster-4.21.1 (or your resolved version) in the output.

Step 5: Install the openshift-client-runner Context¶

DRP uses a container context (openshift-client-runner) to run the OpenShift CLI tools (oc, kubectl) during cluster operations. This is a Fedora-based container image that is not included in the install.sh script — it must be installed separately.

Confirm whether it is already installed:

drpcli contexts list | jq -r '.[].Name' | grep openshift

Expected output: openshift-client-runner

If it is missing, choose one of the following methods:

Option A: Bootstrap (DRP server can reach internet)¶

Follow the bootstrap steps from Step 4, Option A. The bootstrap-contexts and bootstrap-openshift-client-runner profiles both handle context installation.

Option B: Manual install via CLI (connected)¶

IMAGE=$(drpcli contexts show openshift-client-runner 2>/dev/null | jq -re '.Image' \
  || echo 'openshift-client-runner_v1.2.22')

# Download from RackN, stage in DRP file store, and load into the docker-context plugin
drpcli files upload https://get.rebar.digital/containers/${IMAGE}.tar.gz \
  as contexts/docker-context/${IMAGE}
drpcli plugins runaction docker-context imageUpload \
  context/image-name $IMAGE \
  context/image-path files/contexts/docker-context/$IMAGE

Option C: Airgap — download on a connected system, import on DRP¶

On a system that has internet access (does not need drpcli):

# Determine the image name — check your openshift content pack version or use the
# default below (update the version number if deploying a different release)
IMAGE=$(drpcli contexts show openshift-client-runner 2>/dev/null | jq -re '.Image' \
  || echo 'openshift-client-runner_v1.2.22')

wget "https://get.rebar.digital/containers/${IMAGE}.tar.gz"

Transfer the .tar.gz to your DRP server, then upload and load it:

IMAGE=openshift-client-runner_v1.2.22   # set to the filename you downloaded

drpcli files upload ${IMAGE}.tar.gz as contexts/docker-context/${IMAGE}
drpcli plugins runaction docker-context imageUpload \
  context/image-name $IMAGE \
  context/image-path files/contexts/docker-context/$IMAGE

Verify it loaded:

drpcli contexts list | jq -r '.[].Name' | grep openshift

Part 2: Deploy an OpenShift Cluster¶

With content staged, you are ready to deploy. This section walks through assigning machine roles, adding hardware profiles, creating a resource pool, and launching the cluster pipeline.

Step 6: Identify Your Machines¶

List the machines available for deployment:

drpcli machines list | jq -r '.[].Name'

Choose the correct number of machines for your cluster topology (see Prerequisites): - Single Node: 1 machine (acts as both control plane and worker) - Compact (3-node): 3 machines (control plane nodes also run workloads) - Full cluster: 3 control plane + 2 or more workers

Note their names — you will use them in the following steps.

Step 7: Apply Hardware Profiles¶

Before assigning OpenShift roles, apply any site-specific hardware profiles to your machines. These profiles configure BMC/BIOS settings, RAID, network bonding, and disk selection appropriate for your hardware vendor and environment.

# Example: apply your site hardware profile to each machine
drpcli machines addprofile Name:<machine-name> <your-hardware-profile>

Common hardware profile categories: - Disk selection: Use the openshift/install-rootDeviceHints parameter to specify which disk OpenShift installs to (e.g. by serial number, size, or model). This is especially important on servers with multiple disks. - Network bonding/VLAN: Add profiles that configure interface bonding or VLAN tagging on the nodes. - BIOS/RAID: Vendor-specific profiles (e.g. for Dell, HPE, or Lenovo) that configure hardware before the OS boots.

Step 8: Configure Network Data (Optional)¶

If your cluster nodes require custom network configuration — bonded interfaces, VLANs, static IP addresses, or jumbo frames — set the network-data parameter on each machine before deployment. This drives the NMState configuration injected into each node's agent boot ISO.

The network-data parameter is a map with a prod key that describes the primary machine network interface used by OpenShift.

Example 1: DHCP (default — no configuration needed)

If your nodes get IP addresses via DHCP, skip this step entirely.

Example 2: Static IP, single NIC

drpcli machines set Name:<machine-name> param network-data to - <<EOF
prod:
  address: 192.168.1.101
  prefix: 24
  gateway: 192.168.1.1
  dns-servers:
    - 192.168.1.1
  interface: eth0
  dhcp: 'false'
EOF

Example 3: Bonded interfaces with VLAN and static IP

drpcli machines set Name:<machine-name> param network-data to - <<EOF
prod:
  address: 10.102.147.24
  prefix: 26
  gateway: 10.102.147.1
  dns-servers:
    - 10.80.1.222
    - 10.80.2.222
  interface: eno12399np0,ens1f0np0
  bond: bond0
  vlan: '206'
  dhcp: 'false'
  mtu: '9000'
  link-aggregation:
    mode: 802.3ad
    options:
      lacp_rate: '1'
      miimon: '100'
      xmit_hash_policy: layer2+3
EOF

Repeat for each machine in the cluster, substituting the correct IP address per machine.

Step 9: Assign Machine Roles¶

Assign each machine an OpenShift role by adding the appropriate profile. Control plane and worker roles are mutually exclusive.

# Assign control plane role to each control plane machine
drpcli machines addprofile Name:<cp-machine-1> openshift-controlplane
drpcli machines addprofile Name:<cp-machine-2> openshift-controlplane  # skip for SNO
drpcli machines addprofile Name:<cp-machine-3> openshift-controlplane  # skip for SNO

# Assign worker role — only needed for full clusters with separate worker nodes
drpcli machines addprofile Name:<worker-machine-1> openshift-worker
drpcli machines addprofile Name:<worker-machine-2> openshift-worker
drpcli machines addprofile Name:<worker-machine-3> openshift-worker

drpcli machines set Name:<machine-name> param openshift/role to controlplane

Verify the roles were set (using aggregate=true to resolve values set via profiles):

drpcli machines list aggregate=true | \
  jq -r '.[] | select(.Params | has("openshift/role")) | "\(.Name): \(.Params["openshift/role"])"'

Step 10: Create a Pool and Add Machines¶

The cluster pipeline discovers machines through a DRP pool. Create a pool named after your cluster and add all cluster machines to it.

CLUSTER_NAME=tutorial

# Add control plane machines
drpcli pools manage add $CLUSTER_NAME "Name=<cp-machine-1>"
drpcli pools manage add $CLUSTER_NAME "Name=<cp-machine-2>"
drpcli pools manage add $CLUSTER_NAME "Name=<cp-machine-3>"

# Add worker machines
drpcli pools manage add $CLUSTER_NAME "Name=<worker-machine-1>"
drpcli pools manage add $CLUSTER_NAME "Name=<worker-machine-2>"
drpcli pools manage add $CLUSTER_NAME "Name=<worker-machine-3>"

Verify all machines are in the pool:

drpcli machines list | jq -r \
  '.[] | select(.Pool == "'$CLUSTER_NAME'") | "\(.Name): \(.Params["openshift/role"])"'

Step 11: Gather Network Information¶

Before creating the cluster, collect the following network details for your environment. All three networks must not overlap.

DNS / Load Balancer Configuration¶

Two parameters control how DNS is resolved for the cluster:

External DNS (default) — Leave both parameters at their defaults when you have existing DNS infrastructure (Active Directory, BIND, Route 53, etc.) and an external load balancer or upstream proxy handling the API endpoint. You are responsible for creating the required DNS records before the cluster boots:

• api.<cluster-name>.<domain> → your API load balancer IP
• api-int.<cluster-name>.<domain> → your API load balancer IP
• *.apps.<cluster-name>.<domain> → your Ingress load balancer IP

DRP-managed DNS — Set openshift/enable-dns-zone: true when no external DNS is available and DRP is the DNS resolver for the cluster network. DRP will create and maintain all required records automatically as nodes join or are replaced. When enabled, openshift/api-vip and openshift/ingress-vip must both be set.

OpenShift internal load balancer — Set openshift/enable-internal-lb: true for bare-metal or on-premises environments without an external load balancer. OpenShift will deploy keepalived across the control plane nodes to provide VIP failover. When enabled, openshift/api-vip and openshift/ingress-vip must both be set to free IPs within the Machine Network CIDR.

Step 12: Create the Cluster¶

Create a cluster configuration YAML file. Replace the placeholder values with your actual network information. A reference copy of this file is at openshift-deploy-tutorial-cluster-config.yaml.

CLUSTER_NAME=tutorial
CLUSTER_DOMAIN=k8s.local
MACHINE_CIDR=<your-machine-cidr>
OS_VERSION=${OS_VERSION:-4.21.1} # Use the resolved version from Step 4

cat > cluster-config.yaml <<EOF
---
Name: $CLUSTER_NAME
Profiles:
  - universal-application-openshift-cluster
  - openshift-cluster-${OS_VERSION}
Workflow: universal-start
Meta:
  BaseContext: openshift-client-runner
Params:
  broker/name: pool-broker
  broker-pool/pool: $CLUSTER_NAME
  openshift/cluster-domain: $CLUSTER_DOMAIN
  openshift/network/machineNetwork:
    - cidr: $MACHINE_CIDR
  openshift/network/serviceNetwork:
    - 172.30.0.0/16
  openshift/network/clusterNetwork:
    - hostPrefix: 23
      cidr: 10.128.0.0/14
  # DNS and load balancer options — see Step 11 for guidance
  openshift/enable-dns-zone: false    # set true to let DRP manage DNS records
  openshift/enable-internal-lb: false # set true to use OpenShift keepalived VIPs
EOF

drpcli clusters create - < cluster-config.yaml

Enabling the internal load balancer — if you set openshift/enable-internal-lb: true, add the VIP addresses to the Params block:

  openshift/enable-internal-lb: true
  openshift/api-vip: <your-api-vip>         # unused IP within machine network
  openshift/ingress-vip: <your-ingress-vip>  # unused IP within machine network

drpcli profiles show $CLUSTER_NAME | jq '{Name: .Name, Profiles: .Profiles}'

openshift/gitops-repo-url: https://git.example.com/my-org/my-cluster-config.git

Confirm the cluster was created:

drpcli clusters show Name:$CLUSTER_NAME | jq '{Name: .Name, Stage: .Stage, Workflow: .Workflow}'

Step 13: Monitor Deployment¶

The cluster deployment runs through three automated phases:

1. Pre-provisioning — Generates install-config.yaml, agent configs, and NMState network configuration
2. Resource provisioning — Machines boot the agent ISO and begin joining the cluster
3. Post-provisioning — Waits for bootstrap, then installation, then installs the NMState operator

Monitor cluster pipeline progress:

drpcli clusters show Name:$CLUSTER_NAME | \
  jq '{Stage: .Stage, CurrentTask: .CurrentTask, JobState: .JobState}'

Watch member machine progress:

# $CLUSTER_NAME must be set in your shell before running this
watch -n 30 'drpcli machines list | jq -r ".[] | select(.Pool == \"'$CLUSTER_NAME'\") | \"\(.Name): \(.Stage)\""'

Deployment typically takes 30–60 minutes depending on hardware and network speed.

drpcli machines show Name:<machine-name> | jq '{Stage: .Stage, CurrentTask: .CurrentTask}'

oc get nodes
oc get clusteroperators
oc get clusterversion

Parameter openshift/pull-secret not in scope

Part 3: Access the Cluster¶

Once the deployment completes, the cluster credentials are stored as parameters on the cluster object in DRP.

Step 14: Retrieve the kubeconfig¶

The openshift/kubeconfig parameter is set automatically when installation completes.

CLUSTER_NAME=tutorial

# Save the kubeconfig to a local file
mkdir -p ~/.kube
drpcli clusters get Name:$CLUSTER_NAME param openshift/kubeconfig --aggregate \
  > ~/.kube/${CLUSTER_NAME}-config

# Point kubectl/oc at the cluster
export KUBECONFIG=~/.kube/${CLUSTER_NAME}-config

Step 15: Retrieve the kubeadmin Password¶

drpcli clusters get Name:$CLUSTER_NAME param openshift/kubeadmin-password --aggregate

Step 16: Verify Cluster Health¶

Confirm all nodes have joined and the cluster operators are healthy:

# All nodes should show Ready
oc get nodes

# All cluster operators should show Available=True, Progressing=False, Degraded=False
oc get clusteroperators

# Confirm the installed version
oc get clusterversion

Expected output for oc get nodes on a 3+3 cluster:

NAME              STATUS   ROLES                  AGE   VERSION
cp-machine-1      Ready    control-plane,master   71m   v1.34.2
cp-machine-2      Ready    control-plane,master   71m   v1.34.2
cp-machine-3      Ready    control-plane,master   43m   v1.34.2
worker-machine-1  Ready    worker                 44m   v1.34.2
worker-machine-2  Ready    worker                 44m   v1.34.2
worker-machine-3  Ready    worker                 45m   v1.34.2

Step 17: Access the Web Console¶

Retrieve the console URL from DRP:

drpcli clusters get Name:$CLUSTER_NAME param openshift/console --aggregate

This returns the full URL, for example:

https://console-openshift-console.apps.tutorial.k8s.local

Log in with username kubeadmin and the password retrieved in Step 15.

Add-DnsClientNrptRule -Namespace ".k8s.local" -NameServers "<DRP-IP>"
Clear-DnsClientCache

dig @<DRP-IP> console-openshift-console.apps.tutorial.k8s.local

Quick Verification: Deploy a Test Application¶

Once your cluster is healthy, deploy a simple test application to confirm workloads run:

# Create a new project
oc new-project hello-openshift

# Deploy a test pod
kubectl create deployment hello-node \
  --image=registry.k8s.io/e2e-test-images/agnhost:2.43 \
  -- /agnhost serve-hostname

# Expose the service
oc expose deployment hello-node --port=9376
oc expose service hello-node

# Test it (substitute your cluster name and domain)
curl hello-node-hello-openshift.apps.tutorial.k8s.local

# Clean up
oc delete project hello-openshift

Reference: Key Parameters¶

All parameters are documented in the OpenShift content pack. The most important ones for initial deployment:

Reference: Deployment Tasks¶

The universal-application-openshift-cluster pipeline runs these tasks automatically:

Reference: Administrative Blueprints¶

After deployment, use these DRP blueprints for ongoing management: