0
votes

I'm trying to upload a Dotnet core Azure Function to an app service hosted on Windows and I'm struggling to prove that it works or ensure the settings are correct.

I also have the aspiration that the deployment should be fully automated without having to go via the Azure Portal and tweak settings etc.

Build process: currently it looks like this...

  1. The c# function compiles and all unit tests pass locally and on the Azure DevOps build agents
  2. Build completes and generates the zip file
  3. I wrap the zip file within a versioned Nuget package
  4. Nuget package is hosted in Azure DevOps Artifacts repo

So all looks good at this point.

Release Process

  1. I restore and unpack the nuget package on the Azure DevOps build agent.
  2. I confirm the zip file exists with a Powershell task - all good.
  3. I then use the Azure DevOps Release pipeline task; "Azure Functions"
  4. I think I've configured this task correctly
    • Package or Folder: "The path I validated in step 2 above"
    • Deployment Method: Zip Deploy (I've alternated between this and Package deployment in different releases)

App Settings (see screenshot below)

  • name value pairs like -Name "value" -Name2 "value2" etc
  • I've also included -WEBSITE_RUN_FROM_PACKAGE "1" in the list of app settings (I've tried releases with and without this setting present)

The Results

The release passes, it says in the logs that its uploaded the package and the app settings.

However, when I go to the Azure Portal:

  • I don't see my app settings that I thought I'd uploaded in the release.
  • It retains dummy app settings that I added via the Azure Portal directly

Questions

  • Should I create an empty Azure Function within the AppServive using the Azure Portal before I start the Release with this task?
    • The very first time I ran the release it failed because it said it couldn't find the slot I'd specified. I was under the impression that the Azure Function pipeline task would create everything but it appears that it expects there to be an empty function with slots predefined and maybe app settings predefined. Any thoughts please?
    • Do I have to create app settings in the Portal before the release? In other words does the Pipeline task only allow updates to existing Portal created app settings.
  • Is there a better Pipeline task to use - that can create an new Azure Function if it doesn't exist already?

As is often the case with help documentation, the info I've seen follows a happy path, or sometimes too much with lots of ifs, buts and maybe advice.

Any guidance would be truly appreciated as I feel I'm going round in circles here and it should be simple.

Thankyou.

enter image description here

2

2 Answers

0
votes

You can deploy the Azure Function via Azure-Resource-Manager Templates. You can find samples on GitHub. With this step you create the required infrastructure on Azure before your deployment. In your case the Azure Function and a Consumption Plan. In your deployment, the infrastructure is therefore provided in step one and then the actual deployment of the package to your function.

For the infrastructure look at the Azure DevOps Step for Create or Update Resource Groups.

YAML sample for both steps:

- task: AzureResourceGroupDeployment@2
  displayName: 'Create Or Update Resource Group'
  inputs:
    deploymentMode: 'Incremental'
    azureSubscription: 'Your-Subscription'
    resourceGroupName: '${{ parameters.resourceGroupName }}'
    location: '${{ parameters.location }}'
    csmFile: '${{ parameters.csmFile }}'
    csmParametersFile: '${{ parameters.csmParametersFile }}'

- task: AzureRmWebAppDeployment@4
  displayName: 'Azure App Service Deploy'
  inputs:
    azureSubscription: 'Your-Subscription'
    appType: functionApp
    WebAppName: '${{ parameters.function }}'
    packageForLinux: '$(Agent.BuildDirectory)/${{ parameters.dropfolder }}/$(Build.Repository.Name)-$(version)-$(Build.SourceBranchName)-$(Build.BuildNumber).zip'
0
votes

After you've done a build in your Azure Devops pipeline you will create a package to make a release from. You have to make sure that the contents in that package matches to correct folder structure. The contents of your app should have the following structure according to Requirements for continuous deployment.

FunctionApp
 | - host.json
 | - MyFirstFunction
 | | - function.json
 | | - ...  
 | - MySecondFunction
 | | - function.json
 | | - ...  
 | - SharedCode
 | - bin

After the build you can check the contents of the generated package by going to the summary for that particular build and clicking on the published artifact. There you can download the contents and make sure that it has the following structure and content:

 | - host.json
 | - MyFirstFunction
 | | - function.json
 | | - ...  
 | - MySecondFunction
 | | - function.json
 | | - ...  
 | - SharedCode (might not be there)
 | - bin

Once deployed you can browser your deployed files through Kudu by using the CMD or Powershell Debug Console. If you have chosen to run from package you can see the package used at /data/SitePackages/. The packagename.txt points to the latest package used. The contents of the package are extracted to /site/wwwroot/. There you should see at least a host.json, a bin folder, and the folders containing your functions. Nothing else. The function app content should not be deployed to a sub folder of /site/wwwroot/, like for example /site/wwwroot/FunctionApp/.

If the content and folder structure in wwwroot isn't correct, you might still see a successful deployment, you Function App shows up but there are no functions showing up.