Open lhjnilsson opened 2 weeks ago
Can achieve the desired result by passing network=network.name and desired hostname as kwargs when creating the container.
I am still unsure how and why it is so unstable when using the with_network, and also if this maybe should be removed. With reference to pass in on the initializer instead
@alexanderankin saw you added some labels.
I am happy to assist! Shall i add depreciation- flag on with_network ? and add the network and hostname as explicit arguments for Container Initialiser?
I have introduced this pattern for configurations which are experimental
if we can add something like this which links to this exact issue that would be great.
what would be even better is identifying and resolving the issue, which i believe stems from faulty detection with regards to detecting whether or not we are inside of a nested containerized situation or not (or reacting to that correctly).
I would say it is certainly not deprecated for removal, I think we should try to fix it first before giving up entirely.
lets not add container arguments - generally there is nothing magic going on here - maybe I can discover something after taking a closer look - if it works in the contstructor but not in the with_network should maybe even be an easy fix
Understood! Thanks It is interesting that the with_network sometimes work, sometimes not. I will see if i can look into it abit during the weekend
For people stumbling here and for which the workaround is not clear, here it is:
from testcontainers.core.container import DockerContainer
from testcontainers.core.network import Network
network = Network()
network_name = network.name
networking_config = {network_name: {"aliases": ["my-service-alias-1", "my-service-alias-2"]}
container = DockerContainer("your-image-name", network=docker_network.name, networking_config=networking_config)
container.start()
...
container.stop()
By the way, I'm wondering if the with_network
and with_network_aliases
should not just update _kwargs
attribute on the container object. What is the reason to manually call connect
function on the network instead of just relying on the container run
command for attaching the container to a network?
Describe the bug
Hello!
I have a case where I want to run several containers inside a specific docker network environment. However when attaching a container to a network it seems that port forwarding is not attached to the new network - making the overall experience unstable(not able to get postgres URL, few containers like Minio do healthcheck that hangs etc)
It seems like this is not always the case however. Roughly 30% of the times the ports are actually forwarded and it succeeded. However most of the time it fails: resulting in hanging operations etc.
To Reproduce
Given a case as below. Keep in mind that sometimes it does work. Most of the time it won't. Result will be that get_exposed_port operation hangs
Runtime environment
Provide a summary of your runtime environment. Which operating system, python version, and docker version are you using? What is the version of
testcontainers-python
you are using? You can run the following commands to get the relevant information.