Open jbowtie opened 3 years ago
are you sure kind property is set to app,linux,container
?
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.
Can you set system.debug=true
in variables and run pipeline again?
share detail logs
I'll have to set up a new pipeline to repro but will make some time to do so.
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| ... " }
@KasperPurunen can you share debug logs?
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
@AmrutaKawade Were those logs helpful? Do you need any more detail?
Any plans to solve this issue soon?
@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 ?,
Due to inactivity we are closing this. If it is still exists please raise a new bug
@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.
How can this issue be swept under the carpet? This is clearly blocking deployment of Linux container.
@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.
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.
I am using Azure CLI az webapp config container set
as a workaround
I just ran into this naturally, tearing my hair out for hours trying to figure out whats going on
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)"
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.
We've also just hit this after spending the afternoon trying to work out why our DevOps deployed image wasn't working. Same issue.
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
?
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 }}
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.
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?
@PhilipsonJoseph Was this resolved? It is still occurring, and we encountered it this week.
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.
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
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 }}"
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 ???' } } }
anyone who still cares, maybe if you vote for https://developercommunity.visualstudio.com/t/Make-AzureWebAppContainer-recognize-linu/10771718 we'll get some action
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
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:
Since the kind reliably indicates the OS, it seems very odd that the wrong configuration setting is updated.
Task logs