testcontainers
Bug: Azurite unable to run create_container
Describe the bug
when using a Blob Service Client on a Azurite container, an azure blob storage container cannot be created, thus testing that requires containers cannot continue. E.g. get_blob_client and upload_blob requires a container.
To Reproduce
Provide a self-contained code snippet that illustrates the bug or unexpected behavior. Ideally, send a Pull Request to illustrate with a test that illustrates the problem.
The last line here just hangs indefinitely, unable to proceed further
from azure.storage.blob import BlobServiceClient
from testcontainers.azurite import AzuriteContainer
with AzureContainer() as azurite_container:
connection_string = azurite_container.get_connection_string()
service_client = BlobServiceClient.from_connection_string(connection_string)
service_client.create_container(name="test")
Runtime environment
- M2 Pro, sonoma 14.7
- Python 3.12.3
- Docker 4.37.2
- Testcontainers 4.9.0 (via poetry)
Hej I am not completely sure but. I guess you are NOT testing inside docker (DIND),
I have bumped into a similar issue, my hacky solution was to modify the get_connection_string function of the AzuriteContainer
def get_connection_string(self) -> str:
host_ip = self.get_container_host_ip()
if host_ip.lower() == "localhost":
host_ip = "127.0.0.1"
the gist of this change is to use 127.0.0.1 instead of localhost I am not sure why this works though.
If i spin up an azurite container using docker compose and use a port on the same range as testcontainters. I am able to use both localhost and 127.0.0.1
@David2011Hernandez nice, this hack actually works for me
I'm leaving this issue open since the hack requires me to fork the package and change stuff would like to see it get patched officially
do you have this line in your /etc/hosts (c:\Windows\System32\Drivers\etc\hosts)?
127.0.0.1 localhost
you're right, I do have this in my /etc/hosts, I don't remember ever adding it though, might have other implications if i remove it
ok if you have this line and it still doesn't work some kind of other assumption is wrong and it may be a bug.
for context, when I run this test in github actions (running on ubuntu 24.04.1), it passes fine