Overview

What this track covers, who it's for, and how to use it. End-to-end disconnected OpenShift deployment anchored to the greenfield v7 fleet.

This is a self-paced track on deploying OpenShift in a disconnected environment — clusters that cannot reach registry.redhat.io, quay.io, cdn.redhat.com, or any other public endpoint at install time or runtime. By the end you’ll have mirrored a release and operator catalog into a private registry, rendered an install-config.yaml with imageDigestSources, brought a hub cluster up agent-based on KVM, applied the Day-1 baseline (signature ConfigMaps, IDMS/ITMS, CatalogSources, OperatorHub disable), handed it off to GitOps, and rehearsed the Day-2 ritual that keeps the mirror healthy.

The track is opinionated. Disconnected install has six or seven ways to do every step; this track teaches the one most platform teams ship in production as of 2026 — a Quay standalone mirror backed by MinIO object storage, oc-mirror v2 with an ImageSet under version control, agent-based install (no openshift-install against a cloud API), and the Day-2 mirror operating model that comes from operating it for real.

Who this is for

Engineers who:

• Already operate one OpenShift cluster connected to the internet and can use oc and a YAML editor without thinking.
• Know what an Operator, OperatorGroup, and Subscription are, and have installed at least one operator from OperatorHub.
• Have used oc-mirror once or never, and want to understand what the generated YAML actually does.
• Want to operate clusters in BFSI, government, defence, healthcare, or air-gapped industrial environments where the public internet is not on the install path.

If you’ve never touched OpenShift, do the OpenShift 4 Introduction self-paced lab on Red Hat Learning first. Half a day; come back here.

What you’ll learn

After completing the track:

• The four supply chains disconnected install actually has to solve — and why “just mirror the registry” is the half-answer most blogs stop at.
• The supporting service stack a disconnected cluster leans on (private DNS, edge TLS, source-control, object storage, secret custody, registry) and why each one exists.
• How to stand up a Quay standalone mirror backed by MinIO — the registry that holds release payloads, operator catalogs, and platform images.
• The oc-mirror v2 workflow end-to-end: ImageSet authoring, dry-run mapping, the push pass, and what gets generated under working-dir/cluster-resources/.
• How to render install-config.yaml and agent-config.yaml with imageDigestSources, FIPS, TPM2-backed disk encryption, and the OVN-Kubernetes IPv6 baseline (the one that breaks if you over-disable IPv6).
• How agent-based install runs in practice — the rendezvous master, KVM domain definitions, iLO virtual-media for physical workers, and the range-aware HTTP gotcha that bit issue #93.
• The Day-1 baseline: signature ConfigMaps, IDMS, ITMS, CatalogSources, ClusterCatalogs, default OperatorHub disable, and built-in OLM v1 ClusterCatalog disable.
• The handoff to GitOps: install OpenShift GitOps, seed the repo credential, apply the <cluster>-bootstrap Application, move IDMS/catalogs into Git, and use ACM’s gitops-addon to install the same on a spoke pull-mode.
• Operator pinning: channel + startingCSV, the four-step refresh ritual, and why floating channels are the most common way disconnected clusters silently drift.
• Day-2 mirror operations: encrypted backups to MinIO, lifecycle, pre-seeding repos from the dry-run mapping, the difference between a robot and a cluster-pull user, and how to detect drift.
• A capstone project: mirror OCP 4.20.18 plus one operator, install a compact hub agent-based, hand off to GitOps, and prove every pull goes through your mirror.

The 12-module map

Each module is self-contained but assumes the previous ones. Expect 45–90 minutes per module depending on whether you do the exercises.

How to use this track

Three patterns work:

• Sequential. Start at 01, walk through 11. Best for first-timers and anyone who has done a connected install but never a disconnected one.
• Reference. Use the sidebar; jump to the module you need. Best if you already operate a disconnected cluster and want a specific topic — e.g. “I just want the version-bump ritual.”
• Project-driven. Skip to 11, pick the capstone, walk backwards through the modules whose content you need. Best for the practically minded.

