Chapter 14. Deploying installer-provisioned clusters on bare metal

1. Two unique virtual IP addresses.

   • One virtual IP address for the API endpoint.
   • One virtual IP address for the wildcard ingress endpoint.
2. One IP address for the provisioner node.
3. One IP address for each control plane node.
4. One IP address for each worker node, if applicable.

1. Configure

   install-config.yaml

   . Change the appropriate variables to match the environment, including

   pullSecret

   and

   sshKey

   :

   apiVersion: v1
   baseDomain: <domain>
   metadata:
     name: <cluster_name>
   networking:
     machineNetwork:
     - cidr: <public_cidr>
     networkType: OVNKubernetes
   compute:
   - name: worker
     replicas: 2 

   1

   
   controlPlane:
     name: master
     replicas: 3
     platform:
       baremetal: {}
   platform:
     baremetal:
       apiVIP: <api_ip>
       ingressVIP: <wildcard_ip>
       provisioningNetworkCIDR: <CIDR>
       bootstrapExternalStaticIP: <bootstrap_static_ip_address> 

   2

   
       bootstrapExternalStaticGateway: <bootstrap_static_gateway> 

   3

   
       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: ipmi://<out_of_band_ip> 

   4

   
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>" 

   5

   
         - name: <openshift_master_1>
           role: master
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
         - name: <openshift_master_2>
           role: master
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
         - name: <openshift_worker_0>
           role: worker
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
         - name: <openshift_worker_1>
           role: worker
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
   pullSecret: '<pull_secret>'
   sshKey: '<ssh_pub_key>'

   1

   Scale the worker machines based on the number of worker nodes that are part of the OpenShift Container Platform cluster. Valid options for the replicas value are 0 and integers greater than or equal to 2. Set the number of replicas to 0 to deploy a three-node cluster, which contains only three control plane machines. A three-node cluster is a smaller, more resource-efficient cluster that can be used for testing, development, and production. You cannot install the cluster with only one worker.

   2

   When deploying a cluster with static IP addresses, you must set the bootstrapExternalStaticIP configuration setting to specify the static IP address of the bootstrap VM when there is no DHCP server on the bare-metal network.

   3

   When deploying a cluster with static IP addresses, you must set the bootstrapExternalStaticGateway configuration setting to specify the gateway IP address for the bootstrap VM when there is no DHCP server on the bare-metal network.

   4

   See the BMC addressing sections for more options.

   5

   To set the path to the installation disk drive, enter the kernel name of the disk. For example, /dev/sda.

   Important

   Because the disk discovery order is not guaranteed, the kernel name of the disk can change across booting options for machines with multiple disks. For instance,

   /dev/sda

   becomes

   /dev/sdb

   and vice versa. To avoid this issue, you must use persistent disk attributes, such as the disk World Wide Name (WWN). To use the disk WWN, replace the

   deviceName

   parameter with the

   wwnWithExtension

   parameter. Depending on the parameter that you use, enter the disk name, for example,

   /dev/sda

   or the disk WWN, for example,

   "0x64cd98f04fde100024684cf3034da5c2"

   . Ensure that you enter the disk WWN value within quotes so that it is used as a string value and not a hexadecimal value.

   Failure to meet these requirements for the

   rootDeviceHints

   parameter might result in the following error:

   ironic-inspector inspection failed: No disks satisfied root device hints

2. Create a directory to store the cluster configuration:

   $ mkdir ~/clusterconfigs

3. Copy the

   install-config.yaml

   file to the new directory:

   $ cp install-config.yaml ~/clusterconfigs

4. Ensure all bare metal nodes are powered off prior to installing the OpenShift Container Platform cluster:

   $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off

5. Remove old bootstrap resources if any are left over from a previous deployment attempt:

   for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
   do
     sudo virsh destroy $i;
     sudo virsh undefine $i;
     sudo virsh vol-delete $i --pool $i;
     sudo virsh vol-delete $i.ign --pool $i;
     sudo virsh pool-destroy $i;
     sudo virsh pool-undefine $i;
   done

Procedure

