[I’d show more pictures but new users are apparently limited to the number of media stuffs they can attach…]
Steps to produce issue:
-
Create a Docker Registry connector that targets a plain HTTP image repo that doesn’t use any user authentication (anonymous). In my case the registry is in a container built from DockerHub’s registry:2 image. The container runs in Docker Desktop on my local machine. The container is accessible on my local machine at localhost:5000. The connector is added to a Kubernetes delegate that itself runs in Docker Desktop’s Kubernetes implementation on my local machine. “docker-desktop” is the name of the single node in my Kubernetes cluster, which also happens to be the machine on which the Docker image registry is accessible on port 5000.
Docker registry connector config is as follows. Provider type: Other (but DockerHub yields the same results) URL: http://docker-desktop:5000/v2. No authentication (anonymous). - Create a CI pipeline that includes a Build stage.
- Configure the build stage infrastructure such that it uses Kubernetes. In my case, I’m using the same Kubernetes cluster that my delegate is running in but I gave the build infrastructure its own namespace to run in.
- Add to the stage’s execution a build step that builds and pushes an image to a Docker registry.
In my config I specify the Docker repository as docker-desktop:5000/kubedemo-store and reference the Docker connector created in step 1 (which references a plain HTTP Docker registry). - Run the build.
Expected: It builds the image and pushes it to the configured repo.
Actual: The console output for the Docker image build says time=“2022-07-29T12:54:34Z” level=fatal msg=“Username must be specified”.
I did some digging and found out that Harness will try to build the image using the image plugins/kaniko:1.6.0. I played around with this image directly to understand its behaviour and I discovered that it generally outputs this “Username must be specified” message when there’s something wrong with the input arguments to its executor command (for example, don’t pass any arguments). I can’t say for sure what Harness is doing however.
Interestingly, if I add fake credentials to the Docker registry connector in step 1 and follow all the other steps as stated above, Kaniko outputs something different:
Now I can see what Harness is passing to Kaniko’s executor command. Looks right to me except Kaniko complains that it was expecting docker-desktop:5000/v2 to be accessible over HTTPS but it’s not HTTPS. Playing around with Kaniko myself it looks like it can work if I pass the --insecure flag to the executor command.
Conclusion
- Is Harness not handling anonymous Docker registries correctly? Am I doing something wrong? It looks to me like I had to add fake credentials to my Docker registry connector to get Harness to invoke Kaniko in a way that Kaniko likes.
- Even with the fake credentials work around stated above, I couldn’t find any way to get Kaniko to connect to my plain HTTP Docker registry. My own experimentation shows the --insecure flag should be passed to the Kaniko executor when the registry is plain HTTP but I couldn’t find any way to get Harness to do this. Should Harness automatically pass the --insecure flag when it sees in the connector config that the registry is on plain HTTP?
