Open JohnTigue opened 1 year ago
ECS wants to load Docker images from ECR, so this is the natural solution, according to at least two different sources. I.e., this seems like the way to go. See also SD on ECS
(#58).
Here's proof that AWS has made sure that ECR works well in VS Code: Working with the Amazon Elastic Container Registry service in VS Code.
See previous ECR work in dev_tools repo: https://github.com/ManyHands/dev_tools/issues/86
in my pipelines I deploy the ECS Tasks through CloudFormation templates and the CloudFormation stack update is part of the pipeline. That way I update the ECS Task definition automatically every time I push a new image to non-prod ECR
I'm starting to wonder if AWS isn't trying to steer us into their CLI copilot for build tooling as well as.
You can even deploy clusters via copilot CLI: Deploy a clustered application to Amazon ECS by using AWS Copilot
I guess that they realized, "sure, everything CAN be done with just aws-cli, but what a hassle." The aws-cli doesn't know anything about Docker. So, they cranked out copilot, an AWS CLI that knows about Docker.
Cobbling together Docker images and parking them in ECR is the easiest way I can see out of the SD config nightmare that is looming: Why are Stable Diffusion ui's extensions such a nightmare to install?!
I wonder if this ECS copilot
CLI is the best way forward compared to the other options such as: raw CloudFormation or SAM, or CDK, or let alone full on Kubernetes tooling. It's still a full reproducible CLI process that knows about Docker on AWS (i.e. ECS).
So, first do things in the webui AWS Console. Then translate that to copilot
then use copilot
in the build system?
Looks like this is going to be: