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 }}
Repository navigation
Bug: port mapping not working with with_network (with_exposed_ports) #645
changed the title [-]Bug: Pb with port mapping (with_exposed_ports)[/-][+]Bug: port mapping not working with `with_network` (with_exposed_ports)[/+]on Jul 11, 2024
I also experience some difficulties with advanced network setup and I came to the conclusion it's due to the way it's implemented in TC:
when new container is created, self._container = docker_client.run is executed withoutnetwork kwarg, this means container has default network assigned by default:
if "network" not in kwargs and not get_docker_host():
# Otherwise we'll try to find the docker host for dind usage.
host_network = self.find_host_network()
if host_network:
kwargs["network"] = host_network
later, if self._network is not empty (after adding .with_network to container definition), container is connected to it (so it now is connected to two networks):
if self._network:
self._network.connect(self._container.id, self._network_aliases)
the solution could be to pass network kwarg to container constructor and omit .with_network completely but then we cannot assign network aliases. The workaround for this scenario is to use .with_name (it will be used as network alias as well) - I usually generate it with some random characters inside to avoid name clashes. Example:
When calling docker_client.run in container.py#start, it doesn't pass the network through.
If you look at how the method behaves, it will then resort to host networking which is not meant to support port bindings. : if you run docker port on the created container, no port will show up.
By the time the network is connected (L102), it is too late.
Activity
[-]Pb with port mapping (with_exposed_ports)[/-][+]Bug: Pb with port mapping (with_exposed_ports)[/+][-]Bug: Pb with port mapping (with_exposed_ports)[/-][+]Bug: port mapping not working with `with_network` (with_exposed_ports)[/+]fabricebaranski commentedon Jul 12, 2024
Moreover, I have some difficulties to create communication between these two containers on gitlab ci.
mgorsk1 commentedon Jul 15, 2024
I also experience some difficulties with advanced network setup and I came to the conclusion it's due to the way it's implemented in TC:
self._container = docker_client.runis executed withoutnetworkkwarg, this means container has default network assigned by default:self._networkis not empty (after adding.with_networkto container definition), container is connected to it (so it now is connected to two networks):the solution could be to pass
networkkwarg to container constructor and omit.with_networkcompletely but then we cannot assign network aliases. The workaround for this scenario is to use.with_name(it will be used as network alias as well) - I usually generate it with some random characters inside to avoid name clashes. Example:fabricebaranski commentedon Jul 15, 2024
It seems to work when I add .
with_bind_ports(9099, 0)champialex commentedon Aug 12, 2024
Confirming this does not work, for good reasons:
When calling
docker_client.runin container.py#start, it doesn't pass the network through.If you look at how the method behaves, it will then resort to host networking which is not meant to support port bindings. : if you run
docker porton the created container, no port will show up.By the time the network is connected (L102), it is too late.
Instead, this is what start should look like:
.... self._container = docker_client.run( self.image, command=self._command, detach=True, environment=self.env, ports=self.ports, name=self._name, volumes=self.volumes, # New params network=network.name, networking_config={network.name: EndpointConfig(version, aliases=self._network_aliases, **self._network_endpoint_configs) ) **self._kwargs, )In the meantime a workaround is:
Also adding a quick reproducer for testing:
alexanderankin commentedon Aug 12, 2024
open to a PR for this
Lenormju commentedon Aug 12, 2024
I struggled for hours with the same problem, and got this to work (in Pytest's fixtures) :
This way, I can make the web server connect to the MQTT broker (using the
MQTT_BROKER_NETWORK_ALIAS).mgorsk1 commentedon Aug 13, 2024
I've combined @champialex and mine findings into #678
feat: refactor network setup (#678)
feat: refactor network setup (#678)