Change default network behavior

[binman-docker]

Is your feature request related to a problem? Please describe. When we deploy a compose file into Docker UCP, with services that only use mode:host ports, Compose creates a default network, and tries to do so in the user's default collection (which is their private collection).

By default in UCP, a user does not have network create permissions on their private collection, because you may not want the user to deploy random stuff outside defined collections and there are resource exhaustion issues with networks.

Therefore, this deploy fails. The problem is that we do not need nor want a default network, and without that, the user would have no problem doing the deployment.

Describe the solution you'd like I would like Compose to not deploy a default network, especially when it detects mode:host port allocations.

Describe alternatives you've considered

• Modify UCP roles to allow users to create networks on all collections (to include their private collection). This is undesirable due to the possibility of sprawl and orphaned/unused networks leading to IP space exhaustion.
• Put a "dummy" network into the Compose file with the correct Collection label specified. This works, but is undesirable because we would have to remind users to do it every time and would cause frustration.

Additional context More details (internal): ENGORC-2657

[thaJeztah]

With mode:host, you mean host-mode port publishing, correct (so not the host networking namespace). Wondering do these services not connect to anything else? (IOW, they're standalone services, and don't depend on other services?).

I'm a bit on the fence on changing the behavior based on host-mode port publishing;

• services with host-mode publishing can still be connected to a network (for communication with other services), which (I think) is quite a common scenario (front-end proxy with host-mode publishing, but connecting to the actual (web)server over a network
• we need to check carefully what scenarios would be more complicated, e.g. what should happen if a new service is added to the stack that doesn't use host-mode publishing? Should the network be created at that point, and the existing services be updated and connected to that network?

There's one more thing to take into account; (when using SwarmKit services), tasks of a service that is not connected to an overlay network fall back to the default, and thus will be connected to the "bridge" network (which causes them to no longer be isolated)

I do see value in having a way to indicate that a service should not be connected to a network (or, e.g., the default network to be none)

[binman-docker]

Right, this one: https://docs.docker.com/engine/swarm/ingress/#bypass-the-routing-mesh

We talk to the containers via the port assigned to them on the host (similar to how you can run a container with -p 3333:80). We then use HAProxy with service discovery tooling to route to them. This bypasses needing to use swarm mesh.

services with host-mode publishing can still be connected to a network

In which case the user would simply specify the network to be created

we need to check carefully what scenarios would be more complicated

For sure!

I do see value in having a way to indicate that a service should not be connected to a network

That would work, but is similar to the "add a dummy network" workaround where we would have to train users to add that configuration. It's just a little more explicit.

Ultimately it comes down to the fact that we made a decision to make things easy for people (create a network if they don't specify one, assuming they want one) but this hurts people who think they are using the tool correctly, not specifying a network, and getting one anyway. Unfortunately I don't think we can change that decision at this point (at least without releasing a totally new version to warn people of that change), but we could at least try to do the right thing and not add networks when we're pretty sure people don't want one.

[ingshtrom]

related documentation issue => https://github.com/docker/docker.github.io/pull/9064

This related to the second workaround, which is to create a "dummy" network and label it so that it lands in the correct collection.