Automate GitLab operations in Kubernetes environments GitLab Operator with OpenShift support
Anyone who wants to deploy and operate GitLab based on Kubernetes in an OpenShift environment benefits from the so-called GitLab Operator. Since the beginning of the year, the tool has been integrated into the DevOps environment as a beta, now it is generally available.
Companies on the topic
The GitLab operator can be found in the Operator Hub of the OpenShift Container Platform.
(Photo by Red Hat/GitLab)
Earlier this year, GitLab 13.1 was released along with the beta version of the GitLab operator. Over the past six months, GitLab has worked closely with the Red Hat team to discuss technical details and ensure the highest level of compatibility.
GitLab Operator and the Cloud Native Helm Chart are jointly offered as deployment solutions for cloud-native environments. Behind the scenes, the operator uses the Helm Chart to replicate IT operations. The operator offers advanced features beyond the Cloud Native Helm Chart and provides production support for OpenShift and Kubernetes, while the Helm Chart only supports Vanilla Kubernetes.
GitLab got suggestions for its own operator from the CoreOS equivalent of the same name. The goal of an operator is to map and automate the operational knowledge of an administrator, with the software running within the cluster. Initial tasks such as installation and configuration as well as follow-up tasks such as patches and upgrades with minimized downtime are integrated.
For the future, GitLab plans native upgrades without downtime, automatic backup management, and metrics-based performance recommendations. Refer to the GitLab Operator documentation for more information on known limitations and requirements, and for a complete installation guide.
(ID:47741496)
