Pull-through mirror for Docker Hub images with K8s executor
Problem to solve
Currently, GitLab does not offer a pull-through mirror option which meets the following common criteria for a large organization using the Kubernetes runner executor:
- Able to authenticate against DockerHub
- Doesn't require manually editing the container runtime on each K8s node
- Users can leave image pulls as-is (i.e., adopting the solution doesn't require adding prefix variables across hundreds or thousands of projects)
GitLab offers similar solutions, but they don't meet all of these criteria:
-
Dependency Proxy
- Problems:
- Private registry connections aren't available with the Dependency Proxy.
- Unless your organization uses SSO, authenticating to the Dependency Proxy requires you to add predefined variables to each project's
.gitlab-ci.yml
- Problems:
-
Docker Hub Registry Mirror
- Problem: Currently, it's only compatible with the
docker-machine
executor
- Problem: Currently, it's only compatible with the
-
Open source solutions
-
docker-registry-proxy
- Problems:
- The project has not received any commits in nearly a year and does not seem well-maintained
- It would require editing the container runtime on each node
- Problems:
-
docker-registry-proxy
The open source tool k8s-image-swapper seems to meet all of the criteria and currently isn't mentioned in our docs. While this may be a good hold-over, some users would prefer a GitLab-native solution which we fully support.
Intended users
Unknown
User experience goal
A user with the Kubernetes runner executor should be able to set up a pull-through mirror for DockerHub which is able to authenticate against DockerHub, doesn't require manually editing the container runtime on each K8s node, and doesn't require adding prefix variables to each project's CI config.
Proposal
A config option in the Helm Charts values.yaml
file, which allows you to specify an address to a registry mirror. There is a very similar configuration available with the docker-machine executor.
Further details
From @ajwalker in a dev request for help (internal only) on this topic:
I don't think it would be too hard to add to Runner. I think reluctance in the past was because we generally don't try to add options to Runner that are already part of the runtime configuration, but given Kubernetes can have multiple runtimes now, maybe this problem is harder than it used to be for users?