I have an application running using docker-compose.
Now I'm migrating the application to be hosted on ECS.
I'm translating the docker-compose settings to the boto3 ECS equivalents.
Unfortunately I don't find an equivalent of docker-compose's command in the AWS CLI.
ECS does not contain a docker-compose command. Instead you will specify a task definition file that contains all the definitions of a service and the containers that reside within it.
The ECS service will then deploy this based on the task definition, you simply define parameters such as how many of these tasks are operating at once.
You can however use the ecs-cli tool to perform this migration for you, using the ecs-cli compose command it can take the docker-compose file and perform those translations.
Take a look at the Using Docker Compose File Syntax page to see which parameters are supported from a docker-compose file.
You can use container transform with boto3, that will convert docker-compose to equivalent ECS task definition. this is also base on python.
container-transform is a small utility to transform various docker container formats to one another.
Currently, container-transform can parse and convert:
cat docker-compose.yml | container-transform -v
Also suggested tool by AWS ECS road map.
we're unlikely to support the docker-compose format directly in our APIs. But, would a tool like container-transform to transform a docker-compose file into an ECS task definition work for you? Then you can use the resulting ECS task definition file in boto.
You can also use ECS ComposeX which will allow you to keep using your docker-compose definitions as they exist for local purposes as it does not introduce any unsupported extensions for docker-compose, but will also allow you to defined RDS/DocDB/DynamoDB/Kinesis and plenty other options that you can automatically link to your services.
When ready, ComposeX will transform all of that in CFN templates, containing AWS ECS definitions and all necessary resources, that are logically linked to work together but equally self-sufficient (so you can deploy things separately, like DBs for example).
All templates are automatically parsed and validated through cloudformation API (to the best of its abilities). It is purposely aimed at working with AWS services, and follow all best practices, including allowing you to define least-privileged access from/to services and AWS resources.
It supports autoscaling, creation/use of existing ECS clusters and is aimed to make workloads primarly on Fargate but also on EC2 instances.