Allow providing a network alias

[ctron]

The argument --network-alias may be used to influence the name of container in the docker network. Otherwise the container is only available by its ID or name.

It would be useful, if you want to orchestrate a few test containers, which need to communicate with each other, to allow providing the network alias, in order to have predictable DNS names. Compared to using the ID or name (which might clash).

[thomaseizinger]

The name of the container can be set per run invocation using RunArgs. You can thus provide individual names to containers of the same image. Does that not work for your usecase? How would providing a network-alias be different?

Docker has many features and am I not planning on exposing all of them through testcontainers unless they provide significant value to using containers in test environments.

[ctron]

The name of the container can be set per run invocation using RunArgs. You can thus provide individual names to containers of the same image. Does that not work for your usecase? How would providing a network-alias be different?

The difference would be that you can have the same name (e.g postgres) on different networks. Using instance names, you can have only one instance of postgres.

This prevents you from running multiple tests in parallel.

[thomaseizinger]

The difference would be that you can have the same name (e.g postgres) on different networks. Using instance names, you can have only one instance of postgres.

Thank you for the explanation!

This prevents you from running multiple tests in parallel.

Running multiple tests is parallel is something we want to definitely support and is in fact one of the main reasons we created testcontainers-rs!

From your description, it sounds like the primary thing a user would want to control is the network alias and not the container name?

I am trying to minimize the configuration options a user needs to understand and having both, container name and network alias was at least confusing to me. Do you think it would be acceptable to remove the name parameter in RunArgs in favor of network-alias?

Can you think of a usecase within testcontainers in which you would want to specifically control the container name and not the network alias? From what I can see, a container's name is primarily useful as an identifier for managing the lifecycle of the container (start, stop, etc). Given that we do this for the user in testcontainers, I am inclined to remove the name in favor of network-alias to make parallel tests work out-of-the-box.

[ctron]

I see your point. I am not sure, though if removing an existing parameter is a good idea :) But I also don't see any real reason to use a name, as you can "get" the ID of the container, if you need to access it from the tests (like shelling into the container).

Maybe other people have different opinions or more insight into this.

[thomaseizinger]

I am leaning towards replacing name with network-alias because the latter provides clear advantages and for now fulfills all usecases of the former within testcontainers.

If someone comes up with a usecase for name, we can consider re-adding it.

Happy to merge a PR that replaces name with network-alias in RunArgs. Should be accompanied with some good documentation because at least to me, network-alias was unknown and I would consider myself an average docker user.

[clD11]

Is this issue still open? I am happy to take a look

@thomaseizinger @ctron

[thomaseizinger]

Yes, still open!

Let me know if you have any questions :)

[DDtKey]

Hello everyone who is interested in this issue!

Status update for this task:

• still relevant, we need to provide the ability to specify an aliases
• no need to remove the container name config, they are not directly related

---

We could go with such approach:

• introduce with_net_alias(..) to RunnableImage (I don't see a use-case for Image, but it makes sense for RunnableImage)
• it is necessary to slightly rework the current logic of working with network in order to support this:
  • instead of using network_mode config on creation of a container, we need to create the container and then connect it to the network with aliases (API allows to pass aliases only on connect call)
    • create a container (already exists, but need to create without network_mode)
    • create a network if necessary (already exists)
    • connect the container to the network with these aliases

However, there is a missing fact here, not mentioned before: aliases belongs to the network, not to the container (i.e container may have different aliases across different networks). Instead, we can consider such approach:

• extend Container & ContainerAsync to have methods connect(net: Network) and disconnect(name: String)
• connect accepts Network which consists of: name, aliases and reconnect flag

Thus, we have the following benefits:

• quite easy to maintain and use
• possible to add aliases
• allows to connect/disconnect/change aliases dynamically
  • possible to connect multiple containers together on the fly
  • can be used for specific tests, e.g: unresponsive connections
• extendable API
• we still may add with_net_alias for RunnableImage which in fact will utilize the api of created container to connect with aliases (but separately, out of scope for this task)