If you have a lab — even one beefy hypervisor running a few VMs — actually do the exercises. Disconnected install is one of those workflows where reading about imageDigestSources and watching the MCP roll out the rewritten registries.conf are completely different experiences.

What you need

To follow the lab examples literally:

• A hypervisor host with libvirt/KVM, at least 64 GiB RAM and 1 TiB free disk. The lab uses a single HPE DL385 (dl385-2) running Ubuntu 24.04 with the default, hpe-vme-compute, and hpe-vme-storage libvirt networks.
• An Ubuntu 24.04 base image as a libvirt backing file (/var/lib/libvirt/images/ubuntu-24.04-base.qcow2).
• Outbound internet from the hypervisor only (you’ll mirror through it, never from the cluster).
• A valid Red Hat customer pull secret from console.redhat.com.

To follow the concepts on any infra:

• Any hypervisor or bare-metal pair that can host 3 control-plane + 0-3 worker nodes.
• A VM or container host for the mirror registry (Quay, Harbor, Nexus, or oc-mirror’s built-in mirror-registry — the patterns translate).

The lab this track was written against runs on dl385-2 as the hypervisor with a fleet of VMs named gf-ocp-* (DNS at gf-ocp-pdns-01, HAProxy at gf-ocp-haproxy-01, GitLab at gf-ocp-gitlab-01, Vault three-node Raft at gf-ocp-vault-r1-0[123], MinIO and a NetBox CMDB, the Quay mirror at gf-ocp-quay-01, and the gf-ocp-bootstrap-01 operator render host). The target clusters are gf-ocp-hub-dc-v7-master-0..2 (compact hub) and gf-ocp-spoke-dc-v7-master-0..2 (workload).

Where this track lives in the bigger picture

This track teaches disconnected OpenShift deployment as a discipline — what each Day-1 manifest does, why the install needs imageDigestSources, why an oc-mirror rerun changes catalog digests, why FEATURE_EXTENDED_REPOSITORY_NAMES: true is non-negotiable for Quay. The track is portable: every example works against any OCP 4.16+ disconnected install using either Quay or Harbor as a mirror registry, with oc-mirror v2 as the mirror runner.

The lab’s own implementation — names of VMs, choice of Quay over Nexus, MinIO bucket layout, Vault custody paths — is documented separately under /docs/openshift-platform/ (the v6 fleet, Nexus-based) and the work-in-progress /docs/greenfield-ocp-deployment/ installation manual (the v7 fleet, Quay-based, what this track tracks closely).

Two ADRs do a lot of the load-bearing thinking:

• Image supply — the lab’s image-supply chain decision (v6 used Nexus three-endpoint, v7 uses Quay standalone). The “why standalone instead of operator-on-cluster” is in the v7 runbook on dl385-2:~/ocp-greenfield-deployment/runbooks/quay-v7.md.
• IPv6 baseline for OVN-Kubernetes — disabling IPv6 at the kernel-arg or sysctl level crash-loops ovnkube-controller. The right knob is agent-config.yaml’s per-interface ipv6.enabled: false. This is covered in /docs/openshift-platform/architecture-decisions/adr-0026-ipv6-baseline-for-ovn-kubernetes/.

The split is deliberate: the track teaches you disconnected install as a portable discipline, the docs show you one lab’s wire-up. Read both if you want to see how the abstract concepts get pinned to concrete YAML.

A note on what’s not here

This track doesn’t cover:

• Day-0 sizing — choosing master/worker CPU, memory, disk, NIC layout. Sizing is workload-dependent and is well covered in Red Hat’s reference architectures.
• agent-based-installer deep internals — the assisted-service controller, the rendezvous gossip protocol, the post-install pivot. The track shows you how to drive the installer, not how it implements itself.
• Cluster lifecycle and multicluster management — that’s the ACM Multicluster track. This track ends at “a healthy disconnected cluster handed off to GitOps.”
• Application delivery, RHACS, ODF, networking, observability — covered by the /docs/openshift-platform/ reference.

The goal is to make you the engineer who can stand up, secure, and operate a disconnected OpenShift cluster — not the one who can recite every CRD oc-mirror ships.

Ready? Continue to Module 01 — Foundations.