[Bug]: Test containers not work in TeamCity in Docker in Docker

[dominikjeske]

Testcontainers version

4.3.0

Using the latest Testcontainers version?

Yes

Host OS

Linuc

Host arch

x86

.NET version

8

Docker version

Client:       Podman Engine
15:10:47   Version:      4.9.4-rhel
15:10:47   API Version:  4.9.4-rhel
15:10:47   Go Version:   go1.22.11 (Red Hat 1.22.11-1.module+el8.10.0+22728+ac755c3c)
15:10:47   Built:        Mon Mar 17 19:07:06 2025
15:10:47   OS/Arch:      linux/amd64

Docker info

host:
14:06:15     arch: amd64
14:06:15     buildahVersion: 1.33.12
14:06:15     cgroupControllers: []
14:06:15     cgroupManager: cgroupfs
14:06:15     cgroupVersion: v1
14:06:15     conmon:
14:06:15       package: conmon-2.1.10-1.module+el8.10.0+22931+799fd806.x86_64
14:06:15       path: /usr/bin/conmon
14:06:15       version: 'conmon version 2.1.10, commit: 9ece2912d3d8b855ab314954a702ea65c5c9db47'
14:06:15     cpuUtilization:
14:06:15       idlePercent: 97.52
14:06:15       systemPercent: 0.68
14:06:15       userPercent: 1.8
14:06:15     cpus: 8
14:06:15     databaseBackend: sqlite
14:06:15     distribution:
14:06:15       distribution: rhel
14:06:15       version: "8.10"
14:06:15     eventLogger: file
14:06:15     freeLocks: 2048
14:06:15     hostname: test.ux.pl
14:06:15     idMappings:
14:06:15       gidmap: null
14:06:15       uidmap: null
14:06:15     kernel: 4.18.0-553.22.1.el8_10.x86_64
14:06:15     linkmode: dynamic
14:06:15     logDriver: k8s-file
14:06:15     memFree: 11590586368
14:06:15     memTotal: 33437138944
14:06:15     networkBackend: cni
14:06:15     networkBackendInfo:
14:06:15       backend: cni
14:06:15       dns:
14:06:15         package: podman-plugins-4.9.4-20.module+el8.10.0+22931+799fd806.x86_64
14:06:15         path: /usr/libexec/cni/dnsname
14:06:15         version: |-
14:06:15           CNI dnsname plugin
14:06:15           version: 1.4.0-dev
14:06:15           commit: unknown
14:06:15           CNI protocol versions supported: 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 1.0.0
14:06:15       package: containernetworking-plugins-1.4.0-5.module+el8.10.0+22931+799fd806.x86_64
14:06:15       path: /usr/libexec/cni
14:06:15     ociRuntime:
14:06:15       name: runc
14:06:15       package: runc-1.1.12-6.module+el8.10.0+22931+799fd806.x86_64
14:06:15       path: /usr/bin/runc
14:06:15       version: |-
14:06:15         runc version 1.1.12
14:06:15         spec: 1.2.0+dev
14:06:15         go: go1.22.11 (Red Hat 1.22.11-1.module+el8.10.0+22728+ac755c3c)
14:06:15         libseccomp: 2.5.2
14:06:15     os: linux
14:06:15     pasta:
14:06:15       executable: ""
14:06:15       package: ""
14:06:15       version: ""
14:06:15     remoteSocket:
14:06:15       exists: true
14:06:15       path: /run/podman/podman.sock
14:06:15     security:
14:06:15       apparmorEnabled: false
14:06:15       capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
14:06:15       rootless: false
14:06:15       seccompEnabled: true
14:06:15       seccompProfilePath: /usr/share/containers/seccomp.json
14:06:15       selinuxEnabled: true
14:06:15     serviceIsRemote: false
14:06:15     slirp4netns:
14:06:15       executable: /usr/bin/slirp4netns
14:06:15       package: slirp4netns-1.2.3-1.module+el8.10.0+22931+799fd806.x86_64
14:06:15       version: |-
14:06:15         slirp4netns version 1.2.3
14:06:15         commit: c22fde291bb35b354e6ca44d13be181c76a0a432
14:06:15         libslirp: 4.4.0
14:06:15         SLIRP_CONFIG_VERSION_MAX: 3
14:06:15         libseccomp: 2.5.2
14:06:15     swapFree: 2145906688
14:06:15     swapTotal: 2147479552
14:06:15     uptime: 99h 22m 20.00s (Approximately 4.12 days)
14:06:15     variant: ""
14:06:15   plugins:
14:06:15     authorization: null
14:06:15     log:
14:06:15     - k8s-file
14:06:15     - none
14:06:15     - passthrough
14:06:15     - journald
14:06:15     network:
14:06:15     - bridge
14:06:15     - macvlan
14:06:15     - ipvlan
14:06:15     volume:
14:06:15     - local
14:06:15   registries:
14:06:15     search:
14:06:15     - registry.access.redhat.com
14:06:15     - registry.redhat.io
14:06:15     - docker.io
14:06:15   store:
14:06:15     configFile: /etc/containers/storage.conf
14:06:15     containerStore:
14:06:15       number: 0
14:06:15       paused: 0
14:06:15       running: 0
14:06:15       stopped: 0
14:06:15     graphDriverName: overlay
14:06:15     graphOptions:
14:06:15       overlay.mountopt: nodev,metacopy=on
14:06:15     graphRoot: /var/lib/containers/storage
14:06:15     graphRootAllocated: 107363696640
14:06:15     graphRootUsed: 18626908160
14:06:15     graphStatus:
14:06:15       Backing Filesystem: overlayfs
14:06:15       Native Overlay Diff: "false"
14:06:15       Supports d_type: "true"
14:06:15       Supports shifting: "true"
14:06:15       Supports volatile: "true"
14:06:15       Using metacopy: "false"
14:06:15     imageCopyTmpDir: /opt/shark-linux-ci-1/temp/buildTmp
14:06:15     imageStore:
14:06:15       number: 0
14:06:15     runRoot: /run/containers/storage
14:06:15     transientStore: false
14:06:15     volumePath: /var/lib/containers/storage/volumes
14:06:15   version:
14:06:15     APIVersion: 4.9.4-rhel
14:06:15     Built: 1742234826
14:06:15     BuiltTime: Mon Mar 17 19:07:06 2025
14:06:15     GitCommit: ""
14:06:15     GoVersion: go1.22.11 (Red Hat 1.22.11-1.module+el8.10.0+22728+ac755c3c)
14:06:15     Os: linux
14:06:15     OsArch: linux/amd64
14:06:15     Version: 4.9.4-rhel

