Avoid trying https for insecure registries

[pangsq]

Imporve the fallback logic in ping. Not try https if the registry is intentionally set to insecure so that we can avoid long delays on http-only registry (which may directly drop the packet to port 443 rather than answer with a RST).

Fixes GoogleContainerTools/kaniko#970

It still keep #279 solved.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 75.04%. Comparing base (0976a27) to head (0341a1b).
Report is 409 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/name/registry.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1002      +/-   ##
==========================================
- Coverage   75.18%   75.04%   -0.14%     
==========================================
  Files         107      107              
  Lines        5061     5077      +16     
==========================================
+ Hits         3805     3810       +5     
- Misses        711      721      +10     
- Partials      545      546       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cope]

looks good

[jonjohnsonjr]

Part of me thinks we should fall back to https in this case, still, just to avoid breaking something that worked before, but I'm not sure.

[pangsq]

I list all conditions below to figure out how this patch will make a difference to the usage.

No.	Registry Protocols	Insecure Flag	Match localhost pattern	Protocol Used Before	Protocol Used After
1	HTTPS+HTTP	✖	✖	HTTPS	HTTPS
2	HTTPS+HTTP	✖	✔	HTTPS	HTTPS
3	HTTPS+HTTP	✔	✖	HTTPS	HTTP
4	HTTPS+HTTP	✔	✔	HTTPS	HTTP
5	HTTPS-only	✖	✖	HTTPS	HTTPS
6	HTTPS-only	✖	✔	HTTPS	HTTPS
7	HTTPS-only	✔	✖	HTTPS	failed
8	HTTPS-only	✔	✔	HTTPS	failed
9	HTTP-only	✖	✖	failed	failed
10	HTTP-only	✖	✔	HTTP	HTTP
11	HTTP-only	✔	✖	HTTP	HTTP
12	HTTP-only	✔	✔	HTTP	HTTP

The conditions on which performances will be different are No.7/No.8. On these conditions, users just need to unset the insecure flag to make it work. Considering that the insecure flag is default False, these conditions may not happen.

[jonjohnsonjr]

Considering that the insecure flag is default False, these conditions may not happen.

My concern is that this option might be set "globally" for a given consumer. If you look at kaniko, they have a bunch of flags that are booleans to enable insecure behavior.

You can imagine someone with a Dockerfile that pulls FROM two different registries: their secure production registry, and an insecure registry running on their network.

If we don't have a fallback to https, pulling from their secure registry would just fail.

Arguably, any decent web server will redirect from http to https, so this might not be a problem in practice, but I wanted to bring it up as a potentially breaking change.

[pangsq]

I agreed that maybe some kaniko users enbale the insecure flag and have secure/insecure registries in one Dockerfile. On that condition, the pulling from thesecure registries would fail. However, in kaniko, users can also use the insecure-registry to config which registries are insecure and the others will still use HTTPS for pulling and pushing.

In my opinion, it is determined that if users set insecure, then we will try HTTP at first. And whether or not we fallback to HTTPS is another consideration.

[pangsq]

I think fallback to HTTPS after HTTP is failed is reasonable for this issue.

[jonjohnsonjr]

Thanks!