6

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?

Jude Fisher
  • 11,138
  • 7
  • 48
  • 91
  • In partial answer to my own question: yes, changing the name of my MVC Web Project (which also changes the name of the role) to something like "_web" does bring it to the top of the list and means it binds consistently to 127.255.0.0. I'm still interested if there's a better way to do this, though, as this feels like a hack. – Jude Fisher Aug 15 '12 at 10:48

2 Answers2

6

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.

Lorenzo Melato
  • 1,626
  • 1
  • 17
  • 16
  • Hey @lorenzo-melato - could you please tell me more about how you did this? My question about this is at: http://stackoverflow.com/questions/20493043/how-to-map-ip-to-hostname-when-debugging-azure-cloud-projects – mbaaz Dec 10 '13 at 13:57
  • Hey @mbaaz. Sorry I see just now your comment... Precisely what is not clear for you? – Lorenzo Melato Dec 23 '13 at 17:17
  • Thanks for your answer @lorenzo-melato. My interest would be how you wrote your UpdateDnsHostsOnDebugEnv.exe, ie. how you would use the csrun.exe to get the information needed from the project being debugged. I can't seem to figure that one out right now. – mbaaz Jan 09 '14 at 10:58
  • Sorry to bother you so much @lorenzo-melato. I got it working now after a couple of hours, by parsing the result from csrun.exe /status and looking for the correct endpoint for my project. – mbaaz Jan 09 '14 at 14:46
  • Would you mind sharing your implementation of UpdateDnsHostsOnDebugEnv.exe? that would be really helpful... – Uri Abramson Feb 11 '16 at 15:46
4

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.

astaykov
  • 30,768
  • 3
  • 70
  • 86
  • 1
    I don't want to change it - I just want it to be consistent, so my ACS still works. ACS is configured externally, in the management console, so RoleEnvironment is of no use. "All your roles are only accessed via 127.0.0.1:[port]" - this is not correct. 127.0.0.1 points to something else entirely on my system (regular IIS running sites as localhost). – Jude Fisher Aug 15 '12 at 10:49
  • when working locally with Compute Emulator, your base address for your Relying Party at ACS shall be http://127.0.0.1:[given port]/ Where 127.0.0.1 is never changed, regardles of number of roles/instances you have/add/remove. And Port will depend on port availability, but usually is 81, because 80 is occupied by running IIS (full). – astaykov Aug 15 '12 at 10:52
  • Strange - IIS express makes it available on both 127.0.0.1:82 (as you say) and 127.255.0.* - where * is incremented with each Role. I didn't realise the former binding was there, as the second one works perfectly (including Role Discovery etc - so it's definitely emulated). Anyway: marked as answer. Thanks for the quick assistance. – Jude Fisher Aug 15 '12 at 10:57
  • it is not IIS Express that makes it available on 127.0.0.1, but the Compute Emulator. IIS Express is only bound to 127.255.0.* – astaykov Aug 15 '12 at 11:01
  • What's confusing is that when I hit F5 in VS it goes to the 127.255 address, not 127.0. Not sure why that is. – Jude Fisher Aug 15 '12 at 11:02
  • hm, just tried your scenario and F5 goes to 127.0.0.1, while IISExpress only listens to 127.255.0.X. Is your CLOUD PROJECT your startup project? VS will laund default browser on 127.255.0.X if your WEB Project is your STARTUP PROJECT. When working with Windows Azure and compute emulator - always set the Cloud Project as STARTUP PROJECT. – astaykov Aug 15 '12 at 11:12
  • Thanks for your help - my VS has the cloud service project as startup (otherwise all the Role discovery etc. would fall over), but for some reason f5 launches the IISExpress binding. I have to finish something so don't have time to diagnose now, and repointing it to 127.0.0.1:81 works fine, so I'll just do that for now. – Jude Fisher Aug 15 '12 at 11:17