Decide on environment name format to use
This issue is to decide on a standardised structure to use for GitLab environments within our k8s-workloads
group.
Currently we have the following environments (as an example)
- pre
- gstg
- gprd
- ops
- org-ci
- minikube (local dev)
- stgsub
- prdsub
Some environments (most notably gstg and gprd) have more than 1 Kubernetes cluster. e.g.
- gprd
- gprd-us-east1-b
- gprd-us-east1-c
- gprd-us-east1-d
On top of this, gitlab-com
, gitlab-helmfiles
, and tanka-deployments
are monorepos, however tanka-deployments
has a job per service, while the other two repos don't. To this end, we might want to consider the service being part of the GitLab environment name as well, in order to have separate GitLab environments for each deployable.
Some options
-
$service/$environment/$cluster
e.g.camoproxy/gprd/gprd
gitlab-monitoring/gstg/gstg-us-east1-b
-
$environment/$service/$cluster
e.g.gprd/camoproxy/gprd
gstg/gitlab-monitoring/gstg-us-east1-b
-
$environment/$cluster/$service
e.g.gprd/gprd/camoproxy
gstg/gstg-us-east1-b/gitlab-monitoring
Once we have decided on a format to use, not only should we adopt it in our CI jobs for GitLab environments, but we should go into all 3 repos and change the helmfile/tanka/k-ctl environment names to match the format as well. e.g. in gitlab-helmfiles
what is currently helmfile -e gstg-us-east1-b
will become helmfile -e all/gstg/gstg-us-east1-b
(in this case because helmfile covers all services, we use the keyname all
as a reference for that).
Chosen result
As GitLab environments are a low level technical construct used to directly target where a service might live, we are going to go with the format $environment/$cluster/$service
as it follows the path of how one might logically "connect" to access the service (e.g. environment bastion host, kubernetes cluster, kubernetes namespace).