- Preparing the hub cluster for ZTP
- Telco RAN 4.13 validated solution software versions
- Installing GitOps ZTP in a disconnected environment
- Adding FCOS ISO and RootFS images to the disconnected mirror host
- Enabling the assisted service and updating AgentServiceConfig on the hub cluster
- Configuring the hub cluster to use a disconnected mirror registry
- Configuring the hub cluster to use unauthenticated registries
- Configuring the hub cluster with ArgoCD
- Preparing the GitOps ZTP site configuration repository
Preparing the hub cluster for ZTP
To use RHACM in a disconnected environment, create a mirror registry that mirrors the OKD release images and Operator Lifecycle Manager (OLM) catalog that contains the required Operator images. OLM manages, installs, and upgrades Operators and their dependencies in the cluster. You can also use a disconnected mirror host to serve the FCOS ISO and RootFS disk images that are used to provision the bare-metal hosts.
Telco RAN 4.13 validated solution software versions
The Red Hat Telco Radio Access Network (RAN) version 4.13 solution has been validated using the following Red Hat software products.
Product | Software version |
---|---|
Hub cluster OKD version | 4.13 |
GitOps ZTP plugin | 4.11, 4.12, or 4.13 |
Red Hat Advanced Cluster Management (RHACM) | 2.7 |
Red Hat OpenShift GitOps | 1.6 |
Topology Aware Lifecycle Manager (TALM) | 4.11, 4.12, or 4.13 |
Installing GitOps ZTP in a disconnected environment
Use Red Hat Advanced Cluster Management (RHACM), Red Hat OpenShift GitOps, and Topology Aware Lifecycle Manager (TALM) on the hub cluster in the disconnected environment to manage the deployment of multiple managed clusters.
Prerequisites
You have installed the OKD CLI (
oc
).You have logged in as a user with
cluster-admin
privileges.You have configured a disconnected mirror registry for use in the cluster.
The disconnected mirror registry that you create must contain a version of TALM backup and pre-cache images that matches the version of TALM running in the hub cluster. The spoke cluster must be able to resolve these images in the disconnected mirror registry.
Procedure
Install RHACM in the hub cluster. See Installing RHACM in a disconnected environment.
Install GitOps and TALM in the hub cluster.
Additional resources
Adding FCOS ISO and RootFS images to the disconnected mirror host
Before you begin installing clusters in the disconnected environment with Red Hat Advanced Cluster Management (RHACM), you must first host Fedora CoreOS (FCOS) images for it to use. Use a disconnected mirror to host the FCOS images.
Prerequisites
- Deploy and configure an HTTP server to host the FCOS image resources on the network. You must be able to access the HTTP server from your computer, and from the machines that you create.
The FCOS images might not change with every release of OKD. You must download images with the highest version that is less than or equal to the version that you install. Use the image versions that match your OKD version if they are available. You require ISO and RootFS images to install FCOS on the hosts. FCOS QCOW2 images are not supported for this installation type. |
Procedure
Log in to the mirror host.
Obtain the FCOS ISO and RootFS images from mirror.openshift.com, for example:
Export the required image names and OKD version as environment variables:
$ export ISO_IMAGE_NAME=<iso_image_name> (1)
$ export ROOTFS_IMAGE_NAME=<rootfs_image_name> (2)
$ export OCP_VERSION=<ocp_version> (3)
1 ISO image name, for example, rhcos-4.13.1-x86_64-live.x86_64.iso
2 RootFS image name, for example, rhcos-4.13.1-x86_64-live-rootfs.x86_64.img
3 OKD version, for example, 4.13.1
Download the required images:
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.13/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.13/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}
Verification steps
Verify that the images downloaded successfully and are being served on the disconnected mirror host, for example:
$ wget http://$(hostname)/${ISO_IMAGE_NAME}
Example output
Saving to: rhcos-4.13.1-x86_64-live.x86_64.iso
rhcos-4.13.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/s
Additional resources
Enabling the assisted service and updating AgentServiceConfig on the hub cluster
Red Hat Advanced Cluster Management (RHACM) uses the assisted service to deploy OKD clusters. The assisted service is deployed automatically when you enable the MultiClusterHub Operator with Central Infrastructure Management (CIM). When you have enabled CIM on the hub cluster, you then need to update the AgentServiceConfig
custom resource (CR) with references to the ISO and RootFS images that are hosted on the mirror registry HTTP server.
Prerequisites
You have installed the OpenShift CLI (
oc
).You have logged in to the hub cluster as a user with
cluster-admin
privileges.You have enabled the assisted service on the hub cluster. For more information, see Enabling the Central Infrastructure Management Service.
Procedure
Update the
AgentServiceConfig
CR by running the following command:$ oc edit AgentServiceConfig
Add the following entry to the
items.spec.osImages
field in the CR:- cpuArchitecture: x86_64
openshiftVersion: "4.13"
rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso
where:
<host>
Is the fully qualified domain name (FQDN) for the target mirror registry HTTP server.
<path>
Is the path to the image on the target mirror registry.
Save and quit the editor to apply the changes.
Configuring the hub cluster to use a disconnected mirror registry
You can configure the hub cluster to use a disconnected mirror registry for a disconnected environment.
Prerequisites
You have a disconnected hub cluster installation with Red Hat Advanced Cluster Management (RHACM) 2.5 installed.
You have hosted the
rootfs
andiso
images on an HTTP server.
If you enable TLS for the HTTP server, you must confirm the root certificate is signed by an authority trusted by the client and verify the trusted certificate chain between your OKD hub and managed clusters and the HTTP server. Using a server configured with an untrusted certificate prevents the images from being downloaded to the image creation service. Using untrusted HTTPS servers is not supported. |
Procedure
Create a
ConfigMap
containing the mirror registry config:apiVersion: v1
kind: ConfigMap
metadata:
name: assisted-installer-mirror-config
namespace: assisted-installer
labels:
app: assisted-service
data:
ca-bundle.crt: <certificate> (1)
registries.conf: | (2)
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
[[registry]]
location = <mirror_registry_url> (3)
insecure = false
mirror-by-digest-only = true
1 The mirror registry’s certificate used when creating the mirror registry. 2 The configuration file for the mirror registry. The mirror registry configuration adds mirror information to /etc/containers/registries.conf
in the Discovery image. The mirror information is stored in theimageContentSources
section of theinstall-config.yaml
file when passed to the installation program. The Assisted Service pod running on the HUB cluster fetches the container images from the configured mirror registry.3 The URL of the mirror registry. This updates
mirrorRegistryRef
in theAgentServiceConfig
custom resource, as shown below:Example output
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
name: agent
namespace: assisted-installer
spec:
databaseStorage:
volumeName: <db_pv_name>
accessModes:
- ReadWriteOnce
resources:
requests:
storage: <db_storage_size>
filesystemStorage:
volumeName: <fs_pv_name>
accessModes:
- ReadWriteOnce
resources:
requests:
storage: <fs_storage_size>
mirrorRegistryRef:
name: 'assisted-installer-mirror-config'
osImages:
- openshiftVersion: <ocp_version>
rootfs: <rootfs_url> (1)
url: <iso_url> (1)
1 Must match the URLs of the HTTPD server.
A valid NTP server is required during cluster installation. Ensure that a suitable NTP server is available and can be reached from the installed clusters through the disconnected network. |
Configuring the hub cluster to use unauthenticated registries
You can configure the hub cluster to use unauthenticated registries. Unauthenticated registries does not require authentication to access and download images.
Prerequisites
You have installed and configured a hub cluster and installed Red Hat Advanced Cluster Management (RHACM) on the hub cluster.
You have installed the OpenShift Container Platform CLI (oc).
You have logged in as a user with
cluster-admin
privileges.You have configured an unauthenticated registry for use with the hub cluster.
Procedure
Update the
AgentServiceConfig
custom resource (CR) by running the following command:$ oc edit AgentServiceConfig agent
Add the
unauthenticatedRegistries
field in the CR:apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
name: agent
spec:
unauthenticatedRegistries:
- example.registry.com
- example.registry2.com
...
Unauthenticated registries are listed under
spec.unauthenticatedRegistries
in theAgentServiceConfig
resource. Any registry on this list is not required to have an entry in the pull secret used for the spoke cluster installation.assisted-service
validates the pull secret by making sure it contains the authentication information for every image registry used for installation.
Mirror registries are automatically added to the ignore list and do not need to be added under |
Verification
Verify that you can access the newly added registry from the hub cluster by running the following commands:
Open a debug shell prompt to the hub cluster:
$ oc debug node/<node_name>
Test access to the unauthenticated registry by running the following command:
sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>
where:
<unauthenticated_registry>
Is the new registry, for example,
unauthenticated-image-registry.openshift-image-registry.svc:5000
.Example output
Login Succeeded!
Configuring the hub cluster with ArgoCD
You can configure the hub cluster with a set of ArgoCD applications that generate the required installation and policy custom resources (CRs) for each site with GitOps Zero Touch Provisioning (ZTP).
Red Hat Advanced Cluster Management (RHACM) uses |
Prerequisites
You have a OKD hub cluster with Red Hat Advanced Cluster Management (RHACM) and Red Hat OpenShift GitOps installed.
You have extracted the reference deployment from the GitOps ZTP plugin container as described in the “Preparing the GitOps ZTP site configuration repository” section. Extracting the reference deployment creates the
out/argocd/deployment
directory referenced in the following procedure.
Procedure
Prepare the ArgoCD pipeline configuration:
Create a Git repository with the directory structure similar to the example directory. For more information, see “Preparing the GitOps ZTP site configuration repository”.
Configure access to the repository using the ArgoCD UI. Under Settings configure the following:
Repositories - Add the connection information. The URL must end in
.git
, for example,[https://repo.example.com/repo.git](https://repo.example.com/repo.git)
and credentials.Certificates - Add the public certificate for the repository, if needed.
Modify the two ArgoCD applications,
out/argocd/deployment/clusters-app.yaml
andout/argocd/deployment/policies-app.yaml
, based on your Git repository:Update the URL to point to the Git repository. The URL ends with
.git
, for example,[https://repo.example.com/repo.git](https://repo.example.com/repo.git)
.The
targetRevision
indicates which Git repository branch to monitor.path
specifies the path to theSiteConfig
andPolicyGenTemplate
CRs, respectively.
To install the GitOps ZTP plugin you must patch the ArgoCD instance in the hub cluster by using the patch file previously extracted into the
out/argocd/deployment/
directory. Run the following command:$ oc patch argocd openshift-gitops \
-n openshift-gitops --type=merge \
--patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
Apply the pipeline configuration to your hub cluster by using the following command:
$ oc apply -k out/argocd/deployment
Preparing the GitOps ZTP site configuration repository
Before you can use the GitOps Zero Touch Provisioning (ZTP) pipeline, you need to prepare the Git repository to host the site configuration data.
Prerequisites
You have configured the hub cluster GitOps applications for generating the required installation and policy custom resources (CRs).
You have deployed the managed clusters using GitOps ZTP.
Procedure
Create a directory structure with separate paths for the
SiteConfig
andPolicyGenTemplate
CRs.Export the
argocd
directory from theztp-site-generate
container image using the following commands:$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13
$ mkdir -p ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13 extract /home/ztp --tar | tar x -C ./out
Check that the
out
directory contains the following subdirectories:out/extra-manifest
contains the source CR files thatSiteConfig
uses to generate extra manifestconfigMap
.out/source-crs
contains the source CR files thatPolicyGenTemplate
uses to generate the Red Hat Advanced Cluster Management (RHACM) policies.out/argocd/deployment
contains patches and YAML files to apply on the hub cluster for use in the next step of this procedure.out/argocd/example
contains the examples forSiteConfig
andPolicyGenTemplate
files that represent the recommended configuration.
The directory structure under out/argocd/example
serves as a reference for the structure and content of your Git repository. The example includes SiteConfig
and PolicyGenTemplate
reference CRs for single-node, three-node, and standard clusters. Remove references to cluster types that you are not using. The following example describes a set of CRs for a network of single-node clusters:
example
├── policygentemplates
│ ├── common-ranGen.yaml
│ ├── example-sno-site.yaml
│ ├── group-du-sno-ranGen.yaml
│ ├── group-du-sno-validator-ranGen.yaml
│ ├── kustomization.yaml
│ └── ns.yaml
└── siteconfig
├── example-sno.yaml
├── KlusterletAddonConfigOverride.yaml
└── kustomization.yaml
Keep SiteConfig
and PolicyGenTemplate
CRs in separate directories. Both the SiteConfig
and PolicyGenTemplate
directories must contain a kustomization.yaml
file that explicitly includes the files in that directory.
This directory structure and the kustomization.yaml
files must be committed and pushed to your Git repository. The initial push to Git should include the kustomization.yaml
files. The SiteConfig
(example-sno.yaml
) and PolicyGenTemplate
(common-ranGen.yaml
, group-du-sno*.yaml
, and example-sno-site.yaml
) files can be omitted and pushed at a later time as required when deploying a site.
The KlusterletAddonConfigOverride.yaml
file is only required if one or more SiteConfig
CRs which make reference to it are committed and pushed to Git. See example-sno.yaml
for an example of how this is used.