Local Docker registry

[iszulcdeepsense]

Consider this idea again: let's make use of local docker registry by Racetrack (for keeping the jobs), not the external one.

At the first glance, it seems like using the external registry is pointless. Docker registry is only needed to keep the job images, which are used internally. In Kubernetes setup, image-builder pushes the image to registry, then k8s takes it back and creates a pod from it. So what happens in Racetrack, it stays in Racetrack and there's no reason to use it somewhere else. In other words, docker registry is only used to transfer image into the infrastructure. Thus, it could be local. Plus, the installation step where you need to configure your docker registry and provide the tokens might seem to be too complex and redundant for users.

However, the existence of the external registry is imposed by Kubernetes. As far as I tried, you can't instruct Kubernetes to pull the image from a registry that runs inside the cluster's pod. Kubernetes' nodes are actually responsible for pulling the images, so every node's docker daemon (in fact it's not even docker but Container Runtime or something) should be able to reach it and have it configured as a insecure registry. This kind of configuration might be too complex and not really doable in some cases (like AKS). Maybe there's another way out of here, it's worth researching.

[JosefAssadERST]

Apologies for being pedantic and making the design challenge worse, but should RT core really consider the operational needs of ITPs? What I mean is, of course currently our two big ITPs (k8s and docker daemon) care about containers. But do wee want to assume that any ITP for RT uses containers? (not saying we shouldn't, but if we address this need in core, then we're sort of declaring that any infrastructure target will be somehow using containers, e.g. if we dpeloy to Amazon VM image, then it needs a docker host and so on).

[iszulcdeepsense]

Good point. Docker registry is the service that Racetrack relies on. Instead, it should be moved to an interface and implemented by infrastructure plugins. However, plugins can only implement logic at this point, they can't extend number of services, so it might be tough.