I'm proposing my company start using Azure Web Apps for our Web App. Others would like to set up Azure Virtual Machines to run the web app, only the web app.
The reason they would like to do that is because of the way they currently handle roll outs. I would like to find documentation on how this is handled with Azure Web Apps.
Currently we have 2 servers that are load balanced. When it's time for a deployment, we bring down one server, updated it, then switch to that server, bringing down the 2nd server to update that.
I'm sure there's a better way to do that using Web Apps. I'm not completely familiar with the server end yet, but am trying to get information.
What we want to avoid is the user getting 30-60 seconds of load time if we publish a change.
Web Apps provide multiple deployment slots, specifically to allow for multiple deployed versions (e.g. production, dev, test).
Also built-in is the ability to swap slots. This allows you to deploy a new build to a testing slot, test it, then swap with the production slot. At that point, your end users start working with the new app version. Your previous version is in the other slot (until you tear it down).
More information on Web App deployment slots here.
Related
We are migrating to Azure. We have a Web App deployed. However, I have a Windows Service that I need to add in to the mix. The service continuously runs, checking the associated Service Bus Queue for messages every 5 seconds.
I am looking for recommendations on how to do this.
I have looked at Web Jobs. But, I don't understand how it gets kicked off. I know there is a Web Hook involved - but I just want the code to run continuously without having to be constantly kicked.
We are also trying to avoid the cost of having a VM involved.
Thanks in advance.
Since you already have a web app, you could use a Azure App Service to run the Web App. The Azure App Service will allow you to also have a Web Job that you can have run on a schedule.
It does not make sense to break you web app into Azure Functions since it is already built. You can have the service run in an Azure Function, but it will probably add more complexity to interact with the web app (if that is what is happening) and if the service is running every 5 seconds, that could get costly.
Our company website will soon be hosted in an App Service in Azure. The website communicates with an API layer that also hosted in Azure and links to our internal systems and databases. The architecture at this level cannot be changed at this time and has quite a bit of background history, etc.
We are looking at implementing always on deployments using Deployment Slots in the App Service in Azure. The API layer will have non-breaking changes for each deployment and deploying the APIs will be the first part of any release, with the website following.
Is have a clear separation between our environments and the release will be tested in Dev, Test and Pre-Prod environments before the production deployment begins. Overall the whole process is fairly simple until it comes to post-implementation (PI) testing that is currently this is mandatory in our company.
We need to be able to test the production deployment prior to the customers using the site. Currently we feature toggle the site into maintenance mode unless its being accessed from a select IP address list. We now need to perform the PI testing on the new version of the site whilst the customer continues to use the older version of the site. I wasn't sure of the best way of achieving this.
One idea I did have is having a subdomain that links directly to the websites _staging deployment slot bypassing the deployment slot settings. In turn some logic in here could go direct to the API _staging deployment slot. This would give the option to post implement the change just prior to clicking the 'Swap' button to swap over the deployment slots.
I know the overall process isn't ideal, but at the moment this can't be changed. Does anyone have any thoughts or other suggestions on the above please?
Azure makes it easy to create deployment slots for App Services. It’s available in the Standard or Premium App Service plan mode. Deployment slots are actually live apps with their own hostnames. App content and configuration elements can be swapped between two deployment slots, including the production slot.
Azure customers can easily perform the following steps
- Deploy the web application to an online deployment slot.
- Run the tests on a deployment slot, within the live environment that potential testers are going to use. Testing environment and production environment exist side-by-side and provide the similar environment.
- Perform an internal swapping of the IP addresses of both slots (via load balancing and traffic management for both the nodes — slots)
- Update applications with zero downtime
- Swap back to a previous version of your app instantly, with zero downtime for users.
References
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
The overall reason to have deployment slots enabled is that it helps your team to run live testing on the production environment, and in case there are some problems on the production slot, it lets you roll back the swap without having to take your application down for maintenance.
When the MVC application is deployed to azure environment, there is slowness in page loading and also response time of web site get delayed for few seconds once the deployment is done.
When the application is deployed in production environment, this slowness make the bad user experience.
Automation test scripts fails due to delay in response of site immediate after deployment
Deployment is done from Visual studio 2013 to Azure Web App services using Visual Studio Publish option settings.
What we have tried:
Deployment is scheduled once in 30 days and also in mid night, however the user in other part of world face issues when deployment happens.
Can some one help me to resolve issue and there should not be any difference to user when deployment happens in production.
There is a slight increase in loading time, for the first request, after an application is deployed to an Azure Web App. What happens behind the scenes is that the underlying web application must pre-compile the MSIL into machine code before it can serve the site. See https://msdn.microsoft.com/en-us/library/ms366723.aspx for more details.
The application pool, used by the Web App, is also regularly recycled in case of in-activity. The same pre-compilation happens then as well. This downtime can be minimized by enabling "Always-On" for the Web App. See https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/ for more details on how to enable it. The always-on feature regularly pings the site to keep it from going inactive.
Also, to minimize downtime, when doing a deployment to a Azure Web App. Have a look at using deployment slots, https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/. Idea here is that you first deploy to the deployment slot (an own web app instead, get it warmed up) and swap it to be the production slot. This way achieving minimal downtime for the Web App. To automatize this process there is a feature called Auto Swap https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#configure-auto-swap-for-your-web-app that does this for you.
Deployment slots are available for standard and premium apps while always-on is available for basic, standard and premium apps.
I have one Node.js web app running on Azure with 2 configured instances. When I publish my changes, the web app is not available until it recycles approximately for 1 minute.
The question is - how to make one instance available with the older source code, while updating the other instance with the new code? And when one instance is successfully updated, do the same thing for the other one.
your best bet would be to use Azure Deployment slots to stage your deployments and then swap to production.
More information can be found here:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Directly from the article
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.
I've a MVC Web Application (.NET) and from time to time I need to upgrade the deployment version on Azure, the problem is that I have customers that are using the Web-App and I cant take it down and make it unavailable.
There is a way to deploy a new version of my Web-App and still be up and running the all time? (during the deployment process)
One way that I could think of it to do it is by deploy the the Web-App to somewhere other than my current deployment and "play" with the DNS record on my external domain.
Use deployment slots.
Azure Web Apps let you create staging slots for your site. They're effectively independent sites that you can deploy your test/staging bits to.
Then when you have the staging site ready you can push a button and make it your public production site.
See here for more details: https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/