Azure Compute Emulator: Is it possible to control

问题:

Working with the June 2012 Azure SDK, Visual Studio 2010, and IIS Express, I have a web application which has been running on 127.255.0.2. I'm using ACS for authentication, and my app is configured as a relying party at this IP. I've added a new worker role to my solution and for some reason this has pushed my web app's IP back to 127.255.0.3. This is the third time changes elsewhere in the solution have changed this IP, and I'm getting a little tired of having to add new relying party settings and re-run the STS wizard.

Is there any formal way to control which emulated role binds to which IP? And if there isn't, then is the order of startup/binding the same as the order of projects in the Roles folder, and if so then would calling my web role something like Aardvark ensure it was always first to bind?

回答1:

Why would you want to change that IP Address? This is used only internally to avoid IP/Port conflicts. All your roles are only accessed via 127.0.0.1:[port] and this is the address you should use as base address of your relying party app. The 127.255.0.XX addresses are internal addresses that live behind the emulated Load Balancer of the Compute Emulator.

There is no formal, nor informal way to control the instance's IP Address of instance / role for Compute Emulator. Plus even if there was a way to do that, I would not suggest to use it!

You can always get the correct IP Address and Port of any Endpoint configured in your cloud service via the RoleEnvironment.CurrentRoleInstance.InstanceEndpoints property.

Read about IP Address and Port allocation here.

UPDATE

Although your app is bound to 127.255.0.XX (emulated Direct IP Address, a.k.a. DIP) in the IIS Express, the actual call to your app shall go through 127.0.0.1:81 (emulated Virtual IP Address, a.k.a. VIP) (where only port changes). And this is default load page when Visual Studio launches your app. The development Fabric (a.k.a. Compute Emulator) has emulated Load Balancer, which listens on 127.0.0.1:81 (emulated VIP) and redirects traffinc to the appropriate instances, which are spread across 127.255.0.XX (emulated DIP). That's why you have to always use 127.0.0.1 when working with compute emulator and when Configuring ACS relying party. Anything else you do is wrong and not representing Azure environment.

You can read through this and that blog entries to understand the reminology and networking withing Windows Azure.

回答2:

I don't know if my experience match exactly the descripted scenario but I think it can, at least, be an inspiration.

In my solution I have four distinct cloud services, every one have a web role, and every one must know the url of other services to works properly. When in production I know exactly the urls of all my services and I can refer to each service by its domain name. But when it's time do debug this can be a nightmare because there is no option to bind a cloud service to a specific IP address (and port) and DevFabric can't guarantee that a particular cloud service maintain the same address between two different debug session.

I have solved the problem with a simple technique:

In my WebRoles I refer always to domain name like debug.myservice.com or debug.myotherservice.com.

The local ip address is resolved using the hosts file you can find in:

windows/system32/drivers/etc/hosts

by append some simple statements like, for example:

127.0.0.1 debug.myservice.com
127.0.0.2 debug.myotherservice.com

This solve the problem but can be extremely boring because you need to update manually the hosts file every time you launch a new debug session.

But there is a simple and powerful solution. You know you can setup a simple startup script that is executed every time the cloud service is initialized, you can find details here:

http://msdn.microsoft.com/en-us/library/windowsazure/hh180155.aspx

Also you can run different script when you are running on the cloud or in the emulator.

What I do is to run a script that automatically update the hosts file every time my cloud service are initialized in the emulator (and only in the emulator) environment.

Here the script:

IF "%ComputeEmulatorRunning%" == "true" (
    cd Startup
    UpdateDnsHostsOnDebugEnv.exe MyCompany.MyService.Site.WebRole debug.myservice.com
    cd..
)

and here what you need to add to ServiceDefinition.csdef in order to run the script in the startup:

<Startup>
    <Task commandLine="Startup\UpdateDnsHosts.cmd" executionContext="elevated" taskType="foreground">
       <Environment>
           <Variable name="ComputeEmulatorRunning">
               <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
           </Variable> 
       </Environment>
     </Task>
</Startup>

Notice the use of the UpdateDnsHostsOnDebugEnv.exe program. This is a simple console app that I wrote that simply run csrun.exe and parse the result to extract the local endpoint address of the role and update the hosts file.

Hope this help.