I have been working through creating an ECSTask as an infrastructure block for flow deployments and through extensive trial and error found some observations that were not part of the documentation: 1. If setting a

task_definition

,

containerDefinitions.name

must be “prefect”. Otherwise the new registered task definition will contain two separate

containerDefinitions

items and runs will fail. 2. I believe that the

command

parameter has to be blank/null, otherwise your flow will not be run properly. 3. If using the

task_customizations

parameter, you must cast your array(dict) as a

JsonPatch

object otherwise the pydantic validation will fail. This conflicts with the documentation and the examples in the

dataflow-ops

repo (@Anna Geller)

task_customizations=JsonPatch([
        {
            "op": "replace",
            "path": "/networkConfiguration/awsvpcConfiguration/assignPublicIp",
            "value": "DISABLED",
        },
    ])

#1 thanks so much, I'll add this #2 it will be overridden by infrastructure block anyway, so this shouldn't matter - if you see some behavior that doesn't match your expectation, please submit a GitHub issue with a minimal reproducible example and tag me, I'll reproduce and ask the team #3 I couldn't reproduce, works as it

#2 is not overridden. If you specify a command, we will use it instead of our default. You can use this to run commands then enter the Prefect engine yourself.

thx Michael and sorry that I'm spreading the wrong info here but @Zanie I had an image for the agent with an entrypoint:

ENTRYPOINT ["prefect", "agent", "start", "-q", "default"]

and I was able to use the same image for my flow run container on infra block without specifying any command. I guess my misinterpretation was because: • regardless of what entrypoint is set in Dockerfile, if some command is explicitly set on the infra block it will be used • if no command is set, we take this base run command correct or still wrong?

well there’s a difference between the ENTRYPOINT on the image and the

command

set on the

DockerContainer

block

this line is what I meant: we never use the one set in Dockerfile, we always override:

"command": self.command or self._base_flow_run_command()

Well generally Docker containers run things as ENTRYPOINT <COMMAND>