In this article, we will walk through deploying a private Gitlab instance on a closed environment using Google Kubernetes Engine (GKE) in Autopilot mode, with the help of GCP services for storage and databases. We will detail the main requirements for this deployment, including the use of a private Virtual Private Cloud (VPC) and Autopilot mode for enhanced security. We will also discuss the challenges of deploying Gitlab in an Autopilot cluster, such as the lack of support for privileged pods, and the steps we took to address these challenges. We will provide a step-by-step guide on how to create an Artifact Registry, establish connections to GCP services, and handle storage and database needs using Cloud Storage, Cloud SQL, and Memorystore Redis. Additionally, we will explain how to reserve an internal static IP, create a Cloud DNS private zone, and open ports for local access to the GitLab UI. The article will provide a final configuration file and a detailed explanation of the Gitlab Runners, backups, and monitoring processes that were applied to ensure the smooth operation of the deployment.
Organizations can deploy a private Gitlab instance in a closed environment with enhanced security features and utilize GCP services for storage and databases.
Deploying Gitlab in a virtual private cloud (VPC) environment with no external internet connection can be complex. However, following the steps outlined in this article, organizations can successfully deploy a private Gitlab instance in a closed environment.
The main requirements for this deployment include having a cluster within a private VPC, with the cluster nodes and API being private and not accessible outside of the VPC. in our case, we worked on Google Kubernetes Engine (GKE) using Google Cloud Platform (GCP) services for storage and databases. We chose Autopilot mode, which offers enhanced security features compared to GKE in Standard mode.
GitLab must also be deployed in production mode, utilizing GCP services such as Cloud Storage, Cloud SQL (PostgreSQL), and Memorystore Redis instead of built-in storage and databases.
One of the main challenges when integrating an Autopilot cluster with Gitlab is the lack of support for privileged pods on GKE Autopilot. To address this issue, the GitLab Runner can be deployed on GKE Autopilot in unprivileged mode, allowing it only to run Gitlab CI jobs that do not require privileged pods or Docker in Docker. Additionally, cert-manager cannot be installed when integrating with an Autopilot cluster.
First, we created an Artifact Registry and a customer-related repository populated with Gitlab container images. This allows us to access and use the necessary images for our deployment easily.
Next, we created Gitlab buckets in Cloud Storage and granted a Storage Admin role to an IAM service account. This ensures that our Gitlab data is securely stored and easily accessible.
We then allocated an IP range for services and established a connection to GCP services. This allows our Gitlab deployment to communicate with other GCP services and resources.
To handle our database needs, we created a Cloud SQL PostgreSQL instance (v14) with a private IP and a Memorystore Redis instance (v5) in Private service access mode, with the AUTH option enabled. This provides a secure and reliable way to store and retrieve our Gitlab data.
We reserved an internal static IP for the internal TCP/UDP Load Balancer and created a Cloud DNS private zone for internal Gitlab domain records. This allows us to access our Gitlab instance internally easily. We also created an internal DNS A record for the provided Gitlab domain and the internal static IP.
We opened a port for the IAP subnet to allow access to the GitLab UI. This enables local access to the GitLab UI while maintaining a closed environment.
Finally, we prepared a Gitlab helm chart file with all specific configurations and installed Gitlab. We applied detailed configuration for Gitlab Runners, utilizing a Workload Identities map to link runners with GCP IAM. We also applied Gitlab backups and restored the process and monitoring processes to ensure the smooth operation of our deployment.