[Issue] AZD versus BICEP - organize repo into projects with separate provision/deploy

[dfberry]

While I may want to provision and deploy everything all at once, there will also be instances where I want to only provision/deploy a slice of the repo. Deploy has the services in azure.yml to be able to do that but how do I organize and provision by service?

Could I organize bicep into different infra folders or subfolders inside infra?

[vhvb1989]

There's not yet support for composing infrastructure as such @dfberry.

We have a WIP issue for it: https://github.com/Azure/azure-dev/issues/2386, (currently on designing phase).

There are 2 manual alternatives how you can set up your project. Let me share it, in case you want to try it.

1. Conditional-bicep: Add input parameters to your bicep to control when to deploy certain modules. You can use an opt-in or opt-out model, depending on how you want the initial deployment to be. Here's a quick example:

opt-in strategy: " For a main.bicep which deploys modules A, B and C, we want the default deployment to include A and B. Then, if a customer wants to add C, they have to run azd env set INFRA_ENABLE_C true before azd up. A serviceC is defined in azure.yaml, but it is commented, so the customer needs to uncomment so it is deployed."

main.bicep

// Somewhere in the top
@description('opt-in for moduleC - infra')
param deployC bool = false

// Module C - definition
module deployCModule './path/to/module/moduleC.bicep' = if (deployC) {
  name: 'foo'
  scope: rg
  params: {
    moduleCparam1: 'A' 
    moduleCparam2: 'B' 
  }
}

// if setting outputs for moduleC
output MODULE_C_OUTPUT string = deployC ? deployCModule.outputs.foo : ''

main.parameters.json (creates the param input to env var)

  "deployC ": {
      "value": "${INFRA_ENABLE_C}"
    },

Limitations:

• Once infrastructure for C has been deployed, users can't turn flag to false to remove that part of the infra. They need to do a manual delete of resources from C.

For the out-out model, instead of INFRA_ENABLE_C, there would be a variable like INFRA_SKIP_C, just to inverse the logic and disable parts of the infrastructure. However, customers should know they need to remove any service from the azure.yaml file

2. Use hooks. This is a more advance and complicated strategy, so, I won't add a example here :), In summary, you can uset the preprovision hook to replace the /infra folder contents based on ENV VARS.

[jongio]

You can also put the infra in a different folder and then run azd provision and pass -C to that folder. Ping me if you want help setting that up.

[seesharprun]

👀 this thread. I have an OpenAI+ACA+Cosmos template where there are some scenarios where deploying Azure OpenAI doesn't make sense. The opt-out and hook options sound interesting.

[dfberry]

@jongio I've created a repo to test this out and can't get any subdir except the typical subdir working. Can you PR into the repo to show me how to do this?

https://github.com/dfberry/azure-infra-separated.git

[jongio]

The root of the dir you use in -C needs to have azure.yaml file.

azd provision -C sub2-infra-sub-azureyaml works

[dfberry]

@jongio So I don't need any other azure.yml but the one at the root and all deployment services need to be in that root azure.yml?

[dfberry]

@jongio @seesharprun Here is my breakout in my side project. https://github.com/dfberry/cloud-native-todo/pull/21 -

The bicep for the front and back ends stays with front or backend source code. I'm not sure these exactly is what I wanted but I tested it out and it works. Here's how I intend to use it:

1. azd up - every goes at once to start with
2. server code or bicep changes go only for the front or back end and can be deployed separately(generally just the code -- not the provisioning).

Thoughts?

[seesharprun]

I'm admittedly still learning about AZD. Could you azd package <service-name> --output-path <package-name> to package individual services and then azd deploy --from-package <package-name>?

[dfberry]

@seesharprun That would work for SWA, Functions, and App Service where packages are code. I'm not sure how that would work with containers.

[dfberry]

Related issue and its own branch of code

[rajeshkamal5050]

Feature work on this #2650 should also help organize and provision by service.