Skip to content

Docker-compose v3 format is not supported #531

Closed

Description

@alexcase52

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"

Activity

  1. bsideup commented on Dec 22, 2017

    @bsideup
    Member

    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

  2. alexcase52 commented on Dec 22, 2017

    @alexcase52
    Author

    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.

  3. bsideup commented on Dec 22, 2017

    @bsideup
    Member

    @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 :)

  4. alexcase52 commented on Dec 22, 2017

    @alexcase52
    Author

    @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)?

  5. jonashackt commented on Oct 3, 2018

    @jonashackt

    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.

  6. kiview commented on Oct 4, 2018

    @kiview
    Member

    @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.

  7. jonashackt commented on Oct 8, 2018

    @jonashackt

    @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.

  8. stale commented on Jan 6, 2019

    @stale

    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.

  9. rnorth commented on Jan 6, 2019

    @rnorth
    Member

    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

  10. kiview commented on Jan 6, 2019

    @kiview
    Member

    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.

  11. rnorth commented on Dec 7, 2019

    @rnorth
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions