-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Description
I'm running Harbor on AWS EKS, deployed via helm chart. External redis on AWS Elasticache.
I tried recently released support of Redis TLS. So far it's working on all helm components except harbor-registry
. Example log line:
time="2025-04-16T20:54:28.581348803Z" level=error msg="redis: error connecting: read tcp 10.103.94.152:51858->10.103.130.14:6379: i/o timeout" go.version=go1.23.8 instance.id=046ea105-712a-44d1-aca6-74153ca4c969 redis.connect.duration=10.00192435s service=registry version=v2.8.3-21-gea065fef
In the same time other harbor components were connecting just fine to Redis via TLS.
I have one suspicion why it's so. You added tls support for redis at goharbor/distribution#5, yaml key is enabletls
. But in chart yaml key is enableTLS
. As yaml is case sensitive, the keys don't match, resulting in harbor-registry ignoring this option and trying to connect to redis without TLS enabled, which results in i/o timeout. i/o timeout
isn't a connection timeout
, connection is established but communication isn't working as protocols don't match.
PS It's strange to see you forking distribution/distribution
to add redis tls support. You actively resisted forking distribution when you were asked about adding modern AWS auth support (#12888), because it would be available in next major upstream release, distribution 3.0. Same story goes with Redis TLS, it isn't supported by distribution 2.8, but is supported by distribution 3.0. But instead of waiting for 3.0, you forked and patched 2.8.