Azure App Service Deploy finishes successfully, but the files were not updated.
I'm using the pipeline step version 4.*
The WebApp.zip is retrieved successfully from the build and it contains the files, but in a strange subfolder structure: Content\d_C\a\1\s\Platform\Backend\Backend.WebApp (my path starts at 'Platform').
I already tried to use the WebApp release step, but it says it's not compatible with zip files.
This is the log output of the release step:
2019-05-21T13:09:43.6381219Z ##[section]Starting: Azure App Service Deploy: contras
2019-05-21T13:09:43.6498586Z ==============================================================================
2019-05-21T13:09:43.6498697Z Task : Azure App Service Deploy
2019-05-21T13:09:43.6498814Z Description : Update Azure App Services on Windows, Web App on Linux with built-in images or Docker containers, ASP.NET, .NET Core, PHP, Python or Node.js based Web applications, Function Apps on Windows or Linux with Docker Containers, Mobile Apps, API applications, Web Jobs using Web Deploy / Kudu REST APIs
2019-05-21T13:09:43.6498952Z Version : 4.3.24
2019-05-21T13:09:43.6499008Z Author : Microsoft Corporation
2019-05-21T13:09:43.6499078Z Help : [More information](https://aka.ms/azurermwebdeployreadme)
2019-05-21T13:09:43.6499169Z ==============================================================================
2019-05-21T13:09:44.4804024Z Got service connection details for Azure App Service:'contras'
2019-05-21T13:09:44.9625484Z Updating App Service Application settings. Data: {"WEBSITE_RUN_FROM_PACKAGE":"0"}
2019-05-21T13:09:58.0865664Z Updated App Service Application settings and Kudu Application settings.
2019-05-21T13:09:58.4962410Z [command]"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='D:\a\r1\a\_MoonDesk Test\drop\WebApp.zip' -dest:auto,ComputerName='https://contras-staging.scm.azurewebsites.net:443/msdeploy.axd?site=contras',UserName='$contras__staging',Password='***',AuthType='Basic' -setParam:name='IIS Web Application Name',value='contras' -enableRule:AppOffline -retryAttempts:6 -retryInterval:10000 -enableRule:DoNotDeleteRule -userAgent:VSTS_7c1c6e1c-7491-4898-bc4d-a85345921032_Release__16_26_1
2019-05-21T13:09:59.9100098Z Info: Using ID 'fe8253d8-98f3-4403-9e0d-98ceb9f2a406' for connections to the remote server.
2019-05-21T13:10:11.3653059Z Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
2019-05-21T13:10:11.4450004Z Updating App Service Application settings. Data: {"CloudVersion":"1.4.2"}
2019-05-21T13:10:22.5003712Z Updated App Service Application settings and Kudu Application settings.
2019-05-21T13:10:26.5732176Z Successfully updated App Service configuration details
2019-05-21T13:10:33.4106055Z Successfully updated deployment History at https://contras-staging.scm.azurewebsites.net/api/deployments/161558444226571
2019-05-21T13:10:33.4184229Z App Service Application URL: http://contras-staging.azurewebsites.net
2019-05-21T13:10:33.4378162Z ##[section]Finishing: Azure App Service Deploy: contras
Solved it here...The solution/problem lay in the VS solution, which resulted in an invalid zip content.
https://developercommunity.visualstudio.com/content/problem/587989/azure-devops-release-pipeline-azure-app-service-fi.html
Related
I ran into an issue while migrating an Azure app service from .Net Core 5 to 6 while also updating the stack configuration in Azure Portal to use .Net version ".Net 6 (LTS)". The app service only contains continuous webjobs that process service bus messages. Locally, the webjob project runs fine but when deployed to Azure it fails to start. In Kudu tools I'm presented with an error:
[01/03/2023 18:21:32 > 1b0f90: ERR ] Unhandled exception. System.IO.IOException: Failed to bind to address http://127.0.0.1:5000: address already in use.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.
Eventually I am able to get past the error by applying the app setting ASPNETCORE_URLS=http://localhost:5001 to the app service, and applying the same app setting every .Net Core 6 app service running web jobs in the same app service plan except I have to increment the port to something different. This does not seem to be a problem with non-webjob applications, and only occurs when I configure the app service stack to ".Net 6 (LTS)" in Azure Portal.
My question is: Is there another workaround to this issue? I find adding unique port assignments to every webjob running .Net 6 to be a cumbersome and not ideal, and this issue will exist as a serious gotcha for future development.
Here is the dependencies I am pulling in:
Azure.Messaging.ServiceBus Version=7.11.0
Microsoft.Azure.WebJobs Version=3.0.32
Microsoft.ApplicationInsights.AspNetCore Version=2.21.0
Microsoft.ApplicationInsights.NLogTarget Version=2.21.0
Microsoft.Azure.Services.AppAuthentication Version=1.6.2
Microsoft.Azure.WebJobs.Extensions Version=4.0.1
Microsoft.Azure.WebJobs.Extensions.ServiceBus Version=5.3.0
Microsoft.Azure.WebJobs.Extensions.Storage Version=5.0.1
NLog Version=5.0.4
NLog.Targets.Seq Version=2.1.0
NLog.Web.AspNetCore Version=5.1.4
To reproduce:
Create two or more .Net Core 6 applications that only implement Webjobs. My Webjobs functions process Service Bus topic messages, not sure if this is important to reproduce.
Deploy the Webjob applications to the same App Service Plan
In the configuration blade settings tab for each web app make sure that the runtime stack is set to ".Net 6 (LTS)", keep the rest as default.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
The problem seems to be around setting the stack settings version to ".Net 6 (LTS)". From this article it seems that this setting makes the app service Run Kestrel with YARP, I'm guessing the feature parity is not 1:1 with the previous stack.
Example project that can reproduce the issue can be found on Github. Follow README found in .\Scripts to deploy example to Azure.
Note: there seems to be an issue with the template setting the stack to .Net 6. This may need to be done manually post deployment to fully reproduce the issue.
I have created 2 .NET Core 6 Applications and deployed to Azure Web Jobs in same Azure App Service.
Make sure to enable Always On option in App Service => Configuration => General Settings to ensure WebJobs are running Continuously.
I have updated the Stack settings run time Version to .NET 6.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
Yes, even I got stuck with the same issue. The WebJob which I have published 2nd is showing the Pending Restart status.
When I click on the Logs, I can see the below error is Logged.
Make sure that you are setting a connection string named >`AzureWebJobsDashboard` in your Microsoft Azure Website >configuration by using the following format >`DefaultEndpointsProtocol=https;AccountName=**NAME**;Account>Key=**KEY**` pointing to the Microsoft Azure Storage account where >the Microsoft Azure WebJobs Runtime logs are stored.
In the second Console App, I haven't Configured the WebJobs and Storage Account.
Updated the code and published again.
Now I can see both the Jobs are in Running State.
My Program.cs file:
// See https://aka.ms/new-console-template for more information
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
namespace WebJobApp
{
class Program
{
static async Task Main()
{
var builder = new HostBuilder();
builder.UseEnvironment(EnvironmentName.Development);
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
b.AddAzureStorageQueues();
});
builder.ConfigureLogging((context, b) =>
{
b.AddConsole();
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
}
}
Reference taken from MSDoc.
We have the below settings that needs to be done for an app service to install new relic extension:
Ensure the "New Relic Agent" Extensions exist within the App Services Deployment Slot.
The files will be installed in NEW_RELIC_HOME : "C:\home\newrelicAgent". Following the deployment the newly created newrelic.config will need to be replaced with the applicable config for the Application Service.
From the files uploaded, rename {serviceAppName}_newrelic.config to simply "newrelic.config " and replace
"*The newrelic files will load with the worker process and starts profiling post restart of the appservice i.e. with the newly initiated worker process.
ost installation of newrelic extension, we need to replace the newrelic.config file in the below directory.
for dotnet framework applications:
C:\home\NewRelicAgent\Framework>
for dotnetcore applications:
C:\home\NewRelicAgent\Core>*
Unique to each file is the 'Appservicename', also containing the license key information:
NEW_RELIC_LICENSE_KEY : "License key"
NEW_RELIC_APP_NAME: "Appservicename"
Could you please help in updating the pipeline with the settings in an Azure DevOps.
Thanks,
Swabha
When creating a function in Azure through a Linux environment it seems CI/CD is completely missing from it's capabilities as I can't see any actual files. My VS code tells me this
Error: This plan does not support viewing files.
and when I try to deploy my files to the server through the Azure pipeline everything works except for the
Azure App Service Deploy
Which tells me this.
2020-04-21T19:48:37.6676043Z ##[error]Failed to deploy web package to App Service.
2020-04-21T19:48:37.6689536Z ##[error]Error: Error: Failed to deploy web package to App Service. Conflict (CODE: 409)
I did get it working directly through VS Code with a windows environment and didn't notice any of those issues.
Can you confirm this is not possible through Linux or perhaps there is a solution for what I am looking for.
is it possible to do continuous deployment CI/CD of an Azure Function through a Linux Environment via Azure DevOps?
The answer is Yes.
To deploy a Azure Function, you should use Azure Function App task instead of Azure App Service Deploy task. For below example.
steps:
- task: AzureFunctionApp#1
inputs:
azureSubscription: '<Azure service connection>'
appType: functionAppLinux
appName: '<Name of function app>'
#Uncomment the next lines to deploy to a deployment slot
#Note that deployment slots is not supported for Linux Dynamic SKU
#deployToSlotOrASE: true
#resourceGroupName: '<Resource Group Name>'
#slotName: '<Slot name>'
Please check out this document Continuous delivery by using Azure DevOps for detailed examples.
I have created a new Azure DevOps project. Asp.Net core 2.1, Service Fabric deploy.
First deploy went fine. Without any changes subsequent releases are failing
warnings and error
2018-10-10T08:24:17.8368242Z ##[section]Starting: Deploy Service Fabric Application
2018-10-10T08:24:17.8375072Z ==============================================================================
2018-10-10T08:24:17.8375163Z Task : Service Fabric Application Deployment
2018-10-10T08:24:17.8375234Z Description : Deploy a Service Fabric application to a cluster.
2018-10-10T08:24:17.8375288Z Version : 1.7.22
2018-10-10T08:24:17.8375356Z Author : Microsoft Corporation
2018-10-10T08:24:17.8375410Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkId=820528)
2018-10-10T08:24:17.8375479Z ==============================================================================
2018-10-10T08:24:20.0073284Z Searching for path: D:\a\r1\a\**\drop\projectartifacts\**\PublishProfiles\Cloud.xml
2018-10-10T08:24:20.2879096Z Found path: D:\a\r1\a\Drop\drop\projectartifacts\Application\Voting\PublishProfiles\Cloud.xml
2018-10-10T08:24:20.3657104Z Searching for path: D:\a\r1\a\**\drop\applicationpackage
2018-10-10T08:24:20.4618957Z Found path: D:\a\r1\a\Drop\drop\applicationpackage
2018-10-10T08:24:20.7317155Z Imported cluster client certificate with thumbprint '25826D862588CBFA3D2113D882255156F7233F44'.
2018-10-10T08:25:02.0637557Z ##[warning]Failed to contact Naming Service. Attempting to contact Failover Manager Service...
2018-10-10T08:25:42.0730582Z ##[warning]Failed to contact Failover Manager Service, Attempting to contact FMM...
2018-10-10T08:26:22.0962942Z ##[warning]No such host is known
2018-10-10T08:26:22.2408731Z Service fabric SDK version: 3.2.176.9494.
2018-10-10T08:26:22.4279087Z ##[error]No cluster endpoint is reachable, please check if there is connectivity/firewall/DNS issue.
2018-10-10T08:26:22.4687237Z ##[section]Finishing: Deploy Service Fabric Application
All other devops project releases are failing also for same reason.
Any help to debug appreciated
well, this clearly has nothing to do with the release if all the releases are failing. Something happened to your cluster or to your service endpoint
You would need to check if you can connect to the cluster endpoint manually with powershell, for example (connect-servicefabricluster or something along those lines).
misunderstanding of built in release task.
guess cluster was created by DevOps project create and not release task as I thought.
This is a follow-up question to this question. The answer in the original question helped me, but I am stuck somewhere else. As a reminder, I want to deploy my application using a publish profile. My web app in Azure has two subfolders inside wwwroot and one of them is called backend. I want to deploy my application to that folder. I am not sure why msdeploy wants to create anything, since the web app is already there - I just need to get the artifacts inside the backend folder.
Here is the relevant part of the log (with some names changed to xyz):
2018-06-14T09:19:25.0295238Z Start executing msdeploy.exe
2018-06-14T09:19:25.0323018Z "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='D:\a\r1\a\artifacts\drop\xyz.zip' -dest:auto,computerName="https://xyz.scm.azurewebsites.net:443/msdeploy.axd?site=xyz/backend",userName="$xyz",password="***",authtype="basic",includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"D:\a\r1\a\artifacts\drop\xyz.SetParameters.xml"
-enableRule:DoNotDeleteRule -retryAttempts:6 -retryInterval:10000
2018-06-14T09:19:25.6154385Z Info: Using ID '89f1210b-39ba-4758-b7ee-76a06407a503' for connections to the remote server.
2018-06-14T09:19:28.0800802Z Info: Creating application (Default Web Site)
2018-06-14T09:19:28.2012951Z ##[debug]rc:1
2018-06-14T09:19:28.2013216Z ##[debug]rc:1
2018-06-14T09:19:28.2013360Z ##[debug]success:false
2018-06-14T09:19:28.2013523Z ##[debug]success:false
2018-06-14T09:19:28.2073234Z ##[error]Failed to deploy web package to App Service.
2018-06-14T09:19:28.2081930Z ##[debug]Processed: ##vso[task.issue type=error;]Failed to deploy web package to App Service.
2018-06-14T09:19:28.2082198Z ##[debug]{}
2018-06-14T09:19:28.2082470Z ##[debug]System.DefaultWorkingDirectory=D:\a\r1\a
2018-06-14T09:19:28.2083178Z ##[error]Error Code: ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP More Information: Could not
complete an operation with the specified provider ("createApp") when
connecting using the Web Management Service. This can occur if the
server administrator has not authorized the user for this operation.
createApp http://go.microsoft.com/fwlink/?LinkId=178034 Learn more
at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP.
Error count: 1.
I managed to resolve the issue. According to this answer by #starian chen-MSFT, I needed to set the correct parameter in SetParameters.xml. I did this by adding the following to my Visual Studio Build task:
/p:DeployIisAppPath="xyz"
where xyz is the value of DeployIisAppPath element in the publish profile.
The reason is that Azure expecting that site name will be presented twice in scm.azurewebsites.net:443/msdeploy.axd?site=%SiteNameHere%" and the same value as a parameter, by default value from file SetParameters.xml is used for second.
So, you need to modify the value of IIS Web Application Name parameter in xxx.SetParameters.xml programming (e.g. PowerShell or other tasks), after that it should works fine.
Azure staging web deploy fails with ERROR_USER_NOT_AUTHORIZED_FOR_CREATEAPP but not for production