Amaranath Nagappa

A retail client planned to migrate a survey app, actively used by customers, partners, and employees from its on-premise datacenter, to the cloud to reduce operating costs by adopting site reliability engineering practices.

The vendor confirmed the app couldn't run on containers, so I chose the Google Cloud Platform (GCP) for the project and adopted infrastructure-as-code practices.

I used Cloud SQL to manage the database, Windows Server 2016 on GCP MIGs for the web app, internal certificates for HTTPS internal portal, GitLab as the version control system (VCS), and CI/CD pipelines to automate delivery.

I have prepared GUI steps using PowerShell scripts, developed the project, and created a Cloud Storage bucket for Terraform state files and service accounts using the GCP governance repository.

In addition, I created multiple stages in GitLab pipelines with Packer for image building, used Terraform to develop resources such as instance templates, and managed instance groups, Cloud SQL with HA and backups, and GCP for object storage.

The deployment was the closest to containerization that we can with VM deployment.

Ultimately, we saw savings on running this infrastructure in the cloud with reduced support requests and costs.

Part of the site reliability engineering team's duties was maintaining our own GitLab executor images for our project deployments in the GCP Artifacts Registry.

All the necessary GitLab executor images were available on Docker with a few challenges:
• For each GitLab job run, the image must be pulled from Docker Hub
• Docker Hub images require the installation of packages
• Cannot enable internal version controls along with executable versions

To achieve faster GitLab job runs and increased security, I created a GitLab image repository with multiple branches, each with dedicated pipelines.

Additionally, I created and maintained Terraform, Ansible, kubectl, gcloud CLI, OCI CLI, Azure CLI, and Docker images and pushed them to the GCP SRE team's Artifacts Registry, with version controls.

By using these internal images, each GitLab runtime has been reduced by at least 30 seconds. Images are pulled from the internal GCP Artifacts Registry network, and control versions are maintained internally for better infrastructure-as-code management.

I was part of the site reliability engineering team handling the infrastructure migration of a large retail customer's data centers deployed using SRE and DevOps best practices, with code releases running as jobs on a private GitLab infrastructure.

With tens of applications with hundreds of servers, the wait time for shared runners was high, and for each application release, testing and deployment took a long time. The shared runners were being executed in a couple of VMs managed by DevOps tools and shared across 10+ SRE teams.

This project aimed to deploy dedicated GitLab runners so that the daily launch time for the jobs of 15+ team members was reduced by 2-5 minutes each, depending on the peak load of the shared runners.

Designed to deploy as Kubernetes GitLab runners, I pushed the code to the GKE namespace repository and submitted it as a merge request. Used the GitLab documentation to deploy GitLab runners using Kubernetes and created the necessary service accounts. Deployed multiple GitLab runners with different tags for different use cases like app launches, batch jobs, long-running jobs, and testing.

With these dedicated GitLab runners, the teams' productivity has increased due to reduced deployment time.