AzureWebAppContainerV1 incorrectly sets 'windowsFxVersion' for linux container

[jbowtie]

Required Information

Type: Bug

Task Name: AzureWebAppContainer

Issue Description

When a Linux Web App with kind: app,linux,container does not have linuxFxVersion set (as can happen with an ARM Template), the AzureWebAppContainer incorrectly sets windowsFxVersion instead. This is difficult to debug as the deployment succeeds but the site does not come up.

However, if linuxFxVersion is set to a placeholder value (such as "DOCKER|alpine") it will correctly be updated. (So there is a workaround).

Explicitly setting a placeholder value is undesirable for many workflows. For example:

• Run an ARM template to ensure the web app exists (this would overwrite the linuxFxVersion to be the placeholder; normally in incremental mode you would not expect the resource to change)
• ...additional steps... (failure here leaves the placeholder running!)
• Run this step to deploy the latest version of a docker image (this would overwrite the linuxFxVersion again)

Since the kind reliably indicates the OS, it seems very odd that the wrong configuration setting is updated.

Task logs

Trying to update App Service Configuration settings. Data: {"appCommandLine":null,"windowsFxVersion":"DOCKER|p***:latest"}
Updated App Service Configuration settings.
Restarting App Service: app-...
App Service 'app-...' restarted successfully.

[AmrutaKawade]

are you sure kind property is set to app,linux,container ?

[jbowtie]

Yes, I can confirm this.

I've done some experimentation - I think the heuristic being followed is "if linuxFxVersion is set, update that, otherwise update windowsFxVersion" - I don't think the isLinux flag is being passed down to whatever common code is actually setting this property.

[AmrutaKawade]

Can you set system.debug=true in variables and run pipeline again? share detail logs

[jbowtie]

I'll have to set up a new pipeline to repro but will make some time to do so.

[KasperPurunen]

I'm having the same issue. We are setting the kind to app,linux,container as well but the logs from Azure DevOps says the following when deploying with the task: {"appCommandLine":null,"windowsFxVersion":"DOCKER| ... " }

[AmrutaKawade]

@KasperPurunen can you share debug logs?

[jbowtie]

Here is the debug log for the deploy azure resources stage: azure-resource-log.txt

Here is the debug log for the AzureWebAppContainer stage: web-container-log.txt

[jbowtie]

@AmrutaKawade Were those logs helpful? Do you need any more detail?

[abdok96]

Any plans to solve this issue soon?

[PhilipsonJoseph]

@jbowtie , @KasperPurunen For us Whenever app is created without linuxFXVersion in ARM template, app kind is set to as app,linux and not app,linux,container Can any one of you confirm this behavior ?,

[PhilipsonJoseph]

Due to inactivity we are closing this. If it is still exists please raise a new bug

[SteveLillis]

@PhilipsonJoseph This issue is still outstanding. As you note above, any ARM template deployed without linuxFxVersion starting DOCKER| strips container from the kind so app,linux,container becomes app,linux. This is easily worked around by not using an exact string match for the OS type lookup, or instead case-insensitively searching "linux" in the kind so that a match occurs when falling back to the supplied kind when the Map misses. I'll raise a PR.

[cfauchere]

How can this issue be swept under the carpet? This is clearly blocking deployment of Linux container.

[nadesu]

• @v-nagarajku

[SteveLillis]

@nadesu @PhilipsonJoseph @v-nagarajku do you know when we might see a review for this one line correction and an update to the task?

I ask as this is currently blocking my team from being able to use this task as intended, and we will need to make alternative plans if we think this may take some time to make it's way out.

Thank you.

[SteveLillis]

For anyone still struggling with this issue, we worked around it by not using the task at all and instead setting linuxFxVersion in the ARM just for the staging slot, while continuing to leave linuxFxVersion unset for the production slot.

This allowed us to get the staging slot set up correctly with the latest image without disrupting the production slot, perform our testing, etc. then swap slots per the usual process to get the desired image into the production slot.

[cfauchere]

I am using Azure CLI az webapp config container set as a workaround

[onionhammer]

I just ran into this naturally, tearing my hair out for hours trying to figure out whats going on

[CMeeg]