1. Optional: Consider testing the NMState syntax with

   nmstatectl gc

   before including it in the

   install-config.yaml

   file, because the installer will not check the NMState YAML syntax.
   Note

   Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes using Kubernetes NMState after deployment or when expanding the cluster.

   1. Create an NMState YAML file:

      interfaces:
      - name: <nic1_name> 

      1

      
        type: ethernet
        state: up
        ipv4:
          address:
          - ip: <ip_address> 

      2

      
            prefix-length: 24
          enabled: true
      dns-resolver:
        config:
          server:
          - <dns_ip_address> 

      3

      
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-address: <next_hop_ip_address> 

      4

      
          next-hop-interface: <next_hop_nic1_name> 

      5

      1 2 3 4 5

      Replace <nic1_name>, <ip_address>, <dns_ip_address>, <next_hop_ip_address> and <next_hop_nic1_name> with appropriate values.

   2. Test the configuration file by running the following command:

      $ nmstatectl gc <nmstate_yaml_file>

      Replace

      <nmstate_yaml_file>

      with the configuration file name.

2. Use the

   networkConfig

   configuration setting by adding the NMState configuration to hosts within the

   install-config.yaml

   file:

       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
             username: <user>
             password: <password>
             disableCertificateVerification: null
           bootMACAddress: <NIC1_mac_address>
           bootMode: UEFI
           rootDeviceHints:
             deviceName: "/dev/sda"
           networkConfig: 

   1

   
             interfaces:
             - name: <nic1_name> 

   2

   
               type: ethernet
               state: up
               ipv4:
                 address:
                 - ip: <ip_address> 

   3

   
                   prefix-length: 24
                 enabled: true
             dns-resolver:
               config:
                 server:
                 - <dns_ip_address> 

   4

   
             routes:
               config:
               - destination: 0.0.0.0/0
                 next-hop-address: <next_hop_ip_address> 

   5

   
                 next-hop-interface: <next_hop_nic1_name> 

   6

   1

   Add the NMState YAML syntax to configure the host interfaces.

   2 3 4 5 6

   Replace <nic1_name>, <ip_address>, <dns_ip_address>, <next_hop_ip_address> and <next_hop_nic1_name> with appropriate values.

   Important

   After deploying the cluster, you cannot modify the

   networkConfig

   configuration setting of

   install-config.yaml

   file to make changes to the host network interface. Use the Kubernetes NMState Operator to make changes to the host network interface after deployment.

Procedure

1. Add the subnets to the

   machineNetwork

   in the

   install-config.yaml

   file when using static IP addresses:

   networking:
     machineNetwork:
     - cidr: 10.0.0.0/24
     - cidr: 192.168.0.0/24
     networkType: OVNKubernetes

2. Add the gateway and DNS configuration to the

   networkConfig

   parameter of each edge worker node using NMState syntax when using a static IP address or advanced networking such as bonds:

   networkConfig:
     nmstate:
       interfaces:
       - name: <interface_name> 

   1

   
         type: ethernet
         state: up
         ipv4:
           enabled: true
           dhcp: false
           address:
           - ip: <node_ip> 

   2

   
             prefix-length: 24
           gateway: <gateway_ip> 

   3

   
           dns-resolver:
             config:
               server:
               - <dns_ip> 

   4

   1

   Replace <interface_name> with the interface name.

   2

   Replace <node_ip> with the IP address of the node.

   3

   Replace <gateway_ip> with the IP address of the gateway.

   4

   Replace <dns_ip> with the IP address of the DNS server.

Procedure

1. Optional: Consider testing the NMState YAML syntax with the

   nmstatectl gc

   command before including it in the

   install-config.yaml

   file because the installation program will not check the NMState YAML syntax.

   1. Create an NMState YAML file:

      interfaces:
      - name: eth0
        ipv6:
          addr-gen-mode: <address_mode> 

      1

      1

      Replace <address_mode> with the type of address generation mode required for IPv6 addresses in the cluster. Valid values are eui64, stable-privacy, or random.

   2. Test the configuration file by running the following command:

      $ nmstatectl gc <nmstate_yaml_file> 

      1

      1

      Replace <nmstate_yaml_file> with the name of the test configuration file.

