OpenShift Cluster Install Config Generator

Generate install-config.yaml and agent-config.yaml for a compact, user-provisioned OpenShift cluster.

0. Choose your installation approach

Use this guide to decide the best OpenShift installation path before filling full cluster details.

OpenShift installation flow

Use the choices on the right to pick where you install and who provisions the machines. Then get a recommended method and platform before you fill in cluster details.

  1. 1. Where (on-prem / cloud)
  2. 2. Who provisions (UPI / IPI)
  3. 3. Connected?
  4. 4. Recommendation
  5. 5. Generate configs

UPI

You provide hosts/VMs and networking (DNS, load balancers).

IPI

Installer creates machines (needs platform credentials).

Prerequisites planner (before you install)

If you are new to OpenShift, review this checklist before you run the installer. Choose the scenario that best matches your environment.

Production-like environment

Mirror registry setup (disconnected)

Enterprises often block Assisted / connected installs because firewall teams must whitelist many Red Hat endpoints. A dedicated mirror registry lets you pull once from the internet on a bastion, then install the cluster from an internal registry only.

This guide follows Red Hat’s mirror registry for Red Hat OpenShift (a small Quay-based appliance included with an OpenShift subscription). It is for bootstrapping disconnected clusters — not a HA production Quay.

1. Prerequisites

2. Download the installer

  1. Download mirror-registry from the OpenShift console Downloads page (included with your subscription), or from the quay/mirror-registry releases.
  2. Copy the archive to the registry host and unpack it so ./mirror-registry is executable.

3. Install on the local host

Replace the hostname and install directory with your values:

./mirror-registry install \
  --quayHostname mirror.example.com \
  --quayRoot $HOME/quay-install

The installer creates local storage/config under --quayRoot, systemd units for persistence, and an initial user named init with a generated password (printed at the end — save it).

4. Optional: install on a remote host

./mirror-registry install -v \
  --targetHostname mirror.example.com \
  --targetUsername someuser \
  --ssh-key ~/.ssh/id_rsa \
  --quayHostname mirror.example.com \
  --quayRoot /home/someuser/quay-install

5. Log in and trust the certificate

Prefer trusting the generated root CA long term. For a first smoke test you can use --tls-verify=false (not recommended permanently):

podman login -u init \
  -p '<password-from-install>' \
  mirror.example.com:8443 \
  --tls-verify=false

UI: https://mirror.example.com:8443. Add the registry CA to this app’s additionalTrustBundle placeholder later when you generate install-config.yaml.

6. Wire this registry into the generator

7. What to mirror next

  1. On a connected bastion that can reach both the internet and this registry, log in to registry.redhat.io and to your mirror.
  2. Mirror the OpenShift release payload (required to install).
  3. Optionally mirror Operators with the operator-mirror-config.yaml this app generates (day-2 OperatorHub — not required to bring the cluster up).
  4. Copy the resulting ImageContentSourcePolicy / mirror mappings into your install config (this app provides placeholders under Disconnected).

8. Already have an enterprise registry?

If you already run Quay, Harbor, Artifactory, Nexus, or another Docker v2-2 registry reachable from the cluster, you can skip installing the appliance. Point “Mirror registry host” at that registry and trust its CA. The rest of the oc-mirror workflow is the same.

Official references

1. Installation profile

2. Cluster basics

Sensitive value: you can add or update this later in generated install-config.yaml.

Sensitive value: you can add or update this later in generated install-config.yaml.

Pre-requisites execution planner

Use this page to sketch concrete DNS, VIP, and firewall values for your environment. Examples are dummy values — replace them with your own.

Production: example values

DNS records

NameTypeValuePurpose
api.ocp4.lab.example.com A 192.168.50.5 API VIP (port 6443)
api-int.ocp4.lab.example.com A 192.168.50.5 Internal API / machine config (22623)
*.apps.ocp4.lab.example.com Wildcard 192.168.50.6 Ingress VIP (80/443)
master-0.ocp4.lab.example.com A 192.168.50.10 Control plane node 1
master-1.ocp4.lab.example.com A 192.168.50.11 Control plane node 2
master-2.ocp4.lab.example.com A 192.168.50.12 Control plane node 3
worker-0.ocp4.lab.example.com A 192.168.50.20 Worker node 1
worker-1.ocp4.lab.example.com A 192.168.50.21 Worker node 2

Load balancer backend mapping

LB FQDNVIPPortsBackends (example nodes)
api.ocp4.lab.example.com 192.168.50.5 6443 master-0, master-1, master-2
api-int.ocp4.lab.example.com 192.168.50.5 22623 master-0, master-1, master-2
*.apps.ocp4.lab.example.com 192.168.50.6 80, 443 worker-0, worker-1

Firewall ports (summary)

SourceDestinationPort/ProtocolReason
Admins / automation api.ocp4.lab.example.com 6443/TCP Kubernetes API access
Cluster nodes api-int.ocp4.lab.example.com 22623/TCP Machine config server
Users / browsers *.apps.ocp4.lab.example.com 80,443/TCP App and console ingress

3. Platform configuration

Platform-specific install details for the platform chosen in Installation profile (vSphere, Nutanix, AWS, or Azure). Bare Metal (none) has nothing to configure here and this step is skipped automatically when you use Next/Back.

4. Hosts (masters/workers)

For a compact cluster, define three master hosts and zero workers.

Hostname Role IP MAC Primary NIC Bond? Secondary NIC Secondary MAC Static IP? Gateway DNS servers (comma)

Required for agent-based installs. Optional for UPI/IPI.

5. Review and generate

Compact cluster, bare metal / agent-based

6. Generated YAML

install-config.yaml

agent-config.yaml

oc-mirror ImageSetConfiguration (operators)

6. What to do next

After generating YAML:

6. Commands to run

Copy these commands and run them on your jump host / workstation as indicated.

Step 1 of 7