Introduce a TC_HOST env variable in node.js implementation of testcontainers

[roman-dzhadan]

Intro Python, Ruby, and Go implementations support TC_HOST env variable. This is a logical naming convention for those who are not using Docker as their runtime containers. Currently, Node implementation of testcontainers only supports DOCKER_HOST which is a non-logical naming convention for those who are not using Docker as their runtime containers.

@cristianrgreco, lately, I've seen you've made a lot of great improvements to make Podman & Node.js Testcontainers more compatible. What do you think about my suggestion?

Expected Behaviour Improved API consistency of Node implementation to make the experience of usage testcontainers more language-agnostic.

Actual Behaviour According to the documentation, I must define the DOCKER_HOST variable even if I use Podman. Which is non-logical behaviour to me.

Steps to Reproduce

1. I'm defining a variable

export DOCKER_HOST=unix://${XDG_RUNTIME_DIR}/podman/podman.sock

2. I'm starting a podman.socket

systemctl --user start podman.socket

3. I'm running my jest integration tests and everything works fine, except the fact that DOCKER_HOST env var doesn't represent the reality of my usage of Podman.

Environment Information

• Operating System: WSL2 distro (Ubuntu 22.04.2 LTS) within the Windows 11 Pro (22621.1778)
• Docker Version: Irrelevant
• Podman Version: 4.5.1
• Node version: v18.16.0
• Testcontainers version: 9.8.0

[cristianrgreco]

Hi @roman-dzhadan, thanks for raising the issue and I agree. I will speak with the other testcontainers maintainers to see how to get this done.

[danielglazer]

Hey, can I help with this issue? looks to me like we can support both for backward compatibility to not make any breaking changes. but want to hear from you if this looks like a good idea

[cristianrgreco]

@danielglazer It's a tricky issue to pick up because there's a lot of context.

Testcontainers supports the concept of a Testcontainers Host strategy, which behaves a little differently to the Configuration strategy (which supports the DOCKER_HOST env var). The reason the other langs support the TC_HOST env is simply because config file arguments are automatically supported via the environment for those languages - it is not an attempt to replace DOCKER_HOST as this issue suggests.

We'll need to come up with something more generic and agree it with the other Testcontainer implementations, it's just low priority at the moment. IMO something like CONTAINER_RUNTIME_HOST/CRUN_HOST seems reasonable.

If you're looking for an issue to contribute I'd suggest #661

[danielglazer]

@cristianrgreco I am looking for another issue to contribute to :) will definitely check it out. thanks again 🚀

[joebowbeer]

I'm not understanding the benefit.

Testcontainers (and Devcontainers) require Docker API regardless of implementation: Rancher Desktop, Colima, Podman, Moby, etc. These developer tools are distinctly different from Kubernetes, which requires only a runtime interface (CRI) and has removed the dockerd runtime.

Perhaps I'm missing something, but I don't see how introducing a new env var is going to change this reality.

The TestContainers Java docs spell out DOCKER_HOST, too:

https://java.testcontainers.org/supported_docker_environment/

In fact, the Testcontainers docs have helped me sort-out my docker-related issues in other (non-TC) contexts.