2. Add the NMState configuration to the

   hosts.networkConfig

   section within the install-config.yaml file:

       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
             username: <user>
             password: <password>
             disableCertificateVerification: null
           bootMACAddress: <NIC1_mac_address>
           bootMode: UEFI
           rootDeviceHints:
             deviceName: "/dev/sda"
           networkConfig:
             interfaces:
             - name: eth0
               ipv6:
                 addr-gen-mode: <address_mode> 

   1

   
   ...

   1

   Replace <address_mode> with the type of address generation mode required for IPv6 addresses in the cluster. Valid values are eui64, stable-privacy, or random.

1. Create the OpenShift Container Platform manifests.

   $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests

   INFO Consuming Install Config from target directory
   WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
   WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated

Procedure

1. Create a Butane config,

   99-master-chrony-conf-override.bu

   , including the contents of the

   chrony.conf

   file for the control plane nodes.
   Note

   See "Creating machine configs with Butane" for information about Butane.

   Butane config example

   variant: openshift
   version: 4.11.0
   metadata:
     name: 99-master-chrony-conf-override
     labels:
       machineconfiguration.openshift.io/role: master
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             # Use public servers from the pool.ntp.org project.
             # Please consider joining the pool (https://www.pool.ntp.org/join.html).
   
             # The Machine Config Operator manages this file
             server openshift-master-0.<cluster-name>.<domain> iburst 

   1

   
             server openshift-master-1.<cluster-name>.<domain> iburst
             server openshift-master-2.<cluster-name>.<domain> iburst
   
             stratumweight 0
             driftfile /var/lib/chrony/drift
             rtcsync
             makestep 10 3
             bindcmdaddress 127.0.0.1
             bindcmdaddress ::1
             keyfile /etc/chrony.keys
             commandkey 1
             generatecommandkey
             noclientlog
             logchange 0.5
             logdir /var/log/chrony
   
             # Configure the control plane nodes to serve as local NTP servers
             # for all worker nodes, even if they are not in sync with an
             # upstream NTP server.
   
             # Allow NTP client access from the local network.
             allow all
             # Serve time even if not synchronized to a time source.
             local stratum 3 orphan

   1

   You must replace <cluster-name> with the name of the cluster and replace <domain> with the fully qualified domain name.

2. Use Butane to generate a

   MachineConfig

   object file,

   99-master-chrony-conf-override.yaml

   , containing the configuration to be delivered to the control plane nodes:

   $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml

3. Create a Butane config,

   99-worker-chrony-conf-override.bu

   , including the contents of the

   chrony.conf

   file for the worker nodes that references the NTP servers on the control plane nodes.

   Butane config example

   variant: openshift
   version: 4.11.0
   metadata:
     name: 99-worker-chrony-conf-override
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             # The Machine Config Operator manages this file.
             server openshift-master-0.<cluster-name>.<domain> iburst 

   1

   
             server openshift-master-1.<cluster-name>.<domain> iburst
             server openshift-master-2.<cluster-name>.<domain> iburst
   
             stratumweight 0
             driftfile /var/lib/chrony/drift
             rtcsync
             makestep 10 3
             bindcmdaddress 127.0.0.1
             bindcmdaddress ::1
             keyfile /etc/chrony.keys
             commandkey 1
             generatecommandkey
             noclientlog
             logchange 0.5
             logdir /var/log/chrony

   1

   You must replace <cluster-name> with the name of the cluster and replace <domain> with the fully qualified domain name.

4. Use Butane to generate a

   MachineConfig

   object file,

   99-worker-chrony-conf-override.yaml

   , containing the configuration to be delivered to the worker nodes:

   $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml

Procedure

1. Change to the directory storing the

   install-config.yaml

   file:

   $ cd ~/clusterconfigs

2. Switch to the

   manifests

   subdirectory:

   $ cd manifests

3. Create a file named

   cluster-network-avoid-workers-99-config.yaml

   :

   $ touch cluster-network-avoid-workers-99-config.yaml

