docker compose up (in ECS context) fails silently when a malformed compose file is detected

[mreferre]

I am using the ECS / Compose integration and it seems there have been a regression in how compose file errors are being handled.

I am using Docker Desktop 4.0 and this is the docker version:

➜  Downloads docker version
Client:
 Cloud integration: 1.0.17
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:20 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:52:10 2021
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
➜  Downloads 

If you try to edit a malformed docker-compose.yaml file as in:

services:
  web:
    image: nginx:latest
    ports: 80:80

The docker binary in the default (local) context will complain (rightly so):

➜  Downloads docker compose up -d  
services.web.ports must be a list
➜  Downloads

However, if you move to the ecs context and try to up the same file it will just fail silently:

➜  Downloads docker context use myecscontext
myecscontext
➜  Downloads docker compose up              
➜  Downloads 
➜  Downloads docker compose convert
➜  Downloads 

Nothing happens. No error message, anything.

If you fix the typo in the compose file the file is interpreted and brought up just fine in both contexts.

I am fairly sure I got compose files "wrong" in the past and there were always an indication of a problem in the ECS context. I have never seen it failing silently like this (IIRC). Even if this is how it's always been working a proper handling of error messages would be required.

[MartinSchere]

Same thing happening here, but I don't have a malformed docker-compose.yml, when I run it with default context it's OK but when running with ECS I just get no output.

[Jaydeehow]

I'm getting the same thing with the ECS context. Fails silently, and exits with return code 15, which I can't find a reference for in any docker return code documentation.

[MartinSchere]

This is apparently due to an error in the compose file of some sort, maybe a typo somewhere or a feature that's not supported in this type of compose environment. For me it was the volumes, Azure for example does not support shared volumes for docker.

Would be great to have that in the stderr

[mreferre]

Yes. It doesn't appear to be related to a specific misconfiguration in the compose file. It just doesn't complain about it (which makes it harder to debug)

[lucassscaravelli]

Same thing happening here. Unfortunately I'm having to test adding instructions one by one in compose file. On github actions I'm getting Error: Process completed with exit code 14.

So I decided to up a very simple docker compose like this:

services:
  my-redis:
    image: redis

And the docker compose up command worked. After that, adding more services in this file and I'm getting the errors.

[chrisdeely]

also experienced this while attempting to deploy to azure using a malformed compose file. use docker-compose -f compose-file-name.yml config to validate and detect the errors until this is fixed

[MrChrisRodriguez]

In my case, it was the name property that was causing it to fail silently. Debugging this is a nightmare.

[siourdas-vasilis]

having the same issue... error Error: Process completed with exit code 14.

I fixed my "malfunctioned" file thanks to @chrisdeely , by changing my file version to 3.7 but it still fails on GitHub-Actions..

[smackesey]

I have docker compose -f my-compose.yml config working well, but docker compose -f my-compose.yml up gives mysterious error:

$ docker context create ecs --local-simulation abcdefgh
$ docker --context abcdefgh compose --file my-compose.yml up
Command "compose images" not available in current context (abcdefgh). "not implemented"

[Cliftonz]

I think this might have something to do with compose v2. As soon as I switch to v1 I started getting output.

[mquadrat]

In order to find out what's wrong, switch back to default context and run docker compose config. After everything is fine switch back to your ECS context. Even docker compose config gives no output within the ECS context.

[prescod]

Both Amazon and Docker should be embarrassed that this customer-hostile bug has stayed open for so long!

[MattSzymonski]

Same issue for me. I fixed it by removing "name" property (container group name) from docker compose file. It seems that it is not supported.

[eugenmihailescu]

Same issue due to name property (docker fails silently with exit code 15), which is odd since it is supported (as per docs). Supported != a non-malformed config.

Client:
 Cloud integration: v1.0.32
 Version:           23.0.3
 API version:       1.42
 Go version:        go1.20.3
 Git commit:        3e7cbfdee1
 Built:             Mon May  8 21:04:05 2023
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          23.0.4
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.20.3
  Git commit:       cbce3319305c39df3405c969a12e0a5d2bad3f4f
  Built:            Mon May  8 20:47:10 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.20
  GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc:
  Version:          1.1.5
  GitCommit:        f19387a6bec4944c770f7668ab51c4348d9c2f38
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad007797e0dcd8b7126f27bb87401d224240