 The GitLab operator allows you to install and run an instance of GitLab in a vanilla Kubernetes or OpenShift cluster. Kubernetes operators increase the reliability and availability of your applications by automating day-to-operations such as upgrading components, management of data integrity, application reconfiguration, automatic recovery from a failure, and auto-scaling. In this short video, we show you how to install and run the GitLab operator to create a GitLab instance on an OpenShift container platform cluster, which we have already pre-installed. Inspecting the running pods of the OpenShift cluster, we see that Prometheus is already being used as a metric server, which is a prerequisite for the installation of the GitLab operator. Also, we verify that the GitLab system namespace does not yet exist. Another prerequisite is CertManager, which automates the management and issuance of TLS certificates. Let's use the OpenShift operator hub to install and instantiate an instance of CertManager. We first verify that one is not running. Then we head to the operator hub and install the CertManager operator and create an instance of CertManager by using its newly installed operator. In preparation of the GitLab operator installation, we create the namespace GitLab system, under which all of the GitLab resources will be. To install the GitLab operator, we define two environment variables. One is to set the version of the GitLab operator we want to use, and the other one is to set the platform for which we are targeting the operator. In this case, it is OpenShift. We then apply the GitLab operator custom resource definition, or CRD, to the cluster, which creates the operator. As we watch the pods in the GitLab system namespace, we see the creation of two pods for the GitLab controller manager. To create an instance of GitLab, we create a custom resource file called mygitlab.yaml to provide information, such as domain name and CertManager issuer email, for the GitLab operator to use during the creation of the GitLab instance. We then apply the custom resource to the cluster. This action will kick-start the creation of all the pods needed for the instantiation of a GitLab instance on the cluster. Once the GitLab instance is up and running, we obtain its external IP address from the NGINX Ingress Controller installed by the GitLab operator. We use this IP address to create DNS A records to map the DNS names of three of the GitLab instance subsystems to it. At this moment, we can point our browser to our newly created GitLab instance on OpenShift, and log in as root, whose initial password is a secret stored under the GitLab system namespace. That's it! We have shown you how to install and run the GitLab operator to create a GitLab instance on an OpenShift container platform cluster. Kubernetes operators increase the reliability and availability of your applications by automating day two operations such as upgrading components, management of data integrity, application reconfiguration, automatic recovery from a failure, and auto-scaling.