Red Hat OpenShift is widely used as a container workload platform. Many Customers currently utilize NetApp ONTAP for persistent storage of their stateful applications on OpenShift Containers. Did you know that the same ONTAP system can be used to provide storage for other capabilities of the OpenShift ecosystem, allowing our customers to stretch the investments made on the storage? In a previous blog, I showed you how you can integrate NetApp ONTAP storage system for storing logs in the OpenShift Container platform. In this blog, I will provide detailed instructions for installing an integrated image registry in OpenShift Container platform. These steps will enable users to push and pull images from the ONTAP-backed registry to deploy Astra Control Center on the OpenShift cluster.
OpenShift Container Platform provides a built-in image registry that can run as a standard workload on the cluster. This integrated registry can be deployed on an existing OpenShift Cluster by an administrator to provide a registry for users to manage the images that run their workloads. The registry can be scaled up and down like other cluster workloads. It is integrated into the cluster user authentication and authorization system, which means that access to create and retrieve images is controlled by defining user permissions on the image resources.
Let us install the image registry, setup ONTAP NAS storage as the backing store for the registry, push the Astra Control Center image into it, and then install Astra Control Center on the cluster, by pulling the image from the registry.
On platforms like VMware, bare metal etc. that do not provide shareable object storage, the OpenShift Image Registry Operator bootstraps itself as Removed during cluster installation. This allows the installer to complete the cluster installations on these platform types.
Pre-requisites
You should have a working OpenShift cluster. You should have installed Astra Trident on the cluster and set up the backend, storage class and snapshot class objects. You will need to change the default storage class to ontap NAS based storage class, if it is not already done so. You can do this from the command line or console. The screenshot below shows the annotation of the ontap based storage class set as follows (from the console) to make it the default storage class.
storageclass.kubernetes.io/is-default-class true
Remember to modify the current default storage class annotation storageclass.kubernetes.io/is-default-class true to false
Creating the registry
On a VM that has access to the cluster, use the oc tool to make the following 3 edits in the spec section of the imageregistry operator
Edit #1:
oc edit configs.imageregistry.operator.openshift.io
storage:
pvc:
claim:
A PVC (called image-registry-storage) will be automatically created and populated in the claim field. The PVC is generated based on the default storage class, which in our case is backed by ONTAP NAS storage.
Edit #2:
routes:
- hostname: astra-registry.apps.<ocp-cluster-name>.<domain-name>
name: netapp-astra-route
The above allows the creation of a custom host name and a custom route to the registry. Since I will be hosting the Astra Control Center images in this registry, I used astra-registry in the host name.
Edit #3:
Change the management state of the operator to the Managed state
spec: managementState: Managed
Once the edits are completed. Save the file. PVCs, pods and a route should now be created for the image registry.
You will see the following persistent volume claim created and added into configs.imageregistry.operator.openshift.io
oc get all -n openshift-image-registry
Accessing the registry
Add TLS certificates to the OpenShift nodes
You can either add the default TLS certificate or a custom TLS certificate to the OpenShift registry route. For details about using custom TLS certificates, refer to the solutions documentation.
Here, I show the steps when using the default TLS certificate.
1. Get the default certificate from the secret
oc extract secret/router-ca --keys=tls.crt -n openshift-ingress-operator
2. Add the certificate to the docker client on the OpenShift nodes, to allow them to access the image registry. This is achieved by the following 2 steps:
a. Create a configmap in the openshift-config namespace using the TLS certificate
oc create configmap astra-ca -n openshift-config --from-file=astra-registry.apps.ocp-cluster4.sddc.netapp.com=tls.crt
b. Patch it to the cluster image config to make the certificate trusted.
oc patch image.config.openshift.io/cluster --patch {"spec":{"additionalTrustedCA":{"name":"astra-ca"}}}' --type=merge
Add the TLS certificates to the docker client on the admin VM
To push and pull images from a VM where you have downloaded the Astra Control Center images, you need to complete the following steps:
sudo mkdir /etc/docker/certs.d/astra-registry.apps.<cluster-name>.<domain-name>
eg:sudo mkdir /etc/docker/certs.d/astra-registry.apps.cluster4.sddc.netapp.com
sudo cp /path/to/tls.crt /etc/docker/certs.d/astra-registry.apps.ocp-cluster4.sddc.netapp.com
Pushing the Astra Control images into the registry
Follow the instructions here to download and extract the Astra Control Center images on the admin VM from where you can access the cluster. Log into the OpenShift cluster by using the token. You can get the login command from the console.
oc login --token=sha256~OJJdf5gPZamHqHsDKNJw6tRZnXt6fIyHSulypOBECl0 --server=https://api.ocp-cluster4.sddc.netapp.com:6443
Now use podman to login to the registry. (You can also use docker commands to login, to push and pull from the registry)
podman login astra-registry.apps.ocp-cluster4.sddc.netapp.com -u kubeadmin -p $(oc whoami -t) --tls-verify=false
Create a namespace to push the images
oc create namespace netapp-astra -> this is used in the push script below
Use the following script to push the images to the registry:
export REGISTRY=astra-registry.apps.ocp-cluster4.sddc.netapp.com
export DIRECTORYNAME=acc
for astraImageFile in $(ls acc/images/*.tar) ; do
echo "loading images"
echo "loading" $straImageFile
# Load to local cache. And store the name of the loaded image trimming the 'Loaded images: '
astraImage=$(podman load --input ${astraImageFile} | sed 's/Loaded image: //')
astraImage=$(echo ${astraImage} | sed 's!localhost/!!')
# Tag with local image repo.
echo "tagging"
podman tag ${astraImage} ${REGISTRY}/${astraImage}
echo ${REGISTRY}
echo ${astraImage}
# Push to the local repo.
podman push $astraImage ${REGISTRY}/netapp-astra/${astraImage} --tls-verify=false
done
Pulling the Astra Control images from the registry
You can test to verify that pull works by issuing the following command. This command pulls one of the images that was tagged and pushed into the registry.
podman pull astra-registry.apps.ocp-cluster4.sddc.netapp.com/netapp-astra/vault-controller:1.12.1
Now let us use the image in this registry to deploy Astra Control Center in the OpenShift Cluster operator hub.
You can follow the instructions here to ensure all the pre-requisites and the configuration steps are completed to install Astra Control Center. Here, I will only highlight the use of the image registry to deploy Astra Control Center.
Create an image pull secret for the username and password that you want to use to pull images. Ensure that the user has the appropriate permissions. Here I used kubeadmin user and the token as the password.
In the Create AstraControlCenter form view, for the image registry field, provide the name of the server hosting the images and the image pull secret that you created previously.
For the remaining fields, follow the instructions provided in the Astra Control Center documentation.
You will see that the pods are deployed for ACC using the images pulled from the registry.
Summary
In this blog, I have shown you how to deploy an integrated registry on OpenShift Cluster and use ONTAP as the backing storage. I have shown you how to push images into the registry and use it to deploy Astra Control Center. ONTAP provides all the familiar data management capabilities that is made available for the storage backing the image registry storage as well. It enables our customers to extend their storage system utilization to the RedHat ecosystem.
