Freigeben über

Azure VIP

  • Artikel

 

English

Français
A few days ago, it was announced on the Windows Azure blog that the Azure Virtual IP Address was now guaranteed to be maintained as long as a deployment is not deleted. Azure comes with a mechanism to help Blue Green Deployment: staging and production environments, for each hosted service, as well as the VIP Swap feature. The purpose of this blog post is to check with an example how this really behaves. For that, a simple App is created which calls from within the Web Server (the Web Role) a page on the Internet (https://whatismyipaddress.com/) that displays the IP address of its caller. The result is displayed inside the Web Role Web Page. Il a été annoncé il y a quelques jours sur le blog Windows Azure que l’adresse IP virtuelle Azure était maintenant garantie d’être la même tant que le déploiement n’est pas supprimé.Azure fournit un mécanisme qui permet le déploiement de type bleu-vert: les environnements de staging (pré-production) et production, pour chaque service hébergé, ainsi que la fonctionnalité d’échange d’adresse IP virtuelle.Le but de ce billet est de vérifier comment cela se comporte conrètement.Pour cela, on crée un application qui appelle depuis le serveur Web (le Web Role) une page Internet (https://whatismyipaddress.com/) qui affiche l’adresse IP de son appelant. Le résultat est affiché à l’intérieur de la page Web du Web Role.

image

image

 

Here is the code of the application (an ASP.NET Web Role). In Default.aspx, the follwoing was added Voici le code de l’application (un Web Roel ASP.NET).Dans Default.apsx, on a ajouté 
     <asp:Button ID="Button1" runat="server" 
            Text="show this service's outgoing IP Address" onclick="Button1_Click" />
    </p>

    <asp:Literal ID="LiteralRequestIPAddress" runat="server"></asp:Literal>
    <asp:Literal ID="LiteralServerIPAddress" runat="server"></asp:Literal>
In Default.aspx.cs, there is: Dans Default.aspx.cs, on a: 
 using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Net;
using System.IO;


namespace WebRole1
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            LiteralRequestIPAddress.Text = "request from " + Request.UserHostAddress;
        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            string html;

            using (var stream = HttpWebRequest
                .Create("https://whatismyipaddress.com/")
                .GetResponse().GetResponseStream())
            {
                using (var reader = new StreamReader(stream))
                {
                    html = reader.ReadToEnd();
                }
            }

            LiteralServerIPAddress.Text = html;
        }
    }
}
In Azure, public input and output IP addresses are the same (@IP2-in == @IP2-out) so, not having @IP2-in displayed should not be an issue.The application will live in bengjuin2 hosted service, inside my Azure subscription. benjguin2, as any hosted service has a staging environemnt and a production environment.The application, in its version V1 is deployed to the production environment as this is the first deployment ever for that App. Avec Azure, les adresses IP d’entrée et de sortie sont les mêmes (@IP2-in == @IP2-out) et donc, ne pas avoir l’affichage de @IP2-in ne devrait pas être un problème.L’application va vivre sa vie dans le service hébergé benjguin2 de mon abonnement Azure. benjguin2, comme n’importe quel service hébergé a un environnement de staging et un environnement de production.On déploie l’application, dans sa version V1dans l’environnement de production puisque c’est le tout premier déploiement de cette application.

 

image

Testing it gives the following result (after having clicked on the button) On la teste et on obtient (après avoir cliqué sur le bouton)

image

so in production, and from my location, @IP1 = image and @IP2-out is image. In order to check that @IP2-in == @ip2-out, one can navigate to @IP2-out: donc en production, et depuis l’endroit d’où je teste, @IP1 = image et @IP2-out vaut image. De façon à vérifier que @IP2-in == @ip2-out, on peut naviguer à  @IP2-out:

image

In fact, this @IP2 adress can be seen in the Windows Azure portal En fait, cette adresse @IP2 est visible dans le portail Windows Azure

image

App V2 now has to be deployed. In order to do that, deployment is done to the staging environment. On doit maintenant déployer la V2 de l’application. Pour cela, on déploie en staging.

image

Testing, with the DNS name that was created while deploying to staging environment: On teste, avec le nom DNS qui a été créé lors du déploiement dans l’environnement de staging

image

image

image

image

So in staging, @IP2 is imageOK. Now App V2 has been tested, so it’s time to move users to App V2, instead of App V1.This can be done from the Windows Azure Portal: Donc en staging, @IP2 vaut imageOK. Maintenant l’application V2 a été testée, et il est temps de basucler les utilisateurs sur cette V2, à la place de leur actuelle V1.Cela peut être fait depuis le portail Azure:

image

image

image

image

image

The production IP address did not change, neither the name. They are still benjguin2.cloudapp.net and image but they now host App V2.The internal App V2 IP addresses remained the same from staging to production but the load balancer now associated them to the production public VIP and DNS name.This is good news, because only the staging environment may have to be removed from time to time. There are good chances that production always has to be up and running (with more or less resources over time, depending on the demand, but still deployed).So, in our example, only the staging IP Address will be lost when removing staging deployment (retiring App V1).After a few hours in production, App V2 is OK, so APP V1 can be deprovisioned from staging in order to stop paying for the staging environment. L’adresse IP de production n’a pas changé, le nom non plus d’ailleurs. Il s’agit toujours de benjguin2.cloudapp.net et image mais ils hébergent maintenant l’application V2.Les adresses IP internes de l’application V2 sont restées les mêmes en passant de staging à production mais le répartiteur de charge les a maintenant associées à l’adresse IP virtuelle et au nom DNS de production.Cela est une bonne nouvelle, puisque seul l’environnement de staging aura besoin d’être supprimé de temps à autre. Il y a de grandes chances à l’inverse que la production devra toujours rester disponible (avec plus ou moins de ressources en fonction des besoins, mais déployée).Ainsi, dans notre exemple, seule l’adresse IP de staging sera perdue quand on supprimera le déploiement de staging (la vielle App V1).Après quelques heures en production, App V2 est OK, donc App V1 peut être enlevée du staging de façon à ne plus avoir à payer pour cet environnement.

Stop

At this stage, the IP staging address is still available (and the service is still invoiced). It will be removed when deleting the deployment. A cette étape, l’adresse IP de staging est toujours disponible (et on paie toujours). Il sera supprimé quand on supprimera le déploiement.

Delete

image

image

…

image

App V3 is now ready to be deployed App V3 est maintenant prête à être déployée

image

image

This time we get a completely different address for staging environment Cette fois-ci, on a une adresse complètement différente pour l’environnement de staging

image

but you get the idea, after deploying App V3 from staging to production, the production VIP address will still be the same as for App V1: image, and this will still be the case as long as you do not delete the deployment in the benjguin2 production environment vous voyez l’idée. Après avoir déployé App V3 du staging à la production, l’adresse IP virtuelle de production sera toujours la même que ce qu’on avait en V1: image, et cela restera le cas tant qu’on ne supprime pas le déploiement de l’environnement de production de benjguin2.

image

Smile

Benjamin