Allow setting custom IP to a container

[oktalz]

there is already option to set custom IPAM setting to a network seen here [network.go#L40)](https://github.com/testcontainers/testcontainers-go/blob/main/network.go#L40

Could we add similar option to container itself ?
underline code-base already allows setting that options as it can be seen github.com/docker/docker/api/types/network

so it is just a matter of passing those values to it.

since IPAMConfig is a pointer, by default is nil, this feature can be added without changing of behavior of a library

potential use cases are many, but with using some protocols that can't use DNS, of hostnames this is very much welcomed.
in more complex tests where each instance must know/need to have list of all nodes/containers prior to run this would also help.

currently only way of doing that is run all containers, fetch the IPs, stop all containers, create a valid configuration for services, and then start containers again with known IP addresses.

option to set IP address in advance would greatly speed up test in that particular use case

you can also do that in docker compose for example, but I would like to see more Go native way and not run docker compose up and then cleanup after the test is run (so, by using this library and not with external tools)

[mdelapenya]

I'm really interested in those potential, more complex use cases without DNS or hostnames, to have an even wider overview of the problem we want to resolve. As I said in #587 (comment), we are open to the addition once we understand them better.

I have to admit that we (I) probably merged #394 without as much context as the one I have know (joined as a full time maintainer in August), and in that sense, I can share here that Testcontainers (in any available language) is not a generic Docker client that needs to expose all methods and config params of the underlying Docker client.

In any case, we'd like to cooperate with you in improving the setup of your tests, and that could lead to merging #587 into the code ☺️

[kiview]

Thanks for the example @oktalz. In this case, what would happen if you start to parallelize tests (either locally or on CI) and you have conflicts with reusing the same IP address?

In Testcontainers for Java, we have a mechanism to fall back to the docker-java API for accessing Docker features, that are not directly available in the Testcontainers API. The Testcontainers API is an opinionated view on top of the Docker API. In parts, the Testcontainers API wants to actively avoid giving access to features that can lead to Integrated Tests (tests that pass or fail based on the state of another system, in this case, your test host).

That's why I would advocate for giving better access to modifying the container creation request through a different mechanism, that is not part of the top-level Testcontainers API.

[oktalz]

@kiview I don't use same IP ranges in all tests :) that would be pointless.
in fact most of my tests don't need it.

... The Testcontainers API is an opinionated view on top of the Docker API...

I understand that it is opinionated, that is totally fine.

Testcontainers API wants to actively avoid giving access to features that can lead to ...

my first PR solution even had dynamic example (create subset dynamically, then you are safe regardless what you do), but for the purpose of it I simplified it to not test something that is out of scope of a that PR.

... modifying the container creation request through a different mechanism ...

yes, something else might be a better option, however, this can be done without any impact also with testcontainers, but that is my view :)

[mdelapenya]

@oktalz we had a deep chat on this today, and I come with good news. We are going to implement a callback mechanism at the container request level which will provide the very same capabilities you are proposing in your PR. But why in a callback instead of directly in the container request?

The container request represents the public API that anybody will use. This is what I call layer1. Having the IP exposed there will open the gate to possible mistakes for a misuse of the public API (layer1). On the contrary, adding the IP settings as a function that modifies the request in a separate layer (layer2), will make it possible to use layer1 in a simple manner and at the same time, more advanced users will have the ability to use layer2 to provider a more advanced configuration for their containers.

We will eventually be transitioning advanced capabilities from the container request (CapAdd/CapDrop, Shmsize, etc) to the layer2, hopefully in a non-breaking manner. Of course documentation will take an important place here.

I wanted to let you know, as we value your time creating this discussion.

[oktalz]

callback or direct access is not really important, but
reducing complexity is. so having two layers is OK.

Easier maintenance is certainly a good thing, especially due to project having more and more dependencies ( even some weird replace directives in library :), but that is not relevant here )

[mdelapenya]

Indeed. Because we are coupled to Docker, and they have the same replace directives until they release 22.06 (see latest release notes and #629 about that), we were forced to push those directives too. Hopefully resolved soon

[mdelapenya]

Hi @oktalz just to let you know, we released 0.18.0 yesterday, which comes with an interesting feature: it allows customising certain, internal Docker types via 3 modifier functions in the container request: https://golang.testcontainers.org/features/creating_container/#advanced-settings

Please let us know if this ability helps you out under the specific conditions of your test suite.

I'd like to personally thank you for opening this discussion, which led to this change, making us to much better understand the real needs under the request. 🙇 Thank you!

[mdelapenya]

@oktalz ah! I almost forgot it... We removed the replace directives as Docker folks improved their dependencies too

[oktalz]

Thx, I'll give it a chance.

[mdelapenya]

Given this feature has been implemented with the request modifiers, I'm closing this issue as Done.

Thanks for opening this discussion, which led to a feature request!

[aiqency]

For anyone who arrived here Google searching for a quick answer, here it is:

EnpointSettingsModifier: func(m map[string]*network.EndpointSettings) {
    m["networkname"].IPAMConfig = &network.EndpointIPAMConfig{
        IPv4Address: ip,
    }
},

Big thanks to this GitHub repo maintainers and contributors!