You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 22, 2022. It is now read-only.
If we intend to a single load balancer across all nodes' registry (which we need to do because of the DNS limitations) the destination node needs to be part of the request URL so the LB can accurately route the request to the appropriate registry deployment. While largely meaningless to the registry service once routed, the request will still contain the node specification (since it cannot be 'filtered' by the LB). The service hence must disregard but tolerate this part of the path.
The current path w/o the node must remain supported.
The text was updated successfully, but these errors were encountered:
Sean and Eugene made the excellent suggestion of putting the node in an HTTP header - x-request-node. Verified that AWS LB rules support routing based on header values. QED. Thanks @nutjob4life & @tdddblog.
Will close this ticket once we have the rules in place and tested.
If we intend to a single load balancer across all nodes' registry (which we need to do because of the DNS limitations) the destination node needs to be part of the request URL so the LB can accurately route the request to the appropriate registry deployment. While largely meaningless to the registry service once routed, the request will still contain the node specification (since it cannot be 'filtered' by the LB). The service hence must disregard but tolerate this part of the path.
The current path w/o the node must remain supported.
The text was updated successfully, but these errors were encountered: