I am new to Azure Cloud and started working on App services. I created an app service through ARM templates from Azure Devops. Once done, I get the default page which is expected
Now, I deploy a sample react application to the App service and I see the application. However, when I re-run the ARM template, it takes me back to the default page. I am unable to understand why a re-run of ARM takes me back to the default page instead of my react app.
What can I do to have my react app up even after ARM template re-run? Is there any point I am missing?
I deleted my previous app service and re-did everything. Now, my application stays as is even after re-deploying the ARM template. Not sure what went wrong, the first time
Related
I have an IHostedService app in dotnet core 3.1, which is deployed on azure app service plan, but it needs to browse the app service to activate IHostedService.
I have automatic deploy pipeline , when it deploy the IHostedService app,it stopped working and I have to start manually by clicking browse button.
Anyone know how to activate IHostedService after deployment?
One of my colleague who is devops expert find the solution for me.
App service -> configuration -> general settings -> Always On [on]
The Always On feature keeps your Azure web applications up and running,
VSCode sees my Blazor server app as an Azure Function. Right-clicking on my publish folder I only have the option to Deploy to Function App, instead of Deploy to Web App which logically shows me only my function apps from azure. How is this determined by VSCode? I have checked the project file, but I do not see anything obvious wrong.
I tried Googling this, but the search terms only brings me to tutorials where this problem does not exist.
I was missing the Azure Web App extension. Once that was installed, the option appeared
If we are deploying a basic WebApp / WebApi, both these tasks from Microsoft appear to do the same thing - deploy to an appservice.
AzureWebAppV1
AzureRmWebAppDeploymentV4
How do you choose which one to use in a new YAML release pipeline? I just want to make sure I am using the version that is most future-proof - I have 25 release pipelines and don't want to have to re-do them unless necessary.
The way the help is written, hard to compare feature to feature to spot the key "must-haves". Some Microsoft online examples use both. Both are still marked as "In Development" in the readme and both are >1 year old since last check in.
The simplest way to deploy to an Azure Web App is to use the Azure Web App Deploy (AzureWebApp) task.
By default, your deployment happens to the root application in the Azure Web App. You can deploy to a specific virtual application by using the VirtualApplication property of the AzureRmWebAppDeployment task.
Azure App Service Deploy task allows users to modify configuration settings in configuration files (*.config files) inside web packages and XML parameters files (parameters.xml), based on the stage name specified.
Just my two cents, but I just noticed Web App Deploy takes much less time than Service App Deploy. I was wondering how come a simple zip deploy (Service App Deploy) can take so long. So I looked around and found there's also that Web App Deploy, so I tested it.
My project (React/Next small sized app) normally takes 6-10 min to deploy with Azure Service App Deploy (v4). With Azure Web App Deploy (v1) it took a little more than a minute. Wow.
I have an ASP.NET Core app and trying to automate deployment to a Linux-based Azure App Service through the on-premises Azure DevOps server. I managed to build everything and deploy the code to the App Service.
At this moment, the Startup Command which should run the application (dotnet dllname) fails. When I open the URL of my web app, I see the default Azure "welcome" page (served from opt/defaultsite).
I don't have a problem with this particular failure - I did not configure the connection string and other settings yet, so it was expected. However, I wonder how it is supposed to handle such failures. I have these concerns:
How do I know that the startup failed without visiting the web app manually? The Deploy task finishes successfully with a green mark despite the fact that the startup was not successful.
When the app fails to start, I would like to see the error message in the browser rather than the default site (at least for the non-prod environments). Otherwise, the only way to understand that I have a problem and see the reason is to go to the Kudu console and see the log stream.
If my app crashes, would it restart it or it will switch to the opt/defaultsite page again?
At this moment, to address the first concern, I am going to add another task to the Stage - a simple PowerShell script which would send a request to one of the app endpoints, however, I wonder if Microsoft suggests some better/more native solution.
Basically, the stage will be failed if there are errors/exceptions during the deployment.
However we cannot fail an Azure Release Pipeline stage if startup command is not successful, because the deployment is actually complete.
As a workaround you can add another task to run scripts to request the endpoints to detect that as you did.
I am currently provisioning a new resource group using Azure Arm template and Powershell
New-AzureRmResourceGroupDeployment
The resource group template defines all the resources.
A couple of different app service resources are provisioned as part of this resource group. Each app service resource has app settings.
The resource group gets provisioned sucessfully including its app service but from time to time, the app settings are missing on the newly provisioned app service. I am required to teardown and re-create the resource group and it works fine.
When the custom app settings are missing then, in the portal, there is only one app setting visible: WEBSITE_NODE_DEFAULT_VERSION
Any pointers for how I can troubleshoot this so the environment provisioning process is consistent?
Are you using the -DeploymentDebugLogLevel parameter in the PowerShell command you are using for the deployment? There are different values for that parameter that control how much debugging information you get. I have used it in the past to help troubleshoot IaaS deployments using ARM templates. More information is here: https://azure.microsoft.com/en-us/blog/debugging-arm-template-deployments/
Does the app have slots? If yes, are the appsettings tied to specific slots? When we perform a swap slot, then the appsettings can disappear, if the settings are slot specific. Also, are you performing an Incremental upgrade or Complete? As Tom commented, sharing the template will help in understanding whats going on.