Cloud services are a valuable resource in support and give us the ability to host GitLab or GitLab related deployments in a wide variety of configurations. We can use permanent instances as a daily resource and ephemeral deployments to test, verify, reproduce and explore new ideas rapidly without consuming our local resources such as CPU, memory and battery life.
Although highly beneficial cloud services come with a cost that can be hourly or on a per-term basis. At first glance these costs can appear to be minimal however they can easily balloon to thousands of dollars per month.
The purpose of this page is to provide a workflow that will ensure we spend company money as if it's our own while maintaining minimal impact on existing support workflows.
For the context of this page a cloud service is a billed infrastructure product leased from an IaaS provider such as Digital Ocean, Google Cloud Platform or Amazon Web Services.
In a default configuration the Cloud Native GitLab Helm Chart will deploy GitLab services to three Kubernetes nodes to meet availability requirements. The recommendation for each node is the n1-standard-4 machine type. In total this deployment will utilize a whopping 12 vCPU and 45GB of memory. For almost all support related scenarios this size of deployment is unnecessary and we can use the minimum spec instead.
To deploy the Cloud Native GitLab Helm Chart at a minimum spec:
NUM_NODES=1 when executing the cluster bootstrap scriptGCP is not a requirement and the default helm chart can also be deployed locally using Minikube.
