DockerComposeContainer inconsistently appends "_1" to service/image names

[ldcasillas-progreso]

This code doesn't work, for reasons that strike me as a bug:

    public static final String RABBITMQ_SERVICE = "rabbitmq";
    public static final int RABBITMQ_PORT = 5672;

    public static DockerComposeContainer environment() {
        return new DockerComposeContainer(new File("docker-compose.yml"))
                .withExposedService(RABBITMQ_SERVICE, RABBITMQ_PORT);
    }

The problem seems to be that some piece of code is appending the string "_1" to the value of RABBITMQ_SERVICE, but it's not being done consistently in all contexts where it's required. So when the test starts it logs this:

[pool-3-thread-1] INFO 🐳 [dduportal/docker-compose:1.6.0] - STDERR: Creating 5ripbx_rabbitmq_1

But then later it errors this way (over and over, like in #147 ):

[pool-1-thread-1] ERROR 🐳 [richnorth/ambassador:latest] - Could not start container
org.testcontainers.shaded.com.github.dockerjava.api.InternalServerErrorException: Could not get container for 5ripbx_rabbitmq

The error goes away (i.e., I get #146 instead) when I make this code change:

    public static final String RABBITMQ_SERVICE = "rabbitmq_1";

[rnorth]

Hi Luis,
It's docker compose that's appending the _1 to the container name, so it's not entirely unexpected that you have to use this when referring to the container, although I'd agree it's not all that desirable.

I don't think we'll be able to avoid this, but we could probably make it more obvious to users by logging all the created container names and/or using this list of containers to fail-fast when a non-existent name is used.

I'll try and roll this in to general improvements on docker-compose support.

Richard

[ldcasillas-progreso]

Am I understanding this right, and the big problem here is that Compose doesn't provide an easy way of programmatically getting a container name from a service name? I couldn't find one in five minutes, for sure!

I'd think that in your position I'd want to, even though it'd be a drag, do something here to try and ape Compose's container logic at least a bit. Otherwise:

1. Your withExposedService method name is inaccurate, because it's not taking a Docker Compose service name as argument but instead a container name.
2. You're going to get an endless stream of bug reports on this issue, because everybody would run into it.

Two strategies I could think of, but I don't know if they would work:

• When a name is provided to withExposedService that is not a container name, and this failure would happen, try again with _1 appended to the service name.
• Read the Docker Compose YAML file and extract the service names, so that we can recognize when the user has given a service name. This makes the guessing strategy perhaps a bit more robust (since you can only do the guessing when you know for sure that you were given a service name), but I pain at the thought of anybody having to maintain this!

[ldcasillas-progreso]

Actually, maybe this command is what you want? Dunno if your upstream libraries provide it:

• https://docs.docker.com/compose/reference/port/

[rnorth]

@ldcasillas-progreso it's a fair point about the method name :) Perhaps we should go with something like the first strategy you propose. For me it feels marginally safer if the cleverness around appending an index is a dumb-but-consistent approach rather than depending on the state of the containers:

• If the name parameter to withExposedService ends with _ + any digit, just behave as currently. This keeps current code from breaking, and allows control for people who are deliberately already targetting a specific value.
• If the name parameter doesn't end with this, append _1
• Have an additional withExposedService method that takes an extra integer param for the index.

What do you think?

For context, I have recently done a bit of work to enable scaling of compose containers, so the container index number will become all the more important!

Thanks for your suggestions on this!

[ldcasillas-progreso]

Sounds good! Thanks for your hard work.