4. Open the

   cluster-network-avoid-workers-99-config.yaml

   file in an editor and enter a custom resource (CR) that describes the Operator configuration:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: 50-worker-fix-ipi-rwn
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
           - path: /etc/kubernetes/manifests/keepalived.yaml
             mode: 0644
             contents:
               source: data:,

   This manifest places the

   ingressVIP

   virtual IP address on the control plane nodes. Additionally, this manifest deploys the following processes on the control plane nodes only:

   • openshift-ingress-operator

   • keepalived

5. Save the

   cluster-network-avoid-workers-99-config.yaml

   file.

6. Create a

   manifests/cluster-ingress-default-ingresscontroller.yaml

   file:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     nodePlacement:
       nodeSelector:
         matchLabels:
           node-role.kubernetes.io/master: ""

7. Consider backing up the

   manifests

   directory. The installer deletes the

   manifests/

   directory when creating the cluster.

8. Modify the

   cluster-scheduler-02-config.yml

   manifest to make the control plane nodes schedulable by setting the

   mastersSchedulable

   field to

   true

   . Control plane nodes are not schedulable by default. For example:

   $ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml

   Note

   If control plane nodes are not schedulable after completing this procedure, deploying the cluster will fail.

Procedure

1. Create a

   router-replicas.yaml

   file:

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: <num-of-router-pods>
     endpointPublishingStrategy:
       type: HostNetwork
     nodePlacement:
       nodeSelector:
         matchLabels:
           node-role.kubernetes.io/worker: ""

   Note

   Replace

   <num-of-router-pods>

   with an appropriate value. If working with just one worker node, set

   replicas:

   to

   1

   . If working with more than 3 worker nodes, you can increase

   replicas:

   from the default value

   2

   as appropriate.

2. Save and copy the

   router-replicas.yaml

   file to the

   clusterconfigs/openshift

   directory:

   $ cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml

Procedure

1. Create the manifests.

2. Modify the

   BareMetalHost

   resource file corresponding to the node:

   $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml

3. Add the BIOS configuration to the

   spec

   section of the

   BareMetalHost

   resource:

   spec:
     firmware:
       simultaneousMultithreadingEnabled: true
       sriovEnabled: true
       virtualizationEnabled: true

   Note

   Red Hat supports three BIOS configurations. Only servers with BMC type

   irmc

   are supported. Other types of servers are currently not supported.

4. Create the cluster.

Procedure

1. Create the manifests.

2. Modify the

   BareMetalHost

   resource corresponding to the node:

   $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml

   Note

   The following example uses a hardware RAID configuration because OpenShift Container Platform 4.11 does not support software RAID.

   1. If you added a specific RAID configuration to the

      spec

      section, this causes the node to delete the original RAID configuration in the

      preparing

      phase and perform a specified configuration on the RAID. For example:

      spec:
        raid:
          hardwareRAIDVolumes:
          - level: "0" 

      1

      
            name: "sda"
            numberOfPhysicalDisks: 1
            rotational: true
            sizeGibibytes: 0

      1

      level is a required field, and the others are optional fields.

   2. If you added an empty RAID configuration to the

      spec

      section, the empty configuration causes the node to delete the original RAID configuration during the

      preparing

      phase, but does not perform a new configuration. For example:

      spec:
        raid:
          hardwareRAIDVolumes: []

   3. If you do not add a

      raid

      field in the

      spec

      section, the original RAID configuration is not deleted, and no new configuration will be performed.
3. Create the cluster.

Procedure

1. Open the firewall port on the registry node:

   $ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent

   $ sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent

   $ sudo firewall-cmd --reload

2. Install the required packages for the registry node:

   $ sudo yum -y install python3 podman httpd httpd-tools jq

3. Create the directory structure where the repository information will be held:

   $ sudo mkdir -p /opt/registry/{auth,certs,data}

Procedure

1. Review the OpenShift Container Platform downloads page to determine the version of OpenShift Container Platform that you want to install and determine the corresponding tag on the Repository Tags page.

