Repository navigation
DockerComposeContainer inconsistently appends "_1" to service/image names #149
Description
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";
Activity
rnorth commentedon May 28, 2016
Hi Luis,
It's docker compose that's appending the
_1to 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 commentedon May 31, 2016
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:
withExposedServicemethod name is inaccurate, because it's not taking a Docker Compose service name as argument but instead a container name.Two strategies I could think of, but I don't know if they would work:
withExposedServicethat is not a container name, and this failure would happen, try again with_1appended to the service name.ldcasillas-progreso commentedon May 31, 2016
Actually, maybe this command is what you want? Dunno if your upstream libraries provide it:
rnorth commentedon May 31, 2016
@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:
withExposedServiceends 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._1withExposedServicemethod 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 commentedon May 31, 2016
Sounds good! Thanks for your hard work.
Implement smarter options for specifying compose service index as per #…
Implement smarter options for specifying compose service index as per #…
Implement smarter options for specifying compose service index as per #…