NO_PROXY environment variable

[jeb2239]

can these utilities respect the NO_PROXY environment variable in the docker_rules? or is there a way to specify this ?

[nlopezgi]

Hi @jeb2239 ,
sorry for the super long delay responding to this issue. Is this issue still relevant? Could you provide a bit more context if so and let me know to reopen?

[weixiao-huang]

I got the same problem while using no_proxy.
I set http_proxy and https_proxy, also set no_proxy for specified site such as docker-registry.example.com. It seems I can use container_pull to pull image such as alpine, busybox by http(s)_proxy, but while pulling from docker-registry.example.com, it also passes by http(s)_proxy without respecting no_proxy setting

[nlopezgi]

Could you provide a more detailed repro example or more context about no_proxy and how should it work? Its possible its an unsupported feature in our rules. I have not heard from any users (other than this thread) about the need for this feature, so its likely something that would be low priority for us to implement atm, but I'm always happy to work with contributors to get new features supported. Reopening to keep track.

[weixiao-huang]

It seems that the problem is caused by the implementation of upstream package httplib2 since rules_docker depends on containerregistry, and containerregistry depends on httplib2.
In httplib2, it uses dot for suffix match. Means if I add example.com in no_proxy, docker-registry.example.com won't be bypassed as no_proxy. However, while adding .example.com, docker-registry.example.com can be detected as no_proxy domain.
However, since it seems no_proxy doesn't have a standard rule, some implementations of no_proxy may cause confusion.
This issue can be closed, I will discuss it in httplib2's issues. Thanks for your reply

[nlopezgi]

thanks for the extra info. If the error comes from the dependency on containerregistry, then fixing this will need to wait until #580 lands, as we are moving away from the current impl of containerregistry. Please follow #580 and also, it would be great if you can try the new_container_pull rule to see if the behavior is the same or if the migration fixes the issue.

[weixiao-huang]

By using new_container_pull and new_container_push, this problem seems not exist.

[weixiao-huang]

However, it seems that go-containerregistry is a bit slower than containerregistry while pulling and pushing images

[nlopezgi]

Thanks for the update.
We have not done any proper performance comparison yet of the two implementations. It would be great if you could comment on #580 wrt what you saw performance wise with the switch.
The good news is that go-containerregistry is very well supported so I'm sure they will be happy to have feedback wrt to performance that will help them (and us) improve the user experience. Closing this issue for now as the solution (using the new rules) has been identified. Please let me know to reopen if there is any reason to do so.