Adds support for podman-compose

[masonmahaffey]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[awlawl]

I will take a look at this tomorrow. Thanks for your contribution!

[awlawl]

Ok so far so good on my testing. I tried each tool individually so I could make sure that the command availability was working. My only concern is that the output of the config command on docker-compose vs podman-compose is different:

docker-compose.yml Example:

version: "3.7"
services:
  0713demo:
    build: ../../../
    image: ghcr.io/warnermedia/fargate-default-backend:v0.9.0
    ports:
    - 3000:3000
    env_file:
    - hidden.env
    labels:
      aws.ecs.fargate.deploy: 1

Produces this in docker-compose v2.23

name: test
services:
  0713demo:
    build:
      context: /Users/allenlyons/Documents/code/testing/0713demo
      dockerfile: Dockerfile
    environment:
      FOO: bar
    image: ghcr.io/warnermedia/fargate-default-backend:v0.9.0
    labels:
      aws.ecs.fargate.deploy: "1"
    networks:
      default: null
    ports:
      - mode: ingress
        target: 3000
        published: "3000"
        protocol: tcp
networks:
  default:
    name: test_default

But this in podman-compose:

services:
  0713demo:
    build: ../../../
    env_file:
    - hidden.env
    image: ghcr.io/warnermedia/fargate-default-backaend:v0.9.0
    labels:
      aws.ecs.fargate.deploy: 1
    ports:
    - 3000:3000
version: '3.7'

The important difference here is that docker compose expanded the environment variables that were in the hidden.env file, but podman doesn't. When I use fargate service deploy -f docker-compose.yml in an environment without docker-compose (so that it uses podman) it doesn't actually use the values within hidden.env.

I wouldn't say this is a bug in either the Fargate cli or podman-compose, but it is just a side effect of how it handles the config option. The fargate cli expects the variables to be expanded and normalized, it doesn't read env_files. Long term, the real answer has been to not use either commands to accomplish the compose format, but to use a Compose parsing library, but I know that will be a much larger change.

I'm not sure how much of a deal breaker this is. Deploying via docker-compose.yml hasn't been especially popular among the teams I've worked with. But I'd like to hear what you think.