mirror of
https://github.com/docker/compose.git
synced 2026-10-12 02:13:08 +00:00
Nicolas De Loof
27c9a231ea
get-relay-info answers pointed a locally-bound provider at one of the dependents' own networks: shared infrastructure every other service on it could also reach, and no more isolated than any project bridge. Provision a dedicated, internal:true bridge network scoped to that one provider service instead, created only when the provider itself sends get-relay-info -- the provider's own declaration that it binds locally, never for a provider backing a remote resource. The relay container joins it alongside the dependents' networks it already joins; it is torn down with the relay on endpoint changes and on down, including the no-compose-file down path. The network's lifecycle is hardened against the races a shared, project-scoped resource runs into: - a NetworkCreate conflict on the deterministic name re-checks by label (not just by name) before adopting the existing network, so a genuine name clash with an unrelated, user-declared network fails loudly instead of being silently adopted into the relay's isolation boundary; - a NotFound gateway lookup after losing that conflict falls back to an unresolved answer instead of propagating the error; - removeRelayLinkNetwork and ensureRelayLinkNetworksDown both tolerate a NetworkRemove conflict from the daemon's asynchronous endpoint disconnect, which can race the relay container's own removal; - ensureRelayLinkNetworksDown accumulates failures with errors.Join across every relay-link network of a project instead of aborting on the first one, and skips (warn-only) a network that still has active endpoints, mirroring removeNetwork's existing tolerance for regular project networks. docs/extension.md documents that the "desktop" network name in the get-relay-info answer (under Docker Desktop) is an opaque placeholder, never a real Docker network a provider can inspect or connect to. Signed-off-by: Nicolas De Loof <[email protected]>