I use the Deploy Azure App Service VSTS task to deploy an asp dotnet core API to an Azure API app using the Publish using Web Deploy option. The task runs without any errors but somehow I have to restart the API to get the new version.
Is that intended? Is there any flag that I can set to immediately get the deployment "live"? As a workaround I can add a restart task but I hope there is another way....
Are you using App Service Local Cache? https://learn.microsoft.com/en-us/azure/app-service/app-service-local-cache
If you are you will need to remove WEBSITE_LOCAL_CACHE_OPTION = Always property of your web app to have your publish show right away.
Otherwise you can always use a deployment slot to test your app before swapping in production.
Related
DevOps Pipeline is using VSBuild#1 and PublishBuildArtifacts#1 to create zip artifact.
DevOps Releases is using Azure App Service deploy 4.* and Azure App Service Settings 1.* to deploy app on Azure Service App.
Both processes finish with green status but when I check service it says "Your app is running and wait for content".
Reason is that application is deployed to path: /wwwroot/Content/D_C/a/1/s/src/Project/obj/Release/net6.0/PubTmp/Out/ which is also visible in zip artifact: Content\D_C\a\1\s\src\Project\obj\Release\net6.0\PubTmp\Out.
When I setup start command to use this path it works, but:
I don't like fact I must to set it
If application is not web API but MVC app with own 'wwwroot' I have to move this manually or setup post-deployment script
I spent some time on debugging this issue and I can't believe that default settings don't work for basic scenario and deployment from VS/Rider is working ok!
On which step I have error? Path in ZIP is already wrong? Deployment is not smart enough? App Service is wrongly configured?
From Visual Studio 2019 I publish my ASP.NET Core 2.1 WebAPI to Azure.
The publish fails with this error message.
Web deployment task failed. (Web Deploy cannot modify the file 'xxxx.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
If I manual stop in the App Service in Azure and then publish, the error does not appear.
Problem happens intermittently.
As a common practice, you can a new task on Azure Devops pipeline to stop the WebApp and restart the WebApp when deployment is done.
If you don't have downtime You can configure the Azure Web App to have multiple slots. Slots allow you to safely deploy your app and test it before making it available to your customers.
Also check Blue-Green Deployment with AppService
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
API (Host project, ASP.NET Core Web Application)
Migrator (Console application, capable of migrating the database(s))
UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
Migrate the database using the Migrator package
Deploy the API application package
Deploy the UI application package
Put the API application online, maybe some more tests to check that it's working correctly
Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
Put an Azure App Service offline/online (using an app_offline.htm file)
Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
I have setup continuous deployment of a standard web api project to an API App on Azure. The new version is deployed to the staging slot and then swapped with production at the end of the release task. I can see that (by going to App Service Editor in azure portal) the dll file versions reflect the latest changes. But when I access the APIs (from a webapp or postman) on this Azure app the result does not reflect the published changes. The only way I can force the new changes is either restarting the API app or stopping and starting the app service.
Am I missing anything in using continuous integration with API app on Azure?
I have solved this by adding a new task available in VSO release which restarts the staging slot before swapping with production. This makes sure that the new changes are part of the IIS process.
How to deploy azure webjob using Octopus deployment?
For me, octopus says it is deployed to azure but not able to see my webjob under the website.
Can anyone help how to achieve this?
There is a documentation on how to deploy a web job from octopus Azure Web Apps.
I was using Octopus Deploy 3.0 and in my case, I only wanted to deploy a webjob without a web app:
I've chosen Azure Web App Deployment Target:
And in the deployment section, specify the physical path.
For continuous job you can specify a path like that:
For triggered job you can specify a path like that:
have you try to publish your web jobs to your website using Visual Studio?
One way to verify whether your web jobs has been deployed to your website/web app is to access to the Kudu site of your website.
https://.scm.azurewebsites.net/azurejobs/#/jobs
Go to Debug Console (CMD), try to access D:\home\site\wwwroot\App_Data\jobs
and see if there is any web jobs underneath it
You can try using the nuspec to package your artifacts.
Put you web jobs under App_Data\jobs\trigger{webjob} or App_Data\jobs\continuous{webjob} based on your job type.
And then deploy using Octopus, Azure will be able to recognize it.
This might help:
http://blog.amitapple.com/post/74215124623/deploy-azure-webjobs/#.VVRSANNViko
Good luck