Currently the experience of using testcontainers-go within a container isn't that great because when accessing mapped ports via Container.Host(context.Context) (string, error) it only checks if the Docker host is a local or a remote host but when running e.g. in a containerized CI process this will fail because the ports obviosly aren't mapped to the container but to the host.

testcontainers-dotnet resolves this by checking if it's running in a container (by checking for /.dockerenv) and if so it tries to resolve the default gateway and uses this IP to reach the host.

This could also be done for testcontainers-go, also we could not only check for /.dockerenv but also for /run/.containerenv (to support Podman as well).

Another nice feature could be to support advanced mount scenarios where a directory is bind-mounted into the CI container but on a different path (this is the case for instance in Azure DevOps). If one tries to bind-mount a sub-directory of the workspace into a testcontainer the mount obviously fails because the mount source does not exist on the host system.
This can be resolved by:

1. check if running in a container
2. check if there are any bind-mounts
3. get all containers
4. identify the current container by checking /proc/self/mountinfo with a regex like in the notes below
5. check all mounts if there's a bind mount target overlapping with a bind mount source for the testcontainer to be created
6. update the bind mount source to respect the host path

I'd be happy to implement this as soon as the docker-compose stuff is done because I'm also currently dealing with this and have already some workarounds in place I could polish and contribute.

Notes:

• container ID regex: .*(?<containerId>[a-z0-9]{64})(\/[a-z]*)*\/hostname.*