I build and deployed a Vue/nuxt web app to Azure Web App by configuring Azure DevOps build and release pipelines.
The app runs on top of node and Express configuration. I start the app on the server by typing: npm run start on Kudu's CMD. Then the start script is set in the package.json file to launch the command: node server/index.js.
On the other hand, the build pipeline is configured to trigger a new build of the app (npm run build) when a new commit occurs and then the release pipeline catches the output and deploys it to Azure by Zip Deploy mechanism ("Azure App Service deploy" task).
So far I found not in the need to restart neither the Azure Web App nor the node process to update the app. In some ocassion I did found some strange error behaviour I solved by killing the process and restarting all over again.
In an official and proper way manner should I do this every time a new build is released? And how can I do it? I can gues on how to restart node via post deployment actions but what about killing the process? I must kill otherwise the new process port number will collide with the running one.
As I know there exists some circumstances under which an application deployment might result in a restart.
See Deployment vs. runtime issues, App Service deploys files to the wwwroot folder. It never directly restarts your app.
So i think it's necessary when your changes in code do not start to work in your application, but if it works well when sometimes the restart occurs, you don't need to do the restart manually. Also, if you want to restart the app service, you can try Azure App Service Manage Task or restart it in Azure web portal.
Related
I have azure devops publishing a dotnet core web app to an AWS server, but the app serilog logs are not kicking in because even though the DLLS etc are updated the myapp.dll is not re-started, so the logging setup code in program.cs is not executed.
If I run the app in powershell using "dotnet myapp.dll" then the logging file appears but that starts a seperate process on a different port... so it doesnt help.
The app runs under IIS on the server and Im not sure if this is a devops issue or something i need to do in IIS..
I added this as the last step to the pipeline but I get an error
You misspelled a built-in dotnet command.
You intended to execute a .NET Core program, but dotnet-.\myWork.dll does not exist.
You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
The pipeline doesn't start your application. Even if it worked, you would have an app running on the Agent that's executing the pipeline, not on your server.
If you want the app hosted on your server, I'd start with Publish an ASP.NET Core app to IIS tutorial.
Get it deployed on your server manually and ensure it's running correctly. But don't do right-click publish - use commandline all the way.
Once you know what are the necessary steps (and what might go wrong), you can start automating it.
I have an Azure Web App (WebAppLinux) running an Angular application. The deployment is based on the Azure WebApp#1 task in an Azure pipeline.
Everything was fine until today. Without anyone having done a deployment, the website only shows an index page with the files stored in the home directory.
A re-deployment through the CI/CD pipeline is still successful. However, the error remains.
Was there any change to the Azure App Service that made my application incompatible?
The answer of LuisDev99 in https://stackoverflow.com/a/61707805/3809334 has solved the problem.
We had to add
pm2 serve /home/site/wwwroot --no-daemon --spa
to the Startup Command under Configuration, select the tab -> General Settings
In the past we had a startup script that called npx serve -s within our Angular application.
It seems that this way did not work anymore over the weekend. Maybe because there was a configuration change in the WebApp by Microsoft
Not an answer, but if you file an issue in https://github.com/Azure-App-Service/Linux/issues, that will help proceed with the next steps for investigation.
I'm trying Azure App Services. I've set up a build pipeline in Azure DevOps which builds and pushes my image to Docker Hub and then publishes docker-compose.yml as an artifact.
My release pipeline takes the docker-compose.yml and feeds it to the "Azure Web App for Container" task which succeeds. But the bot goes down and doesn't get back up after the deployment unless I access http://<myappname>.azurewebsites.net, then it starts and is of the latest pushed version. So everything seems to work, except the "restart" or docker-compose up.
I've been reading that I want to add a WebJob to my app service, but since I am using a Linux host I cannot seem to configure this. I've tried adding a curl task after deployment, but this probably executes too early.
Any ideas on how I would get to solve this last piece of the puzzle to have a simple CI/CD environment?
Currently there is zero out of the box support for hosting WebJobs in a Linux hosted app service. I've heard there's a hacky way of doing it (I'll have to find the post) but since it's not supported out of the gate, there's no guarantee it'll work.
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.
I'm trying to use webpack with my (fairly large) NodeJS app, deploying as a Windows Azure App Service using Git continuous deployment.
I customized my kudu deploy.sh script to run webpack, but it takes several minutes to webpack on Azure App Service, and the app is unavailable during that time. On my dev laptop, running webpack only takes about 30s (which I could accept as a deployment outage time), but I'm guessing the laptop using an SSD is making this run much faster?
If I was using a deploy script, I'd just run the webpack on my dev machine and push the results to the server, but I'm using git for continuous deployment, and I don't want to commit constantly-changing webpack-generated code to the Git repo.
Is there any way to run webpack-on-deploy with Azure App Service-base NodeJS apps without such a large outage time while deploying?
Instead of reducing deployment outage time try leveraging deployment slot to prevent the app unavailable during that time.
Per Azure's documentation,
Deploying a web app to a slot first and swapping it into production
ensures that all instances of the slot are warmed up before being
swapped into production. This eliminates downtime when you deploy your
web app. The traffic redirection is seamless, and no requests are
dropped as a result of swap operations. This entire workflow can be
automated by configuring Auto Swap when pre-swap validation is not
needed.
How to add a deployment slot to a web app, please refer https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing for details.