With Geo proxying, secondaries now proxy web requests through Workhorse to the primary, so users navigating to the
secondary see a read-write UI, and are able to do all operations that they can do on the primary.
Request life cycle
Top-level view
The proxying interaction can be explained at a high level through the following diagram:
Proxy detection mechanism
To know whether or not it should proxy requests to the primary, and the URL of the primary (as it is stored in
the database), Workhorse polls the internal API when Geo is enabled. When proxying should be enabled, the internal
API responds with the primary URL and JWT-signed data that is passed on to the primary for every request.
In-depth request flow and local data acceleration compared with proxying
Detailing implementation, Workhorse on the secondary (requested) site decides whether to proxy the data or not. If it
can “accelerate” the data type (that is, can serve locally to save a roundtrip request), it returns the data
immediately. Otherwise, traffic is sent to the primary’s internal URL, served by Workhorse on the primary exactly
as a direct request would. The response is then be proxied back to the user through the secondary Workhorse in the
same connection.
Sign-in
Requests proxied to the primary requiring authorization
When a repository exists on the secondary and we detect is up to date with the primary, we serve it directly instead of
proxying.
Proxied repositories
If a requested repository isn’t synced, or we detect is not up to date, the request will be proxied to the primary, in
order to get the latest version of the changes.
Git pull over SSH
As SSH operations go through GitLab Shell instead of Workhorse, they are not proxied through the mechanism used for
Workhorse requests. With SSH operations, they are proxied as Git HTTP requests to the primary site by the secondary
Rails internal API.
Accelerated repositories
When a repository exists on the secondary and we detect is up to date with the primary, we serve it directly instead of
proxying.
Proxied repositories
If a requested repository isn’t synced, or we detect is not up to date, the request will be proxied to the primary, in
order to get the latest version of the changes.
Git push
Git push over SSH
As SSH operations go through GitLab Shell instead of Workhorse, they are not proxied through the mechanism used for
Workhorse requests. With SSH operations, they are proxied as Git HTTP requests to the primary site by the secondary
Rails internal API.
Git push over HTTP(S)
If a requested repository isn’t synced, or we detect is not up to date, the request will be proxied to the primary, a push redirects to a local path formatted as /-/push_from_secondary/$SECONDARY_ID/*.
Further, requests through this path are proxied to the primary, which will handle the push.