What happened?

I'm trying to run test containers in TeamCity (https://www.jetbrains.com/help/teamcity/container-wrapper.html). My tests are executing OK on Windows developer machine but in TeamCity I have Docker in Docker. I read this https://dotnet.testcontainers.org/dind/ and configure everything (see below). I have two steps - one with plain powershell running in container that is pulling image and second running with dotnet build with TestContainers using same image (to distinct where is a problem). When I'm not configuring docker remote socket both steps are failing but when adding this

--privileged --network=host -v /run/user/1123/podman/podman.sock:/run/podman/podman.sock

powershell is pulling image with success but TestContainers gives me "i/o timeout".

Relevant log output

Docker.DotNet.DockerApiException : Docker API responded with status code=InternalServerError, response={"message":"i/o timeout"}
14:11:05   
14:11:05     Stack Trace:
14:11:05        at Docker.DotNet.DockerClient.HandleIfErrorResponseAsync(HttpStatusCode statusCode, HttpResponseMessage response) in /_/src/Docker.DotNet/DockerClient.cs:line 514
14:11:05      at Docker.DotNet.DockerClient.MakeRequestForRawResponseAsync(HttpMethod method, String path, IQueryString queryString, IRequestContent body, IDictionary`2 headers, CancellationToken token) in /_/src/Docker.DotNet/DockerClient.cs:line 342
14:11:05      at Docker.DotNet.Models.StreamUtil.MonitorResponseForMessagesAsync[T](Task`1 responseTask, DockerClient client, CancellationToken cancel, IProgress`1 progress) in /_/src/Docker.DotNet/Endpoints/StreamUtil.cs:line 41
14:11:05      at DotNet.Testcontainers.Clients.DockerImageOperations.CreateAsync(IImage image, IDockerRegistryAuthenticationConfiguration dockerRegistryAuthConfig, CancellationToken ct) in /_/src/Testcontainers/Clients/DockerImageOperations.cs:line 73
14:11:05      at DotNet.Testcontainers.Clients.TestcontainersClient.PullImageAsync(IImage image, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 422
14:11:05      at DotNet.Testcontainers.Clients.TestcontainersClient.RunAsync(IContainerConfiguration configuration, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 335
14:11:05      at DotNet.Testcontainers.Containers.DockerContainer.UnsafeCreateAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 454
14:11:05      at DotNet.Testcontainers.Containers.DockerContainer.StartAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 298
14:11:05      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartNewAsync(Guid sessionId, IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, IImage resourceReaperImage, IMount dockerSocket, ILogger logger, Boolean requiresPrivilegedMode, TimeSpan initTimeout, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 224
14:11:05      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartNewAsync(Guid sessionId, IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, IImage resourceReaperImage, IMount dockerSocket, ILogger logger, Boolean requiresPrivilegedMode, TimeSpan initTimeout, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 248
14:11:05      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartDefaultAsync(IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, ILogger logger, Boolean isWindowsEngineEnabled, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 135
14:11:05      at DotNet.Testcontainers.Clients.TestcontainersClient.RunAsync(IContainerConfiguration configuration, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 319
14:11:05      at DotNet.Testcontainers.Containers.DockerContainer.UnsafeCreateAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 454
14:11:05      at DotNet.Testcontainers.Containers.DockerContainer.StartAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 298
14:11:05      at Samples.IntegrationTests.CustomerTests.InitializeAsync() in /opt/shark-linux-ci-1/work/c6ef9990aae14445/areas/samples/Sample.WebApi/Sample.IntegrationTests/CustomerTests.cs:line 61
14:11:05     Standard Output Messages:
14:11:05    [testcontainers.org 00:00:00.470] Connected to Docker:
14:11:05      Host: unix:///run/podman/podman.sock
14:11:05      Server Version: 4.9.4-rhel
14:11:05      Kernel Version: 4.18.0-553.22.1.el8_10.x86_64
14:11:05      API Version: 1.41
14:11:05      Operating System: rhel
14:11:05      Total Memory: 31.14 GB

Additional information

No response

[HofmeisterAn]

I have two steps - one with plain powershell running in container that is pulling image and second running with dotnet build with TestContainers using same image (to distinct where is a problem). When I'm not configuring docker remote socket both steps are failing but when adding this

--privileged --network=host -v /run/user/1123/podman/podman.sock:/run/podman/podman.sock

powershell is pulling image with success but TestContainers gives me "i/o timeout".

Did I understand this correctly? One approach fails right away when trying to pull the (base) image, and the other one (using the flags) fails with the shared stack trace?

Testcontainers also fails when pulling images, based on the stack trace.

at DotNet.Testcontainers.Clients.TestcontainersClient.PullImageAsync(IImage image, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 422

I guess this is a general issue and not specific to Testcontainers. Usually, mounting the socket is enough for a DinD environment, sometimes --privileged mode is necessary, though.

[dominikjeske]

Did I understand this correctly? One approach fails right away when trying to pull the (base) image, and the other one (using the flags) fails with the shared stack trace?

Not exactly. First approach is trying to use containers without additional parameters and then powershell step is exiting with error

Trying to pull mcr-docker.artifactory.xxx.pl/mssql/server:2019-latest...
12:39:04   Getting image source signatures
12:39:04   Copying blob sha256:86f1aa391d69220cb4b795def495570f7a5b01300540366caac7941f16516c8c
12:39:04   Copying blob sha256:75364e5e02c7d03deda93c353bc743c44621b8736892965d2e978f2674e1949b
12:39:04   Copying blob sha256:b43df23e6f02a3288781eb235ff93a3feabb723e620a3b5446c1b9b2dd18870b
12:39:12   Error: writing blob: adding layer with blob "sha256:b43df23e6f02a3288781eb235ff93a3feabb723e620a3b5446c1b9b2dd18870b": processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/gshadow: invalid argument): exit status 1

same approach without additional parameters for test containers gives me

    Error Message:
12:39:42      System.ArgumentException : Docker is either not running or misconfigured. Please ensure that Docker is running and that the endpoint is properly configured. You can customize your configuration using either the environment variables or the ~/.testcontainers.properties file. For more information, visit:
12:39:42   https://dotnet.testcontainers.org/custom_configuration/ (Parameter 'DockerEndpointAuthConfig')

I tried to fix this and executed containers with mapping

--privileged --network=host -v /run/user/1123/podman/podman.sock:/run/podman/podman.sock

with this approach powershell step gives me this

  Trying to pull mcr-docker.artifactory.xxx.pl/mssql/server:2019-latest...
12:24:16   Getting image source signatures
12:24:16   Copying blob sha256:86f1aa391d69220cb4b795def495570f7a5b01300540366caac7941f16516c8c
12:24:16   Copying blob sha256:b43df23e6f02a3288781eb235ff93a3feabb723e620a3b5446c1b9b2dd18870b
12:24:16   Copying blob sha256:75364e5e02c7d03deda93c353bc743c44621b8736892965d2e978f2674e1949b
12:24:31   Copying config sha256:b6d65c67219f3a0bd86870b0ef485928305923e8c3c83964170c476b5eef165e
12:24:31   Writing manifest to image destination

So for me it looks like a proof that I can get image using socket from host with success. Same fix with step used in testcontainers finish with error

Docker API responded with status code=InternalServerError, response={"message":"i/o timeout"}

So it looks better but still with error - I don't understand why 'podman pull' works in other step but testcontainers can't pull image?

Testcontainers also fails when pulling images, based on the stack trace.

I guess this is a general issue and not specific to Testcontainers. Usually, mounting the socket is enough for a DinD environment, sometimes --privileged mode is necessary, though.

This is why I have plain powershell step (TC Linux agent->ContainerWrapperX->pull) proving that I can pull image in same container and same thing is not working in test containers (TC Linux agent->ContainerWrapperX->testcontainers). I don't know how to debug this on what exact operation I'm waiting with i/o timeout? If I can turn some verbose method or execute some code to diagnose please assit me becaouse I'm stuck.

[HofmeisterAn]

I see, you're saying in the second example, using the PowerShell, the manifest is written. You can try increasing the verbosity when pulling the image. Not sure if it will contain more info though, the stack trace looks like it fails immediately. But let's see 🤞. Add a static ctor and try the following:

static CustomerTests() // TODO: Check if the ctor matches your configuration.
{
    ConsoleLogger.Instance.DebugLogLevelEnabled = true;
}

Or, you can pass a custom ILogger to the container builder that logs everything (but that's already the case for the above configuration; there are no traces, etc.).

[dominikjeske]

Hmm for me looks similar - any ideas how to investigate it?

ps. DOCKER_HOST ENV is set to unix:///run/podman/podman.sock, agent machine is not connected to internet (only internal artifactory but image link points to this artifactory)

    Error Message:
21:26:57      Docker.DotNet.DockerApiException : Docker API responded with status code=InternalServerError, response={"message":"i/o timeout"}
21:26:57   
21:26:57     Stack Trace:
21:26:57        at Docker.DotNet.DockerClient.HandleIfErrorResponseAsync(HttpStatusCode statusCode, HttpResponseMessage response) in /_/src/Docker.DotNet/DockerClient.cs:line 514
21:26:57      at Docker.DotNet.DockerClient.MakeRequestForRawResponseAsync(HttpMethod method, String path, IQueryString queryString, IRequestContent body, IDictionary`2 headers, CancellationToken token) in /_/src/Docker.DotNet/DockerClient.cs:line 342
21:26:57      at Docker.DotNet.Models.StreamUtil.MonitorResponseForMessagesAsync[T](Task`1 responseTask, DockerClient client, CancellationToken cancel, IProgress`1 progress) in /_/src/Docker.DotNet/Endpoints/StreamUtil.cs:line 41
21:26:57      at DotNet.Testcontainers.Clients.DockerImageOperations.CreateAsync(IImage image, IDockerRegistryAuthenticationConfiguration dockerRegistryAuthConfig, CancellationToken ct) in /_/src/Testcontainers/Clients/DockerImageOperations.cs:line 73
21:26:57      at DotNet.Testcontainers.Clients.TestcontainersClient.PullImageAsync(IImage image, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 422
21:26:57      at DotNet.Testcontainers.Clients.TestcontainersClient.RunAsync(IContainerConfiguration configuration, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 335
21:26:57      at DotNet.Testcontainers.Containers.DockerContainer.UnsafeCreateAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 454
21:26:57      at DotNet.Testcontainers.Containers.DockerContainer.StartAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 298
21:26:57      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartNewAsync(Guid sessionId, IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, IImage resourceReaperImage, IMount dockerSocket, ILogger logger, Boolean requiresPrivilegedMode, TimeSpan initTimeout, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 224
21:26:57      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartNewAsync(Guid sessionId, IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, IImage resourceReaperImage, IMount dockerSocket, ILogger logger, Boolean requiresPrivilegedMode, TimeSpan initTimeout, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 248
21:26:57      at DotNet.Testcontainers.Containers.ResourceReaper.GetAndStartDefaultAsync(IDockerEndpointAuthenticationConfiguration dockerEndpointAuthConfig, ILogger logger, Boolean isWindowsEngineEnabled, CancellationToken ct) in /_/src/Testcontainers/Containers/ResourceReaper.cs:line 135
21:26:57      at DotNet.Testcontainers.Clients.TestcontainersClient.RunAsync(IContainerConfiguration configuration, CancellationToken ct) in /_/src/Testcontainers/Clients/TestcontainersClient.cs:line 319
21:26:57      at DotNet.Testcontainers.Containers.DockerContainer.UnsafeCreateAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 454
21:26:57      at DotNet.Testcontainers.Containers.DockerContainer.StartAsync(CancellationToken ct) in /_/src/Testcontainers/Containers/DockerContainer.cs:line 298
21:26:57      at Samples.IntegrationTests.CustomerTests.InitializeAsync() in /opt/shark-linux-ci-1/work/c6ef9990aae14445/areas/samples/Sample.WebApi/Sample.IntegrationTests/CustomerTests.cs:line 68
21:26:57     Standard Output Messages:
21:26:57    [testcontainers.org 00:00:00.660] Connected to Docker:
21:26:57      Host: unix:///run/podman/podman.sock
21:26:57      Server Version: 4.9.4-rhel
21:26:57      Kernel Version: 4.18.0-553.22.1.el8_10.x86_64
21:26:57      API Version: 1.41
21:26:57      Operating System: rhel
21:26:57      Total Memory: 31.14 GB
21:26:57    [testcontainers.org 00:00:01.077] Docker config "/opt/app-root/.docker/config.json" not found
21:26:57    [testcontainers.org 00:00:01.080] Searching Docker registry credential in Auths
21:26:57    [testcontainers.org 00:00:01.081] Docker registry credential  not found

[HofmeisterAn]

agent machine is not connected to internet (only internal artifactory but image link points to this artifactory)

OK, this is a good hint and probably the issue. Testcontainers pulls a helper image to track resources and ensure everything gets cleaned up afterward: Resource Reaper (Ryuk).

I'm guessing you haven't configured Testcontainers to pull Ryuk from your Artifactory?

There are two ways you can do that:

1. Set the environment variable TESTCONTAINERS_RYUK_CONTAINER_IMAGE to mcr-docker.artifactory.xxx.pl/testcontainers/ryuk:0.9.0.
2. Set TESTCONTAINERS_HUB_IMAGE_NAME_PREFIX to mcr-docker.artifactory.xxx.pl. This will automatically prepend the prefix to every image, routing image pulls through your private registry instead of Docker Hub.
   • For example, WithImage("alpine") will internally become mcr-docker.artifactory.xxx.pl/alpine.
   • Just make sure the image names match what you've got in your private registry.

[dominikjeske]

Yes it was the problem with Ryuk. I set TESTCONTAINERS_RYUK_DISABLED to disable this functionality for now. For me it would be more readable when TestContainers would log more information about step that are executed. For example 'Getting ryuk image from address'. When there is only try/catch it is hard to catch what is going on.
So I'm next step but still with no success - now container is running but I cant access to it - connecting to 127.0.0.1:generatedPort is not working event when waiting long time. Locally everything is working.

[HofmeisterAn]

For me it would be more readable when TestContainers would log more information about step that are executed.

I agree, this is definitely something we should work on improving 👍.

Yes it was the problem with Ryuk. I set TESTCONTAINERS_RYUK_DISABLED to disable this functionality for now.

Just a heads-up. Disabling Ryuk can mess up your container host. We only recommend this (if at all) for ephemeral environments (and sometimes it is necessary). It's better to configure this properly and make sure the image is being pulled correctly.

So I'm next step but still with no success - now container is running but I cant access to it - connecting to 127.0.0.1:generatedPort is not working event when waiting long time.

In some environments, you'll also need to override TESTCONTAINERS_HOST_OVERRIDE to configure which host exposes the ports (e.g., DinD on Docker Desktop). I'm not exactly sure what's required in your specific setup, it vary a lot depending on the environment (I'm not aware of anything specific for Podman).

I recommend manually running a container and trying to connect to it. If Testcontainers can't connect, you'll probably run into the same issue using the CLI. Can you try the following?

# TODO: Mount the socket according to your environment.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 testcontainers/ryuk:0.9.0

Then try connecting to it:

# TODO: Test 127.0.0.1 and localhost
nc -N localhost 8080 << EOF
label=testing=true&label=testing.sessionid=mysession
label=something
EOF

Setting up environments like Podman, Rancher, DinD, different CI providers, etc., can be tricky. It usually takes a bit of fiddling to get everything running smoothly. Once you've figured out all the steps needed for your setup, a contribution to our docs would be super helpful.

I hope that helps.

[dominikjeske]

I'm little confused how to make it work with my configuration – still cannot connect to SQL container because port is not reachable.
What I have tested:

1. When running locally on Windows (WSL) I can run container that I’m using in TeamCity and on this container I’m running tests with TestContainers. I had small issues with reaching container port but when I map /var/run/docker.sock.raw:/run/podman/podman.sock using docker.sock.raw it works (but this is only on Docker Destop). Also when not using dynamic port assignment and use standard SQL port mapping 1433:1433 everything is working
2. When running on TeamCity agent with Redhat Linux (rhel8) that is using podman and running container wrapper with same container like above I can start test containers with SQL testcontainer – I can se logs that SQL I starting but when I’m trying to connect to 1433 (I also tried with dynamic port) I cant reach the port. I tried many ip addresses – every IP address from NetworkInterface.GetAllNetworkInterfaces(), _container.Hostname and _container.IpAddress but each is not reachable.
   Any ideas how to resolve this?

[HofmeisterAn]

Is the container runtime running on the same machine? Have you tried the steps above? The issue you're encountering usually indicates a general problem with the container runtime configuration. I'm guessing that if you try running the container manually (as suggested above), you'll run into the same issue.

I tried many ip addresses

You need the address from the container runtime host, and make sure no firewall or similar is blocking the incoming traffic. Others have run into this before.

Could you please share the output of podman inspect <container_id> (maybe podman info --debug)?