Open christothes opened 2 years ago
Can you talk more about what you are looking to do? The entry point is currently fixed at /infra/main.bicep when you run azd provision.
I was trying to create 2 separate entry points which could be invoked via a script. The purpose of the script was to perform some steps in between the 2 entry points which cannot be accomplished in bicep.
We should allow configuring the bicep file that azd provision
uses. I think we should put something in the azure.yaml
file that looks like this:
infra:
module: main
Which, when using the bicep IaC provider would mean use infra\main.bicep
(perhaps module should be a partial path instead?)
But I think what @christothes want is something kind of different - today we have a fairly tight correspondence between "an application has a single IaC file (which may have includes) (that's a reason why azd provision
doesn't take an argument). I know @wbreza has been thinking about what it would mean for services to include their own IaC files and what provision
might mean in that world and it would be interesting to see if that level of power would give @christothes the tools he needs to solve his problem.
@christothes - What's forcing you to have two separate entry points? I assume this is something related to provision AAD principles or something else that you can use later, based on my vague memories from when we chatted last. Could you explain the sequencing here?
Chris and I talked a little more about this "in person". The crux of the issue is that he's trying to use AAD to provide authentication for a web site and do to that he has to provision some resources (a key-vault vault, a Service Principal and then an App Registration" and some of these cannot be created via an ARM Deployment. So, he has a script today that does a bunch of az
cli calls to create these resources and then calls azd provision
to deploy the rest of the infrastructure and his webapp.
A few interesting takeaways from our discussion:
infra/main.bicep
) per environment.It's interesting to note that I think using either Pulumi or Terraform he would be able to accomplish his goals, since he could introduce arbitrary computation during the infrastructure deployment and that would run in his context.
One thing to note is that Chris isn't trying to do complicated AAD stuff here - he just wants to be able to use it to provide Authentication to website - it feels like very "day 0" level work and the result is quite complicated. It would be great if azd
had a better understanding of this and provided a declarative way of specifying at least some common gestures.
I actually see multiple issues here:
Seems to be an issue for some time and the suggested route is to have deployment scripts and PS commands. References of similar previous issues.
Bicep backlog item already exists for fixing the same
Output from
azd version
Runazd version
and copy and paste the output here:azd version 0.1.0-beta.4 (commit fd96b3e9b283598bc4dc736e893f1b47080fbf7d)
Output from
az version
Runaz version
and copy and paste the output here (minimum required version is 2.38.0):Describe the bug running
azd provision <some path to a .bicpe file>
ignores the path and just executes main.bicepTo Reproduce Steps to reproduce the behavior... create a different bicep file than main.bicep run
azd provision <some path to a .bicpe file>
Expected behavior the specified bicep file is deployed
Environment Information on your environment:
Additional context Add any other context about the problem here.