I've hit this issue recently also. I have some Bicep templates that I am using to deploy App Service resources (and other things) within a pipeline, and do not want to set linuxFxVersion in the Bicep template because I want that to happen later on in the pipeline via the AzureWebAppContainer task.

If I don't set linuxFxVersion when the App Service is created the AzureWebAppContainer task ends up setting windowsFxVersion i.e. the task output includes: Trying to update App Service Configuration settings. Data: {"appCommandLine":null,"windowsFxVersion":"DOCKER|undefined"}.

As per the issue description, setting a placeholder linuxFxVersion on the App Service does workaround this, but it's not something I want to maintain.

I have also now switched to use az webapp config container set as per this comment, and that's setting linuxFxVersion fine and has unblocked me for now.

In case it's helpful to have an example, I have switched this:

- task: AzureWebAppContainer@1
  displayName: 'Deploy to web app' 
  inputs:
    azureSubscription: '$(ServiceConnection)'
    appName: '$(WebAppName)'
    multicontainerConfigFile: '$(Pipeline.Workspace)/path/to/docker-compose.yml'
    deployToSlotOrASE: true
    resourceGroupName: '$(ResourceGroupName)'
    slotName: '$(WebAppDeploySlotName)' 

To this:

- task: AzureCLI@2
  displayName: 'Deploy to web app'
  inputs:
    azureSubscription: '$(ServiceConnection)'
    scriptType: pscore
    scriptLocation: inlineScript
    inlineScript: |
      az webapp config container set --name "$(WebAppName)" --resource-group "$(ResourceGroupName)" --multicontainer-config-file "$(Pipeline.Workspace)/path/to/docker-compose.yml" --multicontainer-config-type COMPOSE --slot "$(WebAppDeploySlotName)"

[vidarkongsli]

Having had a brief look at the source code for this task, it seems to me that it always looks at the main web site setting when determining whether it is a Linux service, even if you are deploying to a deployment slot: https://github.com/microsoft/azure-pipelines-tasks/blob/7adc2fa8639ba6cf8a18dbe3d0bd93d78c641c9d/Tasks/AzureWebAppContainerV1/taskparameters.ts#L49 This seems to be the reason for this task failing in the my situation.

[ph-ict]

We've also just hit this after spending the afternoon trying to work out why our DevOps deployed image wasn't working. Same issue.

[mortenbock]

I just spent an hour debugging this as well. The kind was set to app,linux and that seemingly caused the image to be written to WindowsFxVersion

I used the Azure CLI to set the LinuxFxVersion, which then updated the kind to app,linux,container, but the deployment task keeps updating the WindowsFxVersion, maybe because that setting is still populated as well?

Is there a way to reset the WindowsFxVersion?

[mortenbock]

Just FYI, I switched to the AzureRmWebAppDeployment@4 task in DevOps, that does it correctly:

- task: AzureRmWebAppDeployment@4
  displayName: Deploy to Azure
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: ${{ parameters.azure_subscription }}
    appType: 'webAppContainer'
    WebAppName: ${{ parameters.app_service_name }}
    DockerNamespace: ${{ parameters.dockerNamespace }}
    DockerRepository: ${{ parameters.dockerRepository }}
    DockerImageTag: ${{ parameters.dockerImageTag }}

[Spencerooni]

Just spent a day trying to understand why my deployed linux container wasn't working. How the container deploy task does not work for linux is super confusing. It wasn't until I did az resource show --ids <resource id> and compared all the attributes of a web app deployed via manually selecting the image vs one I deployed using the pipeline, that I could see the windowsFxVersion being set in the one using this task... @mortenbock your solution worked perfectly for me.

[crow-ua]

This one also caused me some grief lately (situation is complicated by the fact I'm using Terraform for IaC and deploying compose instead of single dockerfile). @CMeeg's workaround worked, but it would be interesting to know proper way to handle this. @PhilipsonJoseph any insights on this?

[ajpogue]

@PhilipsonJoseph Was this resolved? It is still occurring, and we encountered it this week.

[laksharun]

Spent an entire day troubleshooting the issue of why the docker image would not run a Linux web app when deployed through the pipeline. Finally found the difference in the WindowsFxVersion value via https://resources.azure.com when comparing the settings with an app that was deployed manually. It finally worked after using the AzureRmWebAppDeployment@4 task as suggested by @mortenbock.

Has there been any updates on this issue? If not, I believe at least the AzureWebAppContainer@1 document should be updated with this.

[chrisflem]

A colleague of mine found a good workaround for this using bicep templates. First ensure the web app:

resource sites_WebService 'Microsoft.Web/sites@2021-03-01' = {
  name: webServiceName
  location: location
  kind: 'app,linux,container'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    enabled: true
    reserved: true
.......omittet for brevity
  }
  tags: tags
}

