Nicolas De loof

`x-aws-protocol` must be set within the `port` definition of your service, aside `protocol` using the long syntax

Fargate indeed does not offer tmpfs support (see https://github.com/aws/containers-roadmap/issues/710) On the other hand Fargate supports [ephemeral task-storage volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-storage.html), that we could use for comparable purpose. I'm not sure anyway this...

Compose-spec introduced support for `depends_on: { condition: service_completed }` which is an initial step toward init containers support, but the actual way to get them expressed within a compose application...

@dalegaspi could you please describe your use case, so we better understand how this can fit into the compose model, and how the compose file format could evolve to embrace...

thanks for the details. so, basically, you're using a sidecar to add servicemesh feature to your deployment, which maybe could be supported using AWS AppMesh for better integration with the...

I totally agree there's technical challenges offering portability, but - typically - Compose model does define a `logging` section where I'd like I can opt-in for `FluentBit` or anything comparable,...

sure, I'm not saying there's no use-case to require sidecars, just it seems to me most use-cases are actually implementation details for many modern infrastructure services (routing, security, monitoring, retry,...

@mreferre here again, I'd tend to ask "why do you need nginx as a (sidecar) frontend to your django service? Doesn't AWS offer something comparable directly implemented by the infrastructure...

Just a quick note that, from a technical standpoint, Compose _does_ support sidecars in the sense you can define namespaces to be shared (`network_mode: "service:foo"`). Obviously, as this is mixed...

This repo is about docker compose, not "cloud integration". @glours could you please transfert to docker/compose-cli?