Docker-compose v3 format is not supported
alexcase52 opened this issue · 11 comments
TestContainers 1.5.1
18:47:36.971 [main] ERROR ? [docker/compose:1.8.0] - Could not start container
java.lang.IllegalStateException: Container did not start correctly.
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:241) [testcontainers-1.5.1.jar:na]
at org.testcontainers.containers.GenericContainer.lambda$start$0(GenericContainer.java:194) [testcontainers-1.5.1.jar:na]
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76) ~[duct-tape-1.0.6.jar:na]
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:192) [testcontainers-1.5.1.jar:na]
at org.testcontainers.containers.ContainerisedDockerCompose.invoke(DockerComposeContainer.java:442) ~[testcontainers-1.5.1.jar:na]
at org.testcontainers.containers.DockerComposeContainer.runWithCompose(DockerComposeContainer.java:152) ~[testcontainers-1.5.1.jar:na]
at org.testcontainers.containers.DockerComposeContainer.finished(DockerComposeContainer.java:245) ~[testcontainers-1.5.1.jar:na]
at org.testcontainers.containers.FailureDetectingExternalResource$1.evaluate(FailureDetectingExternalResource.java:36) ~[testcontainers-1.5.1.jar:na]
at org.junit.rules.RunRules.evaluate(RunRules.java:20) ~[junit-4.11.jar:na]
at org.junit.runners.ParentRunner.run(ParentRunner.java:309) ~[junit-4.11.jar:na]
at org.junit.runner.JUnitCore.run(JUnitCore.java:160) ~[junit-4.11.jar:na]
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69) ~[junit-rt.jar:na]
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234) ~[junit-rt.jar:na]
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74) ~[junit-rt.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_112]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_112]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_112]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_112]
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) ~[idea_rt.jar:na]
18:47:36.972 [main] ERROR ? [docker/compose:1.8.0] - Container log output (if any) will follow:
18:47:36.974 [dockerjava-netty-1-7] INFO ? [docker/compose:1.8.0] - STDERR: Version in "[...]docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
18:47:36.975 [dockerjava-netty-1-7] INFO ? [docker/compose:1.8.0] - STDERR: For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/
----
And I use docker-compose.yml with version: "3"
Hi @alexcase52,
Yes, v3 is a new format, and we use Docker Compose 1.8.0 by default.
You can either use withLocalCompose() or set compose.container.image to docker/compose:1.18.0 with configuration property (i.e. via testcontainers.properties file on classpath):
https://www.testcontainers.org/usage/properties.html
thanks @bsideup, tried both options - neither worked well. I tried to reuse development env docker-compose.yml with several services. but as I understand docker-compose attempted to start everything from this file which is not what I needed. I need just a single service.
Worked around for now via building GenericContainer with my only service in the code.
@alexcase52 good to hear that you got it working :) Frankly, I would always recommend GenericContainer over Docker Compose, especially together with Networks, because it's so much better and flexible :)
@bsideup, a question to close with this and have simplest possible GenericContainer building code:
I have Dockerfile and a bunch of files in its dir refferred by this Dockerfile. Can I say: this is Dir, there's all what you need, build an image? Something like new ImageFromDockerfile().withFilesFromPath(Dir) or even new ImageFromDockerfile(Dir)?
Thanks @bsideup for your comment - i had the same issue in https://github.com/jonashackt/spring-boot-rest-clientcertificates-docker-compose like @alexcase52 :
STDERR: Version in "[...]docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the serviceskey, or omit theversion key and place your service definitions at the root of the file to use version 1.
First I used .withLocalCompose(true) which worked fine locally (with a current Docker Compose installation on Mac). But this failed on the TravisCI build.
Then I switched to the testcontainers.properties solution, where I upgraded the docker compose version of testcontainers:
compose.container.image=docker/compose:1.22.0
Now everything runs fine - both locally and on TravisCI. Here´s the full docker-compose.yml:
version: '3.7'
services:
server-alice:
build: ./server-alice
ports:
- "8443"
tty:
true
restart:
unless-stopped
server-tom:
build: ./server-tom
ports:
- "8443"
tty:
true
restart:
unless-stopped
client-bob:
build: ./client-bob
ports:
- "8080:8080"
tty:
true
restart:
unless-stopped
I would suggest a general update in testcontainers core to docker/compose:1.22.0 since there are already 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6 & 3.7 as of today. And I think it´s a common use case to just re-use an existing docker-compose.yml, which is also used in other contexts (this is also the case in my example project). And in that case you don´t want to be restricted to such old Compose file versions IMHO. For example restart policys aren´t available in lower versions than 3.0.
But as I don´t have any glue about testcontainer internals, that´s something the maintainers have to decide.
@jonashackt Just to clear out some confusion (or induce even more 😅), restart_policy (as most of the v3 exclusive features) only takes effect when deploying stacks to a swarm (also see Compose file version 3 reference.
TBH I'm also not sure, if v3 is really intended to replace v2 for classic Docker-Compose use.
Still it also might worth discussing if it would make sense to support v3 as well a stack deployment to swarm.
@kiview your right, I also don´t see, why Docker Stack features should be of any use in a testcontainers context. BUT: The problem I see is that I want to be able to re-use my existing docker-compose.yml with testcontainers - without the need to change it. In this case the v3 features are used - not with testcontainers, but in another use case. E.g. my stage or prod deployments.
But it´s also completely ok for me to use the testcontainers.properties file. I was just curious if it would be a problem to just upgrade the base image in the testcontainers core.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.
I think I’d like to keep this open - we should be able to upgrade the image. IIRC the last time I tried it wasn’t so simple and there were other issues, but I can’t remember the details.
Sent with GitHawk
I've added a label so stablebot won't remove it in the future, since I also agree that we should fix it at some point.
Maybe it would be best to support 3.x and 2.x, since both are in widespread use and serve slightly different use cases.
This was resolved in #1847 - release notes here: https://github.com/testcontainers/testcontainers-java/releases/tag/1.12.4