Then set the config, where we either use the existing value, or set a placeholder

resource sites_app_invoemailtrackingapi_config 'Microsoft.Web/sites/config@2022-09-01' = {
  parent: sites_WebService
  name: 'web'
  properties: {
    netFrameworkVersion: 'v6.0'
    vnetRouteAllEnabled: true
    acrUseManagedIdentityCreds: true
    alwaysOn: true
    linuxFxVersion: empty(sites_WebService.properties.siteConfig.linuxFxVersion) || sites_WebService.properties.siteConfig.linuxFxVersion == null ? 'DOCKER|alpine' : sites_WebService.properties.siteConfig.linuxFxVersion
    minTlsVersion: '1.2'
  }
}

This will prevent the app from restarting and using the wrong image, since there is no changes. On the first time creation of the web app, the placeholder will be used, ensuring the web app is created correctly

[DohmenICT]

I still have this issue when using AzureRmWebAppDeployment@4.

When I update the Tag of a container which runs as "app,linux,container", the AzureRmWebAppDeployment@4 process updates the "LinuxFxVersion". But when I open the container settings in Azure Portal, it seems that the container runs the "WindowsFxVersion" which isn't updated.

As a workaround, I now also explicitly set the "SiteConfig" Properties when running the AzureRmWebAppDeployment@4. And this works. When updating the tag of a container, it now downloads this correct version when starting the container.

This is my Task now:

            - task: AzureRmWebAppDeployment@4
              displayName: 'Deploy xxx Container ${{ parameters.environmentName }}'
              inputs:
                ConnectionType: 'AzureRM'
                azureSubscription: ${{ parameters.serviceConnectionName }}
                appType: 'webAppContainer'
                WebAppName:  ${{ parameters.appName }} 
                DockerNamespace: ${{ parameters.containerRegistry }}
                DockerRepository: ${{ parameters.imageRepository }}
                DockerImageTag: ${{ parameters.tag }}
                ConfigurationSettings: -linuxFxVersion "DOCKER|${{ parameters.containerRegistry }}/${{ parameters.imageRepository }}:${{ parameters.tag }}" -windowsFxVersion "DOCKER|${{ parameters.containerRegistry }}/${{ parameters.imageRepository }}:${{ parameters.tag }}"

[dariusz-bzowka-chain-insight]

I want to run bicep and inject my docker.compose file: resource appService 'Microsoft.Web/sites@2023-01-01' = { name: WebAppName location: WebAppLocation properties: { serverFarmId: AppSvc.id siteConfig: { linuxFxVersion: 'COMPOSE|how to inject it ???' } } }

[drdamour]

anyone who still cares, maybe if you vote for https://developercommunity.visualstudio.com/t/Make-AzureWebAppContainer-recognize-linu/10771718 we'll get some action

[drdamour]

FYI the AzureRmWebAppDeployment@4 work around has the unfortunate side affect of forcing the DOCKER_CUSTOM_IMAGE_NAME env var to be set on your app service...which if you're using terraform means you'll have to lifecycle ignore it which is crappy.

the workaround i went with was

          # https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-web-app-container-v1            
          - task: AzureWebAppContainer@1
            displayName: Deploy Container
            inputs:
              azureSubscription: $(serviceConnection)
              appName: $(appName)
              imageName: $(acrHost)/$(imageRepository):$(version_lowered)
              # HACK: work around https://github.com/microsoft/azure-pipelines-tasks/issues/14805 :(
              configurationStrings: '-linuxFxVersion DOCKER|$(acrHost)/$(imageRepository):$(version_lowered) -windowsFxVersion null'

this mutates windowsFxVersion to "null" instead of null but it still makes linux container start up correctly and gets the kind to transition from app,linux to app,linux.container

technically that hack is only needed once, but doesn't seem to hurt to do it every time