Multi-cloud GitLab CI/CD for IaC automation on Google Kubernetes Engine
Gitlab has undoubtedly been favourite choice of Enterprises since ages for VCS. Same way it has gained lot of popularity recently for its CI/CD offerings. Whether its the flexibility of choosing the hosting server for GitLab or the maturity it has gained in the DevOps area all over the years make it a strong competitor in its segment.
There are many articles available on Medium which speak about the steps involved in setting up GitLab CI/CD on GKE, in this article we will be discussing a step further as in how to deal with Multi-cloud GitLab CI/CD automation requirements.
Design consideration — Multi-cloud high level design
In the above architecture GitLab VCS is hosted on Google Kubernetes engine and GitLab runners which are responsible for CI/CD are individually hosted on different cloud providers on their respective Kubernetes managed service offerings. ex. Gitlab runner on Google cloud is hosted on GKE, another runner on AWS is hosted on EKS whereas the third runner on Azure is hosted on AKS.
Architecture Ice Breaking
The above architecture shows details of multiple blocks of components involved and how they combine together to make multi cloud GitLab CI/CD a reality.
The topics can be broken down to monitoring, GitLab Cloud native hybrid architecture details, multi pipeline design, artefact exchange and monitoring, multi cloud communication between runners and GitLab server.
VPC Networking Diagram- Hub & Spoke
This is a typical GCP Hub and Spoke network architecture with the Transit VPC being a hub, connecting to On-prem via interconnect, leveraging VPC-Peering to peer with the other VPCs.
VPCs are running as Shared-VPC where Internal-VPC mainly hosting workloads facing On-prem and DMZ-VPC mainly hosting workloads serving the internet.
In the current architecture, all the VPCs are also controlled by VPC Service Control (VPC-SC) where each shared-VPC is protected by their own perimeters to restrict cross VPC-SC API access.
Network Design for IaC components
As we saw the general Network architecture in the previous section, if we add the IaC components in it, then the modified Network design looks like this. According to Google VPC design best practice and Google VPC Service Control best practice, a Management VPC is introduced here. This management VPC Being the control plane of the rest of the cloud infrastructure, due to its data and workload sensitivity, this management VPC is placed in a separate perimeter to be protected from API invocation originated from other perimeters.
IaC infrastructure CI pipeline workflow with GitLab
- A developer updates Terraform code, commits code to GitLab, and creates a merge request to deploy infra resource.
- The GitLab runner executor polls for CI jobs.
- The runner picks up a job and pulls the container image that is configured for the pipeline.
- Using the container image, the runner spins up a Kubernetes Pod to the job using the service account configured in the CI pipeline.
- The pipeline takes the tfstate file from Cloud Storage.
- Execute Terraform plan through Google Cloud service account with Workload Identity.
IaC infrastructure CD pipeline workflow with GitLab
- Reviewers and approvers allow merge requests, which triggers a CD job.
- The GitLab runner executor polls for CD jobs.
- The runner picks up a job and pulls the container image that is configured for the pipeline.
- Using the container image, the runner spins up a Kubernetes Pod to the job using the service account configured in the CD pipeline.
- The pipeline takes the tfstate file from Cloud Storage and executes Terraform plan.
- Manage Workload project infra resources through Google Cloud service account with Workload Identity.
Conclusion
With Enterprises gaining maturity in their already hosted Cloud DC, multi-cloud has gained huge popularity recently as the next step amongst the Tech Giants. Whether it is their HA and DR goals to go multi-cloud or if its their Customers demand to have a SaaS solution offering on a particular cloud provider, Enterprises and Tech Giants have been working their ways into multi-cloud.
In this article I have covered one such use case where Enterprises can leverage multi-cloud GitLab CI/CD on Google Kubernetes Engine and meet their infrastructure automation goals effectively.
