ooh that sounds very interesting! no it doesn't support that at the moment, and your understanding of the "backend app" is correct.
However, we have a design ready for a
task run command which sounds similar: aws/amazon-ecs-cli-v2#702. Is this what you envisioned? or did you have some other usecases in mind with the step function?
Hi @dougtoppin !
There is not a cluster version in the manifest right? An update to the my task code and deploy did not show a version change for the platform?
That's right, we just use the LATEST version of the Fargate platform while creating the ECS Service. You might find this article interesting that explains how tasks get their platform version: https://aws.amazon.com/blogs/containers/aws-fargate-platform-versions-primer/
Yea, what Efe said :D We also have work planned for a
local experience, that will generate a docker-compose file as well.
For example, if you have a front-end and back-end services, and you want to work on the front-end service, you could run ecs-preview local, it'd generate a docker-compose file that uses your local code for front-end and pulls down the image from the back-end service (and generates a network that looks like your VPC network).
@kohidave Working at a fairly large company and networking aspects are managed by an external group. We have as many internal systems as public/external.
We have automation around ECS clusters / services (public and private) behind ALBs as well as NLB... based on
ecs-cli v1. We've been talking about adding more features and a lot of them seem to be planned for
The abstraction to
application type is something we've talked about. Managing the build pipeline is good (we have jenkins templates atm and experimenting with github actions cicd).
One technical aside... if I understood the web presentation... many
applications (say services) could be sharing an
ALB. Is that true? This is a hack we put in our automation, to re-write the rules, as the ALB API did not support modifying rules independently. Did I miss something there? So, we run N services in a cluster and have 1
public ALB and 1
private ALB... shared by all the services.
Support for Task and Scheduled Task is something we have demand for... as an alternative to lambda
that's awesome! Those are some of the next set of patterns we're going to release
We're exploring renaming our commands from
ecs-preview project and
ecs-preview app to
ecs-preview app and
ecs-preview svc respectively. Our intuition says that using "application" and "service" while getting started with the CLI will be more intuitive.
Does anyone have any concerns or feedback? all thoughts are welcomed :D
I don't think there would be any change in terms of workflow for the devs using the tool.
The goal behind it is really to get to a terminology closer to customers, and have a more natural way of describing your application.
The "SweetDogs" application is made of "woof" and "bark" load balanced web services and a "newsletter" cron job.
Basically, it allows us to distinguish the types of components in your application and provide them as commands
svc init --name fe --app SweetDogs or
job init --name newsletter --app SweetDogs.
Hi everyone! It's party time 🎉
We just released v0.0.8: https://github.com/aws/amazon-ecs-cli-v2/releases/tag/v0.0.8
It has some pretty cool features:
app statusdisplays the health status of your service and tasks
Backend Appwhich allows you to create a service that's not accessible from the internet.