Follow up post for anyone that uses ECS workers. H...
# ask-community
s
Follow up post for anyone that uses ECS workers. How do you configure them? I have a
task_role_arn
and an
execution_role_arn
I want to set in my provisioned ECS worker service, but have no idea how to do so. Right now I am trying to use sed to manually modify a template on worker launch (which first tries to create a work-pool with the sed-modified template), but this is a code smell I'd love to get rid of. Ideally I'd love to simply do this via an environment variable, but nothing in the documentation here or here seems to indicate you need to either hardcode them in a template or specify it explicitly in the deployment.yaml (the latter not being ideal because a deployment shouldnt need to know about infrastructure subnets). Similarly, the documentation here shows a bunch of configuration options like the arns and vpc_id, but not the ways you can set this configuration. I'm really at a loss with this one
My current (not quite working) solution for reference:
n
hi @Samuel Hinton - have you checked out using variables ? which are automatically rendered into work pools job templates that’s essentially what you seem to be doing with sed here, except you wouldn’t have to recreate the work pool, and you can selectively override different job variables for deployments if you want
https://docs-3.prefect.io/3.0rc/develop/variables#in-prefect-yaml-deployment-steps goes for job_variables sections or the base job template itself
s
Hey @Nate, thanks for the link. I think the main blocker is that variables seem to be documented as a cloud feature here: https://registry.terraform.io/providers/PrefectHQ/prefect/latest/docs/resources/variable
n
variables are not a cloud only feature, and overrides can happen at the deployment/flow run level (using variables or hardcoding) so deployment authors can do it without engaging with your iac / tf (if you want, you control what’s templateable in the work pool)
does that help? i can provide an example later when at my keyboard
s
Ah awesome, might just need to remove the Cloud reference in the doc there to help out. I'll see if I can get variables working, though the big thing right now is setting up a local terraform provider - the prefect server is just another service the same as the worker, so technically the provider doesnt exist at the plan stage.
Hey @Nate so I think this could work - I've manually made the variables to test things, but my flow is crashing right now. Fair enough, I've probably done something wrong. But I cant actually find any way to see what the ecs task was launched with. Ie I have a
vpc_id
variable, and want to confirm its being set in the deployment, but I can't see any information about the ecs task variables in the logs, Details, Parameters, etc, of the crashed flow. Do you know how to view that final deployment configuration?
n
for a given flow run, you can always check out the configuration tab on the flow run detail page to see the job variables used for that flow run (which is a merge of the work pool | deployment | flow run job variables) or you can read the deployment object to see what’s on there does that help?
s
Ah yeah the configuration tab is not showing me any of the variables I have. I've defined both the vpc_id and the network_configuration (screenshot 1), but the deployment doesnt seem to pick those variables up at all (screenshot 2)
I guess maybe the issue is that variables don't automatically resolve? I've been assuming that because my base template has a
{{ vpc_id }}
in it, that it will pick up a
vpc_id
variable. But from this page maybe I need to have every deployment yaml specify something like
vpc_id: "{{ prefect.variables.vpc_id}}"
If that's the case, then please let me know and I'll put the sed command back, as I dont want every downstream flow having to configure infrastructure networking when I can just munt the template to add defaults 🙂
(And thanks for the info so far @Nate, really appreciate it)
catjam 1
n
you can put variables (yep you need the prefix "namespace"
prefect.variables.
e.g.
{{ <http://prefect.variables.my|prefect.variables.my>_vpc_id }}
, since just
{{ vpc_id }}
would look in the above
variables
section for a job variable by that name, not a Prefect Variable in your workspace - we could document this better) in the base job template of your work pool, meaning downstream deployments do not need to configure this job variable perhaps you're fine with hardcoding the vpc_id in your template (since deployment creators wont need to configure it), I just suggested a Prefect Variable since it would provide a clear place for you (or other infra configure-ers) to set this value without messing with the work pool, or needing to re-run something like your sed'd
prefect worker start
command if that vpc value changes, since we render that template at runtime, and therefore the current value of that Prefect Variable would be the thing that matters i'm technically out of office this week but ill work on adding an example / clarifying docs on this when i get back, since I think we need some more color on this in the docs
in the meantime, here's a broad strokes example of what I'm expecting here (just using sdk for my convenience in making an MRE) - i hit some error that ill look into later
Copy code
Value error, The variables specified in the job configuration template must be present as properties in the variables schema. Your job configuration uses the following undeclared variable(s)
s
Ah that client example is super useful, let me see if I can get something working with that, I'll report back asap and let you know if it worked. Hopefully I can help contribute to the docs in this case because 100% acknowledge that I've gotten really confused trying to put all these puzzle pieces together
Hmm so as Im trying to get this working with variables as well, I notice that the Variables and WorkPool create not having an overwrite or exist_ok equivalent is super clunky. Im having to duplicate everything so it tries a create and on failure then tries an update. Ie its so much easier to use
Variable.set(name,  value, overwrite=True)
than something akin to
Copy code
try:
    client.create_variable(...)
except PrefectHTTPStatusError as e:
    if e.code == 409:
       client.update_variable(...)
but apply that to create work pool vs update work pool Ive reproduced the same error too, but am struggling to fix it.
EDIT: no luck getting this working with my super limited knowledge
Found a similar slack thread running into the same issue and this doco issue was raised from it: https://github.com/PrefectHQ/prefect/issues/12201
Hey @Nate, assuming you're back from holidays, do you have any furhter ideas as to how to use
client.create_work_pool
without that variable error? If I can get it working I'll put it in the github link for posterity
m
(side note: thanks for the docs feedback @Samuel Hinton, I opened https://github.com/PrefectHQ/terraform-provider-prefect/pull/288 to remove the
Cloud
reference from the resources that are not cloud-only)
s
Ah awesome, thanks @Mitch Nielsen. Would you happen to know how to get a create_work_pool function working, like what Nate tried to do? We're still a bit blocked on this and simply pass all our network and security configurations downstream to client flows so they can override manually instead of just having it set up to work out of the box
🙇 1
n
hey @Samuel Hinton - sorry i didn't come back to this sooner, lose track of threads sometimes i fixed that example, I just forgot a tad. there should be a way to set the
prefect.variable.thing
as a default in the template like i mentioned earlier, but the below should help hopefully in the meantime?
s
Oops, now its my turn to not hit enter. This has the same issue as the others, where the flow deployment has to set its job variables explicitly. I was hoping to (in my repo with the terraform where I define the work pool and services) simply set the job template, variables and defaults. Then the downstream flow repo which deploys itself to the ecs worker wouldn't need to have a large section in the deployment where we spell out the job_variables again. Because if we change the template, I don't want to have to commit and change N repos with N deployment files - I want my infrastructure repo to handle the entire job template defaults (apart from things like cpu and memory requirements), with the downstream repos not even knowing about thing slike the vpc id