2. Set the required environment variables:

   1. Export the release version:

      $ OCP_RELEASE=<release_version>

      For

      <release_version>

      , specify the tag that corresponds to the version of OpenShift Container Platform to install, such as

      4.5.4

      .

   2. Export the local registry name and host port:

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      For

      <local_registry_host_name>

      , specify the registry domain name for your mirror repository, and for

      <local_registry_host_port>

      , specify the port that it serves content on.

   3. Export the local repository name:

      $ LOCAL_REPOSITORY='<local_repository_name>'

      For

      <local_repository_name>

      , specify the name of the repository to create in your registry, such as

      ocp4/openshift4

      .

   4. Export the name of the repository to mirror:

      $ PRODUCT_REPO='openshift-release-dev'

      For a production release, you must specify

      openshift-release-dev

      .

   5. Export the path to your registry pull secret:

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      For

      <path_to_pull_secret>

      , specify the absolute path to and file name of the pull secret for your mirror registry that you created.

   6. Export the release mirror:

      $ RELEASE_NAME="ocp-release"

      For a production release, you must specify

      ocp-release

      .

   7. Export the type of architecture for your server, such as

      x86_64

      :

      $ ARCHITECTURE=<server_architecture>

   8. Export the path to the directory to host the mirrored images:

      $ REMOVABLE_MEDIA_PATH=<path> 

      1

      1

      Specify the full path, including the initial forward slash (/) character.

3. Mirror the version images to the mirror registry:

   • If your mirror host does not have internet access, take the following actions:

     1. Connect the removable media to a system that is connected to the internet.

     2. Review the images and configuration manifests to mirror:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run

     3. Record the entire

        imageContentSources

        section from the output of the previous command. The information about your mirrors is unique to your mirrored repository, and you must add the

        imageContentSources

        section to the

        install-config.yaml

        file during installation.

     4. Mirror the images to a directory on the removable media:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}

     5. Take the media to the restricted network environment and upload the images to the local container registry.

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 

        1

        1

        For REMOVABLE_MEDIA_PATH, you must use the same path that you specified when you mirrored the images.

   • If the local container registry is connected to the mirror host, take the following actions:

     1. Directly push the release images to the local registry by using following command:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

        This command pulls the release information as a digest, and its output includes the

        imageContentSources

        data that you require when you install your cluster.

     2. Record the entire

        imageContentSources

        section from the output of the previous command. The information about your mirrors is unique to your mirrored repository, and you must add the

        imageContentSources

        section to the

        install-config.yaml

        file during installation.
        Note

        The image name gets patched to Quay.io during the mirroring process, and the podman images will show Quay.io in the registry on the bootstrap virtual machine.

4. To create the installation program that is based on the content that you mirrored, extract it and pin it to the release:

   • If your mirror host does not have internet access, run the following command:

     $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"

   • If the local container registry is connected to the mirror host, run the following command:

     $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

     Important

     To ensure that you use the correct images for the version of OpenShift Container Platform that you selected, you must extract the installation program from the mirrored content.

     You must perform this step on a machine with an active internet connection.

     If you are in a disconnected environment, use the

     --image

     flag as part of must-gather and point to the payload image.

5. For clusters using installer-provisioned infrastructure, run the following command:

   $ openshift-baremetal-install

Procedure

1. Add the disconnected registry node’s certificate to the

   install-config.yaml

   file:

   $ echo "additionalTrustBundle: |" >> install-config.yaml

   The certificate should follow the

   "additionalTrustBundle: |"

   line and be properly indented, usually by two spaces.

   $ sed -e 's/^/  /' /opt/registry/certs/domain.crt >> install-config.yaml

2. Add the mirror information for the registry to the

   install-config.yaml

   file:

   $ echo "imageContentSources:" >> install-config.yaml

   $ echo "- mirrors:" >> install-config.yaml

   $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml

   Replace

   registry.example.com

   with the registry’s fully qualified domain name.

   $ echo "  source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml

   $ echo "- mirrors:" >> install-config.yaml

   $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml

   Replace

   registry.example.com

   with the registry’s fully qualified domain name.

   $ echo "  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml