good morning everybody - i have an "execution envi...
# prefect-community
r
good morning everybody - i have an "execution environment" question: is it possible to have an agent running on a micro EC2 instance that deploys flow runs as ECS tasks? i know in 1.x we could spin up an ECS agent that would automatically do that, but in 2.x it seems like we would manually have to stitch that piece together? this repo shows how to spin up an agent running on ECS in 2.x which is cool, but the infra in the deployment is still
Process
- which means the flow run will be executed in the same container that the agent is running - am i understanding that correctly?
2
d
that’s how it stands now ya. there’s a ticket on the
prefect-aws
project about an ecs task deployment target https://github.com/PrefectHQ/prefect-aws/issues/39, so hopefully changes will be visible there
🙌 1
a
am i understanding that correctly?
yes you do! the idea here is that you have one container and one agent/work queue per project and this project can have multiple flows with shared dependencies i.e. one project = one repo = one ECR image = one ECS agent/work queue possibly tagged with the project name and project name as work queue and multiple flows running in a Process within that conatinerized process
we are working on ECS integration but this setup is useful because it avoids unnecessary latency that you would get when spinning up serverless container for every single flow run many users don't have different dependency requirements for every single flow but rather per project -- this is what this setup is for
🙌 1
I haven't documented that yet due to time, but wanted to share already since it's already working if you can figure it out already
r
anna you have done enough haha - i've only been peeping the docs/discourse for the past few days and have seen your name like 8000 times so i appreciate everything you are doing great point on the latency piece - makes a lot of sense. so it seems like we can either spin up an ECS agent and run flows in that same container (using infra=
Process
), or we can use an EC2 instance for our agent and run flows on that same server (also using infra=
Process
). both will pretty much achieve the same thing it seems - low latency for deploying flow runs and not super compute intensive especially if our flows are pretty lightweight. makes sense! thank you!
❤️ 1
a
100% yes, but here:
or we can use an EC2 instance for our agent and run flows on that same server (also using infra=
Process
)
if you have an agent on EC2, you can also use DockerContainer infra block since EC2 can run both subprocesses and docker containers
r
perfect - is there any benefit to using DockerContainer over process? does it have to do with limited cores or something like that?
a
it's just a different setup -- if you need per-deployment isolation, one container per flow run could be helpful
💯 1
👍 1