Zero Downtime Upgrade for an application in Microsoft Azure. Part 1: PaaS
The life cycle of any application implies its support. These can be any patches, hot fixes, new versions, etc. In the case of the desktop application, everything is quite clear and familiar. However, let's see how the update mechanism of your application happens if it is hosted in the cloud. In our case, we will be talking about the Microsoft Azure cloud.
So, Microsoft Azure provides enough broad tools to automatically update your application, and usually the application is currently used by other people, so the most important issue is the update "on the fly", that is, invisible to the user. Let's look at all the possible ways that it is possible to apply for a Microsoft Azure application.
This update mechanism is more applicable only in the testing and development process. As we know, Microsoft Azure supports two application deployment mechanisms: PaaS and IaaS. The Web Deploy option runs within PaaS. In general terms, the mechanism for publishing an application from Visual Studio is as follows:
Suppose the guys from the development team are now actively introducing new features, some of which can already be tested by testers. The full deployment process takes a lot of time, so due to some minor changes it is expensive to start it every time. In this case, you can use the mechanism WebDeploy. The scheme is presented below:
')
The mechanism works as follows. Suppose that we already have a virtual machine that is running version 1.0 of our application. We need to update it to 1.0.1, in which fairly small changes have been made, so the delta changes (archive size) is small. Web Deploy in this case collects the project (of course), archives only the changed files, uploads the archive with the changes to Azure Storage. After that, using the RDP protocol (a mandatory requirement for the virtual machine), the archive with the changes is copied to the running virtual machine. The archive is unpacked and the changed files are replaced in the IIS directory. Then IIS restarts.
Let's now look at the pros and cons of this approach.
Pros:
Minuses:
As we can see, this method can hardly be regarded as production, but it also has its advantages, therefore it has the right to life.
We continue to consider options for updating the application as part of a PaaS deployment. Unlike the previous version, the following approach is quite applicable and is used in the production environment.
Suppose that our customer uses our application version 1.0 at (contoso.cloudapp.net). Our task is to update the application version to 1.1 imperceptibly for the user.
Microsoft Azure offers a convenient concept of slots in cloud services. When we publish our application to the cloud through Visual Studio, we are always asked in which slot we want to publish our application: Staging or Production.
Accordingly, the only difference between these slots is that the production slot has a DNS associated with a specific name (in our test, test-app-1.cloudapp.net), and Staging has a name like GUID.cloudapp.net. Thus, you can simultaneously hold multiple versions of the same application in the same cloud service. As I mentioned above, the customer uses the production slot, and we can use Staging, for example, to conduct tests or prepare the environment for release.
When creating a cloud service, Azure Internal Load Balancer creates a table of IP addresses associated with a specific DNS name. The idea of ​​VIP Swap is very simple - it is the replacement of the IP addresses of the machines associated with the Staging slot with the IP addresses of the machines attached to the Production slot. The update operation of the internal table of IP addresses of the load balancer Azure takes a matter of seconds. Thus, from the user's point of view, updating the application to the new version happens instantly.
Let's now look at the pros and cons of this approach.
Pros:
Minuses:
Analysis of this update method shows that it is quite suitable for use in the production environment. When using PaaS approach to deploying an application, it is one of the most optimal.
Today, this is all that I wanted to tell you. Next time we will see what tools Microsoft Azure can use to update the application deployed as part of IaaS. Do not switch!
So, Microsoft Azure provides enough broad tools to automatically update your application, and usually the application is currently used by other people, so the most important issue is the update "on the fly", that is, invisible to the user. Let's look at all the possible ways that it is possible to apply for a Microsoft Azure application.
Web deploy
This update mechanism is more applicable only in the testing and development process. As we know, Microsoft Azure supports two application deployment mechanisms: PaaS and IaaS. The Web Deploy option runs within PaaS. In general terms, the mechanism for publishing an application from Visual Studio is as follows:
- Build the application with all dependencies
- Archiving
- Download to Azure Storage
- Deploy a virtual machine from an image
- Copy archive from Azure Storage to virtual machine disk
- Archive unpacking
- IIS Setup
Suppose the guys from the development team are now actively introducing new features, some of which can already be tested by testers. The full deployment process takes a lot of time, so due to some minor changes it is expensive to start it every time. In this case, you can use the mechanism WebDeploy. The scheme is presented below:
')
The mechanism works as follows. Suppose that we already have a virtual machine that is running version 1.0 of our application. We need to update it to 1.0.1, in which fairly small changes have been made, so the delta changes (archive size) is small. Web Deploy in this case collects the project (of course), archives only the changed files, uploads the archive with the changes to Azure Storage. After that, using the RDP protocol (a mandatory requirement for the virtual machine), the archive with the changes is copied to the running virtual machine. The archive is unpacked and the changed files are replaced in the IIS directory. Then IIS restarts.
Let's now look at the pros and cons of this approach.
Pros:
- Reduces the time to deploy a new version of the application
- Small size changes
- Publish directly from Visual Studio
Minuses:
- If the machine is recreated (recycling), then the changes made during the Web Deploy process will not get into the original archive (package, .cspkg)
- Only web roles (Web Roles) are supported. Worker Roles are not supported.
- RDP connection with the virtual machine - a prerequisite
- Only one virtual machine is supported within one cloud service (Cloud Service)
- The method is applicable only within PaaS deployment
As we can see, this method can hardly be regarded as production, but it also has its advantages, therefore it has the right to life.
VIP Swap
We continue to consider options for updating the application as part of a PaaS deployment. Unlike the previous version, the following approach is quite applicable and is used in the production environment.
Suppose that our customer uses our application version 1.0 at (contoso.cloudapp.net). Our task is to update the application version to 1.1 imperceptibly for the user.
Microsoft Azure offers a convenient concept of slots in cloud services. When we publish our application to the cloud through Visual Studio, we are always asked in which slot we want to publish our application: Staging or Production.
Accordingly, the only difference between these slots is that the production slot has a DNS associated with a specific name (in our test, test-app-1.cloudapp.net), and Staging has a name like GUID.cloudapp.net. Thus, you can simultaneously hold multiple versions of the same application in the same cloud service. As I mentioned above, the customer uses the production slot, and we can use Staging, for example, to conduct tests or prepare the environment for release.
When creating a cloud service, Azure Internal Load Balancer creates a table of IP addresses associated with a specific DNS name. The idea of ​​VIP Swap is very simple - it is the replacement of the IP addresses of the machines associated with the Staging slot with the IP addresses of the machines attached to the Production slot. The update operation of the internal table of IP addresses of the load balancer Azure takes a matter of seconds. Thus, from the user's point of view, updating the application to the new version happens instantly.
Let's now look at the pros and cons of this approach.
Pros:
- Changing IP addresses in the load balancer table takes seconds
- Test and production environments are isolated from each other.
- If necessary, there is an opportunity to "return everything back" (Swap in the opposite direction)
- Support for both Web roles and Worker
- Deploy directly from Visual Studio
Minuses:
- The configuration of virtual machines in the Staging and Production slots must be the same.
- No support for virtual machines deployed within IaaS
- Additional costs for virtual machines deployed in a parallel slot
Analysis of this update method shows that it is quite suitable for use in the production environment. When using PaaS approach to deploying an application, it is one of the most optimal.
Today, this is all that I wanted to tell you. Next time we will see what tools Microsoft Azure can use to update the application deployed as part of IaaS. Do not switch!
Source: https://habr.com/ru/post/226093/
All Articles