Introduction
The initial offerings of Windows Azure were limited. Things like full-trust, execution of native code, etc. were prohibited because of security reasons. For example, the full IIS feature set was restricted. Even the IIS Hosted Web core only allowed a web role to attach to only a single HTTP and a single HTTPS endpoint. While this would suffice in simple cases, certain advanced scenarios were not being permitted.
As the platform got more mature, more complex execution options were permitted. Things like administrative access and full IIS support were introduced in the platform.
The latest version of the Windows Azure SDK now permits us to run our services under IIS7 (not just the Hosted Web core). This permits usage of all facilities of IIS like multiple websites, VDIR support, isolation of application pools, etc.
The Windows Azure platform also allows new ways for configuration. You can set it up to start as “Administrator” so that you can perform certain administrative tasks like setups, update configuration settings, and other bootstrapping steps. Your code resumes normal execution after these steps are complete, so this prevents elevation of privilege of the code for the entire duration the codebase is deployed to the cloud. Alternately, you can choose to run as “Administrator” for the entire lifetime of your deployment.
Earlier, we only had a single application ties to an endpoint (HTTP and/or HTTPS). This needed minimal configuration and the service configuration looked as under.
The Setup
By default, a Windows Azure cloud project’s service definition file looks like this (when you have a web role and a worker role added to the solution):
<?xml version=”1.0″ encoding=”utf-8″?>
<ServiceDefinition name=”WindowsAzureProject2″ >
<WebRole name=”WebRole1″ vmsize=”Small”>
<Sites>
<Site name=”Web”>
<Bindings>
<Binding name=”Endpoint1″ endpointName=”Endpoint1″ />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name=”Endpoint1″ protocol=”http” port=”80″ />
</Endpoints>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WebRole>
<WorkerRole name=”WorkerRole1″ vmsize=”Small”>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WorkerRole>
</ServiceDefinition>
Under the new settings permitted by the Windows Azure cloud platform, you can include TCP as an additional protocol which is supported along with HTTP and HTTPS.
Additionally, you can specify that a role is supported on multiple sites, virtual applications and can also bind each site to multiple endpoints.
You can add the binding either manually by editing the service definition file (ServiceDefinition.csdef) or by using the WebRole Properties Page.
For example, let’s imagine that we have three websites called www.foo.com , www.bar.com and www.helloworld.com which are supposed to run the same code in the backend. To facilitate this, we can set the service definition file like this.
<?xml version=”1.0″ encoding=”utf-8″?>
<ServiceDefinition name=”WindowsAzureProject2″ >
<WebRole name=”WebRole1″ vmsize=”Small”>
<Sites>
<Site name=”Foo” physicalDirectory=”..websitecode”>
<Bindings>
<Binding name=”Endpoint1″ endpointName=”Endpoint1″ hostHeader=”www.foo.com”/>
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name=”Endpoint1″ protocol=”http” port=”80″ />
</Endpoints>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WebRole>
<WorkerRole name=”WorkerRole1″ vmsize=”Small”>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WorkerRole>
</ServiceDefinition>
To add support for running bar.com and helloworld.com on the same webrole, we need to add another “site” node in the service definition file, one for each website.
Our service definition file will look as under when you add these nodes (the added code is highlighted).
<?xml version=”1.0″ encoding=”utf-8″?>
<ServiceDefinition name=”WindowsAzureProject2″ >
<WebRole name=”WebRole1″ vmsize=”Small”>
<Sites>
<Site name=”Foo” physicalDirectory=”..websitecode”>
<Bindings>
<Binding name=”Endpoint1″ endpointName=”Endpoint1″ hostHeader=”www.foo.com”/>
</Bindings>
</Site>
<Site name =”bar” physicalDirectory=”..websitecode”>
<Bindings>
<Binding name=”Endpoint1″ endpointName=”Endpoint1″ hostHeader=”www.bar.com”/>
</Bindings>
</Site>
<Site name =”helloworld” physicalDirectory=”..websitecode”>
<Bindings>
<Binding name=”Endpoint1″ endpointName=”Endpoint1″ hostHeader=”www.helloworld.com”/>
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name=”Endpoint1″ protocol=”http” port=”80″ />
</Endpoints>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WebRole>
<WorkerRole name=”WorkerRole1″ vmsize=”Small”>
<Imports>
<Import moduleName=”Diagnostics” />
</Imports>
</WorkerRole>
</ServiceDefinition>
Now, when you run the application and start IIS, you will notice that under your Sites node, there are 3 site nodes, one each for www.foo.com , www.bar.com and www.helloworld.com.
You will note that the port for each of the sites will be different. This is because the websites are currently on your local machine. However the main thing to notice here is that if you inspect the application pools node in IIS manager, you will notice that the same application pool is used for the three websites, which means that they are running off one instance of the application.
Summary
In this article, we learned how to configure advanced web roles to allow using the same role for multiple websites. I hope you have found this information useful.
About the author
Vipul Patel is a Software Engineer currently working at Microsoft Corporation. He is currently working in the Microsoft Lync team and has worked in the .NET team earlier in the Base Class libraries and the Debugging and Profiling team. He can be reached at vipul_d_patel@hotmail.com
