Deploy Gitlab

GitLab is a self-hosted, open source platform that provides a comprehensive set of features for code management, collaboration, and delivery.

Prerequisites

Storage

Please ensure that at least one of the following prerequisites is met. Each prerequisite corresponds to a different storage method .

• Dynamically generated PVC: A storage class already exists in the cluster. The access mode defined by the storage class must be ReadWriteMany (RWX).

• Use available PVC: A persistent volume claim (PVC) already exists in the cluster. The access mode selected in the PVC must be ReadWriteMany (RWX), and the volume mode must be File system.

• Use node storage: There is sufficient storage resources in the cluster nodes.

Tip: After deleting the tool created by the function, the PVC bound to the tool will still remain.

Network

• If you want to access the tool through a domain name, please create a domain name in advance.

• If you want to use the HTTPS protocol, you also need to prepare a certificate that matches the domain name. The certificate sources include platform allocation and confidential dictionary import.

  | Certificate Source | Description |
  

  | ———— | ———————————————————— | | Platform administrator | Certificates created in Networking > Certificates . The certificate needs to be assigned to the project where GitLab will be deployed. | | Import ConfigSecret | TLS type secret dictionary created in Container Platform. The secret dictionary needs to be in the same namespace as GitLab. |

High availability

Requirements for deploying GitLab as highly available:

• PostgreSQL and Redis Operator must be deployed in the target cluster. In addition, the Redis Operator must be in the Own-namespace deployment mode.

• The default StorageClass that is NOT NFS already exists to automatically deploy the required components.

Cautions

• The SSO login depends on the built-in Dex authentication service of the platform. If the platform uses the https protocol for access and uses a self-signed certificate, this self-signed certificate needs to include a CA. Otherwise, the SSO function of the tool cannot be used.

• The service access address is set to the IPV4 address by default. If you need to use IPV6 and the cluster network card supports IPV6, please modify the IPV4 address to the IPV6 address.

On-premise deployment

It is recommended to open a virtual machine and deploy a public cloud cluster before deploying DevOps tools, and use the same storage and network solution as the native cluster. In this way, the tools and capabilities supported for deployment are synchronized with the native cluster deployment tools.

Verification

Once the deployment status become Deployed, verify the tool’s accessibility by accessing the URL.

What’s next

• Allocate tool resources to platform projects .

• Configure External LB for GitLab .

• To facilitate your use of the code repository trigger, the platform allows Webhook and service requests to the local network by default when integrating with GitLab. However, due to the special nature of Webhook usage , if you do not need to configure the code repository trigger, or need to meet stricter security requirements, you can disable Webhook and service requests to the local network . After disabling, the code repository trigger cannot be used.