ecs_composex VS troposphere

If you have read my earlier posts or heard me talk with Corey on Screaming in the Cloud, I am the author of a tool called ECS Compose-X. It's designed to support all the docker compose features, and allow for extensions that make it easier to deploy to AWS.

Now, given you already have a docker-compose file, you could deploy to AWS in just a few minutes (assuming you have an account, and can pull the docker image from somewhere, like AWS ECR) with ECS Compose-X (GH|Docs). You can have a look at the wordpress demo on how to take your docker compose file as an input and let compose-x deal with everything (security, networking etc.) for you.

Hope this might help https://github.com/compose-x/ecs_composex/blob/main/.cicd/buildspec_manifest.yml It does not use build-list but I got everything working in that way.

In case you want to deploy infrastructure with some services running on ECS (planning on adding lambda to that mix though) and other AWS resources, i.e. Dyn tables, RDS etc., you could do something very nice using ECS Compose-X (GH) CFN Macro

If you happen to have a docker-compose file locally that you used for dev testing, try ECS Compose-X (GH) which will parse that, render CFN templates and allow you to deploy the services in AWS ECS. If you have existing VPC and ECS Cluster, it can do discovery based on tags or just give it the subnets or cluster to use, as-is, it will take care of the rest (networking. IAM etc).

docs and source code

So, I created ECS Compose-X (docs) which covers 99% of our use-cases to date. The idea behind it was to allow developers to do exactly what you described: have one docker-compose.yaml file which describes the services, and use override files for each environments.

I started using Troposphere when writing Compose-X because at the time CDK did not have Python support and once CDK had python support, the variable names for the resources properties were all changed from the original CFN definition.

ECS with AppMesh works like a charm. I will find you back my example app to show you, but I have created a project commonly called compose-x which would allow you to declare your services in docker compose format and declare your mesh nodes/routers/services as well and it will automatically create everything necessary for your services and the mesh

Seems like an interesting generalized mix of something like https://github.com/cloudtools/troposphere and Ansible from a glance.

The value add would be unifying provisioning and configuration management in a Python-y experience? The lifecycle of each is distinct and that's traditionally where the headaches of using a single tool for both has come in

Under the IaC category, in July 2023, AWS added loops to CloudFormation, finally ticking a box the community has been asking for since troposphere. I suspect that, in combination with the Terraform licensing changes, it may keep people using CloudFormation for a while longer.

Because ECS Compose-X uses Troposphere, I was able to create a very light and simple python library(https://github.com/JohnPreston/troposphere-awscommunity-applicationautoscaling-scheduledaction) to distribute the resource for other Troposphere users to re-use.

Written in house, but the library troposphere is the primary component of how it is built. Example stacks are here.

I am kind of going off topic here, but isn't the point of being an SA to be created with code services to deliver solutions at scale that are cost-effective? How in the hell can you do that when you can't write a simple Python template that generates code at 50 times the rate you can manually? How can you ever be expected to deploy a serverless solution if you can't write any code yourself? There has to be some level of proficiency there.

Wouldn't using troposphere[1] be easier?

[1] https://github.com/cloudtools/troposphere

You might have seen some tutorials on how to set up S3 buckets using the AWS Console. This works fine, but I'm a firm believer of managing your resources with code. I've chosen the native solution of AWS, called AWS CloudFormation. This makes it easier to reproduce the setup if I ever need to tear it down of move it to another account or region. Below is the full CloudFormation template, I've used a framework called Troposphere, a Python library that creates CloudFormation.

For CF for example I no longer write template in yaml or shudders json, and instead I use troposphere.

refer : https://github.com/cloudtools/troposphere