Investigation on alternatives to the usage of the qa tunnel
Problem Shutdown of the qa-tunnel for security reasons
as a result, the following specs are not running:
- create_project_with_auto_devops_spec.rb
- kubernetes_integration_spec.rb
- all_monitor_core_features_spec.rb
- all_monitor_features_spec.rb
Findings
Currently, it does not seem to be possible to run some of the 7_configure
and 8_monitor
feature specs.
When avoiding the Kubernetes scenario and the internet tunnel altogether the outcome is a lack of connectivity between the components, more specifically: GitLab instance and K3s container (the Kubernetes cluster is running in docker)
🧪 Experiment 1
8_monitor
tests run without Auto DevOps enabled and deploy manually (using a simplified gitlab-ci.yml) to the Kubernetes cluster (k3s) and not using the Registry
Observations:
- works locally when using an alias to the loopback adapter and tests pass
✅ - doesn't work on CI
❌ GitLab instance and k3s are in the same docker networktest
but the runner pod is inside the k3s cluster and does not know how to route to the GitLab instance (named, as an example,http://gitlab-qa-asfsdg.test
). There is a LoadBalancer in the cluster that can be pinged from the Runner pod and from the docker k3s container (when opening a shell likedocker exec -it k3s sh
), but the LoadBalancer External IP is not reachable from the host machine - where GitLab runs. The gitlab-qa-asfsdg.test hostname is not being resolved, therefore the builds get stuck with unreachable Runner.
How could we let the LoadBalancer (Ingress installed via UI in Operations > Kubernetes > Applications
) , inside a container, know where to route for gitlab-qa-asfsdg.test
so that it can resolve for the Runner, as the container is on the same test
network?
Also, this does not solve entirely the problem since [create_project_with_auto_devops_spec.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/qa/specs/features/browser_ui/7_configure/auto_devops/create_project_with_auto_devops_spec.rb)
does need to test the Auto DevOps flow and that requires to spin a Registry component as well.
🧫 Experiment 2
Auto DevOps locally without using a qa-tunnel. Is it possible?
Observations:
- Enabled the Registry following GDK specific instructions and also (see references below) modified so it listens to a local aliased IP
✅ - Blocked with the certificate signed by unknown authority issue
❌ Found documentation for manually deploying a runner on the cluster but this somehow seems to bypass the Auto DevOps process as the Runner is already installed via the UI inOperations > Kubernetes > Applications
. Can we customize Auto-Devops.gitlab-ci.yml to allow the already installed Runner to accept a self-signed certificate for the registry? Or should this Runner be manually installed via Helm?
This is only a partial solution. Perhaps it can enable us to use the qa tunnel just for CI purposes and give developers a local secure (non Internet exposed) solution as a workaround.
Main references: