How to prevent reversion of changes known to be applied elsewhere?

[cemerick]

I have a template that describes a set of Container App instances and surrounding infrastructure. It works great to initially provision it all, and it's a great way to incrementally evolve that infra.

However, there are some places where I wish I could annotate a particular property as being only relevant when initially creating a resource. For example, the name of a container app's container image: it's strictly necessary to create the resource, but it's known and expected that that property will be changed outside of bicep deployments (whether via the portal, or far more commonly via CI/CD processes that only ever bump the deployed container image, and don't touch anything else).

As it stands, I need to be sure the container image parameter going into the deployment process matches what is currently deployed, or obviously, bad things will happen. This is to say nothing of possible race conditions between a bicep deployment and a CI/CD-originated container image bump, or some future where we'll have multiple versions of container images in different app replicas, etc.

Is there a way to make bicep deployments ignore certain resource properties that are known to be regularly modified otherwise?

[brwilkinson]

Hi @cemerick

On some resource types some properties are optional and it is possible setup conditions on these OR on the whole resources.

If you do use a condition you can maintain state such as a flag to say to skip the deployment all together.

However in the case of containerApps the image is a required property. So you can only skip deploying the resource all together.

Would it be possible to integrate your same template into your Deployment pipeline? That way you pass in the image name as a parameter which comes from a Build variable?

It's hard if you have 2 separate pipelines, So perhaps just build the Container App Environment in your main templates, then deploy the Apps in the App Pipeline?

In theory it is possible to use and existing Resource to read the current setting, then use that to apply over the top of your new deployment. The first time you deploy you need to set a flag to provide a starter value, then onwards from them, it uses the results of the GET to be used on the PUT ...

I will setup a sample for you, then post back....

in the meantime here is a sample of the same from App Service.

• https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/AppServiceWebSite.bicep#L165

appConfigCurrent: contains(ws, 'initialDeploy') && bool(ws.initialDeploy) ? {} : appsettingsCurrent[index].list().properties

You have to use a nested Module to make it work... you have a default value and use that if initialDeploy: 1 then you pass in the output from the existing and use that if intialDeploy: 0. So you do need to toggle that or deploy twice in the beginning to get it up and running.

• you could just do the same for your image name and image ... on the containerApps template.

      containers: [
        {
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          name: 'simple-hello-world-container'

I think it's just a though experiment and perhaps not the way to run in production. Anyway I will test it out.

[brwilkinson]

@cemerick
Here is a sample to merge config.

• https://github.com/brwilkinson/Bicep_Merge_Proto

[brwilkinson]

@cemerick other than this, I don't believe we have my alternative other than to lock down access with RBAC roles. Allow reader, then enforce change via pipelines.

[thisispaulsmith]

@cemerick how did you end up solving this?

It seems using the bicep as part of the app CD using an image param is the only option.

Typically we'd configure infrastructure in a dedicated pipeline but as it stands any infrastructure update would revert the image to the incorrect version. If say for example it had been updated as part of a dedicated app pipeline.

[arealmaas]

Did you arrive on any good workflows here @thisispaulsmith @cemerick ? Struggle really hard to create a good deployment pipeline that doesn't go through an entire Bicep-deployment where rest of infrastructure and dependent resources are created.

I would imagine splitting the provisioning part and the updates of the app "manifest/template" would be ideal in my case at least.

So as a potential workaround now I might be able to set a variable "initialProvisioning" to only create the container app in the case where we are initially provisioning resources using the if expression on the resource: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/conditional-resource-deployment#new-or-existing-resource

param initialProvisioning bool

var containerAppName = 'some-container-app-name'
resource containerApp 'Microsoft.App/containerApps@2023-05-01' = if (initialProvisioning) {
  name: containerAppName
  location: location
  .... 

And rather use a yaml to specify the template:

app.yml

properties:
  configuration:
  ....
  template:
    containers:
    - image: 'someimage'
      name: container-app
      probes:
      - type: Liveness
        httpGet:
          path: "/healthz"
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3
    scale:
      minReplicas: 2
      maxReplicas: 5

This way I can:

• Easily edit a yaml template to trigger a new deploy with new configurations which would be super fast when using az containerapp update ... --yaml app.yml.
• When a new image is built, replace the image tag and trigger new deploy using az containerapp update ... --yaml app.yml
• Change traffic weight and other things like rollback revision after running tests etc without going through a Bicep deployment
• Leave the provisioning of the Container Apps and all other dependent resources in a separate pipeline/flow/trigger

This feels like a hacky'ish solution though... Would appreciate some input on achieving a similar workflow! @brwilkinson

[thisispaulsmith]

@arealmaas we're still working on this. However, what we have so far is a core pipeline for configuring core infrastructure. This include the Container App Environment and other static type assets. We then have a Container App module and an instance of that module per container app. This works very much like having a Helm chart per app, we simply just have a bicep file per app with most of the shared logic in the module.

As part of our pipeline we just simply pass the correct tag and the bicep makes any updates to the app.

Does that make sense?

[arealmaas]

Yes makes sense. It seems like this is the direction we are heading to as well. Hard to get a good workflow any other way. Would be curious to know if someone has done anything else.

Thanks for the quick answer and the good description @thisispaulsmith !

[trylvis]

I have also been leaning against such a approach.

I do on the other hand like the thought of just having this .yml file with all the settings, without needing to manage all that through parameters into a bicep file.

Do you use a central Container App module? How do you handle environment variables and secrets in the workflow?

[arealmaas]

Yes we reuse a container app module. Environment variables just hardcoded in the bicep-file for now. Secrets are fetched from keyvault on deployment and passed via bicepparam. The repo is open source and available here: https://github.com/digdir/dialogporten

The process is still a work in progress, but now we have come to a point where we have separated the two pipelines and using https://github.com/google-github-actions/release-please-action to version the application and generate changelogs.

Still, I don't feel like this is as good a workflow that we could achieve with Kubernetes/ArgoCD, but it works.. We will be iterating on this and hopefully we'll land on an even better solution eventually.