Working via docker.sock does not necessarily mean containers are running on localhost about testcontainers-java

[rnorth]

Hi Jan,

Thanks for this - that's a good point. I'm wondering, since the port availability wait can tend to be quite important, if there might be another option.. How about an environment variable that would be able to override the container address detection?

e.g. in DockerClientFactory.instance().dockerHostIpAddress():
if using /var/run/docker.sock, container address = 'localhost' unless TESTCONTAINERS_CONTAINER_HOST is set, in which case return the value of that

That way the wait-for-start behaviour can carry on working (using getContainerIpAddress()), plus tests can remain independent (calling getContainerIpAddress() themselves).

Would that help in your case?

Thanks
Richard

[JanMosigItemis]

That sounds like it would solve the problem. However I tend to like properties more than environment variables. This way it's easier to integrate with Jenkins and Maven, e. g. I can run a build like

mvn clean install -Dtestcontainers.container.host=docker-machine-ip

And it doesn't pollute the build server's environment.

If such a feature is going to be integrated it may be a good idea to mark it as experimental for some time since I am not exactly sure if it does really make sense that way. I mean: If it wasn't for the docker in docker setup, then socket->localhost, ip->someOtherHost holds true und is perfectly reasonable. The new feature may cause things to become more complicated (also more powerful) and it must be seen if similar situations do exist where it comes in handy. Maybe provisioning Jenkins Slaves with Docker or running a whole container as test would be another use case for this.

[rnorth]

Yes, I think I'd probably want an equivalent system property for any environment variable setting anyway, so that would be OK.

I do think it is worth thinking more about where this would be useful, as you suggest. Another scenario I can imagine that might need something similar would be use of Docker Swarm. In that case the env var/property would be too simplistic to relate to where the container actually ends up. So maybe something programmatic might be a better idea - at least gives users the option of implementing more sophisticated behaviour when it's genuinely needed...

I'll have a bit more of a think about it and maybe propose some other approaches tomorrow.

Thanks for your input!
Richard

[rnorth]

I'm thinking I'll keep this reasonably simple for now:

• if env var TESTCONTAINERS_CONTAINER_HOST or sysprop testcontainers.container.host is set, that value will always be returned from getContainerIpAddress() (no matter what)
• otherwise the usual logic will apply - it will return the DOCKER_HOST address unless using a unix socket, in which case it will return localhost

I think this gives necessary flexibility without complicating things too much...

This doesn't cater for the swarm example, but in such a scenario getContainerIpAddress() is unlikely to be useful anyway - there's only so much it can do. Instead some other project/environment specific method should be written separately and used in its place, outside of the testcontainers library.

I'll set this up in a branch for review.

[rnorth]

Closing this in conjunction with PR #92 for the time being.