@Marvin in prefect 2 what is the environmental variable to set to specify the flow path?

It looks like the environment variable you're asking about is

PATH

and

PREFECT__FLOW_PATH

. You can find more detailed information about this in the [Prefect Documentation](https://docs.prefect.io/ui/flows/), especially in the topics on Flows, Deployments, and Logging. Hope this helps!

There is no environment variable for this in Prefect 2

I think it is

PREFECT_LOCAL_STORAGE_PATH=

, I am trying to tell prefect where to look for a flow when building a deployment from flow without specifying storage (flow logic is in the container, as is the flow files).

What’s the entrypoint for your deployment?

there isn't one. we found setting one caused execution of the entrypoint and the flow when the flow ran on the deployment infrastructure (

ECSTask

)

That’s a little confusing — the entrypoint is how we load the flow for execution

correct.

Sounds like you’re calling your flow in the file then?

it was guarded. No matter what we put in the entrypoint, it was executed along with the flow.

Setting the local storage path won’t make us look for a flow there

well, it's running fine no entrypoint with github storage, but with I think Prefect 2.5.x > < 2.7.x it reported a

shutil.copytree

error when using local storage

it would be easiest to use Prefect base image and then using /opt/prefect/flows as work dir should make Prefect look in the right place, could you try that?

FROM prefecthq/prefect:2-python3.9
WORKDIR /opt/prefect/flows

Interesting. We are probably not using prefect as intended then. We now have it working with the above Dockerfile (removal of the

PREFECT_LOCAL_STORAGE_PATH

envar breaks the flow. Here is a brief overview of how we are deploying Prefect v2 with this method: 1. a flow-centric image is created in AWS CodeBuild based on Dockerfile and is pushed to ECR. 2. CodeBuild fires off a script that spins up an ECS Task in the targeted AWS environment 3. ECS Task creates a task definition using the image created in CodeBuild, it overrides some things and adds sidecars to the new task definition 4. Above task definition is passed to prefect deployment script, which creates an

ECSTask

infrastructure block and then builds the flow (or flows) and registers them with prefect

Prefect 1 and 2 are entirely different products and they have very different deployment patterns • v1 ECS example • v2 ECS example

I think our biggest challenge migrating to v2 was to allow the addition of sidecars and avoiding getting the too-many-revisions to a task definition issue. Our current deployment strategy is working as expected albeit probably not what it was designed to do. Some things with

ECSTask

creation had to be modified (providing

task_definition_arn

and

auto_deregister_task=False

) to allow for us to use sidecars for logging to DataDog (among other things) and avoid the too-many-revisions. In our workflow, once a flow is "deployed" it is the source of truth until overwritten by another "deployment". The source of all this discussion was removing the need for a

Github

block and using the flow stored in the image, which the addition of the envar

PREFECT_LOCAL_STORAGE_PATH

solves (magically). This strategy allows us to deploy multiple

ECSTask

infrastructure blocks (`EC2`|`Fargate`) with varying amounts of memory and cpu. Downstream workflow logic determines the infrastructure flow to run (e.g.

-ec2-light

or

-fg-heavy

) in the flow name, which for light processing that is needed to complete quickly we use

EC2

with low resource request.