Set Up a Cloud Service for Azure
Updated: October 24, 2014
To set up a cloud service, you must create the service model. The service model provides definition settings for the cloud service and configuration values for those settings. You cannot change the definition of a cloud service while it is running in Azure. Although you can change the configuration of the service model for a running cloud service, to change the definition settings of a service model, you must upgrade the cloud service by using a VIP swap.
|You can use Visual Studio to create and configure the service model files. For more information, see Configuring the Azure Application with Visual Studio.|
You can use the following information to get started creating, configuring, and changing the service model for a cloud service:
The service model consists of a ServiceDefinition.csdef file and a ServiceConfiguration.cscfg file. The definition file is packaged with the role binaries when the application for the cloud service is prepared for deployment. The ServiceConfiguration.cscfg file is deployed with the application package and is used by Azure to determine how the application should run.
The ServiceDefinition.csdef file specifies the settings that are used by Azure to configure a cloud service. The Azure Service Definition Schema (.csdef File) provides the allowable format for a service definition file. The following example shows the settings that can be defined for the Web and Worker roles:
<?xml version="1.0" encoding="utf-8"?> <ServiceDefinition name="MyServiceName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"> <WebRole name="WebRole1" vmsize="Medium"> <Sites> <Site name="Web"> <Bindings> <Binding name="HttpIn" endpointName="HttpIn" /> </Bindings> </Site> </Sites> <Endpoints> <InputEndpoint name="HttpIn" protocol="http" port="80" /> <InternalEndpoint name="InternalHttpIn" protocol="http" /> </Endpoints> <Certificates> <Certificate name="Certificate1" storeLocation="LocalMachine" storeName="My" /> </Certificates> <Imports> <Import moduleName="Connect" /> <Import moduleName="Diagnostics" /> <Import moduleName="RemoteAccess" /> <Import moduleName="RemoteForwarder" /> </Imports> <LocalResources> <LocalStorage name="localStoreOne" sizeInMB="10" /> <LocalStorage name="localStoreTwo" sizeInMB="10" cleanOnRoleRecycle="false" /> </LocalResources> <Startup> <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple" /> </Startup> </WebRole> <WorkerRole name="WorkerRole1"> <ConfigurationSettings> <Setting name="DiagnosticsConnectionString" /> </ConfigurationSettings> <Imports> <Import moduleName="RemoteAccess" /> <Import moduleName="RemoteForwarder" /> </Imports> <Endpoints> <InputEndpoint name="Endpoint1" protocol="tcp" port="10000" /> <InternalEndpoint name="Endpoint2" protocol="tcp" /> </Endpoints> </WorkerRole> </ServiceDefinition>
You can refer to the Service Definition Schema for understanding the format of an element, and you can use the following information for a better understanding of how to use these elements:
Sites – contains the definitions for websites or web applications that are hosted in IIS7.
InputEndpoints – contains the definitions for endpoints that are used to contact the cloud service.
InternalEndpoints – contains the definitions for endpoints that are used by role instances to communicate with each other.
ConfigurationSettings – contains the setting definitions for features of a specific role.
Certificates – contains the definitions for certificates that are needed for a role. The previous code example shows a certificate that is used for the configuration of Azure Connect.
LocalResources – contains the definitions for local storage resources. A local storage resource is a reserved directory in the file system of the virtual machine in which an instance of a role is running.
Imports – contains the definitions for imported modules. The previous code example shows the modules for Remote Desktop Connection and Azure Connect.
Startup – contains tasks that are run when the role starts. The tasks are defined in a .cmd or executable file.
The configuration of the settings for your cloud service is determined by the values in the ServiceConfiguration.cscfg file. You specify the number of instances that you want to deploy for each role in this file. The values for the configuration settings that you defined in the service definition file are added to the service configuration file. The thumbprints for any management certificates that are associated with the cloud service are also added to the file. The Azure Service Configuration Schema (.cscfg File) provides the allowable format for a service configuration file.
The service configuration file is not packaged with the application, but is uploaded to Azure as a separate file and is used to configure the cloud service. You can upload a new service configuration file without redeploying your cloud service. The configuration values for the cloud service can be changed while the cloud service is running. The following example shows the configuration settings that can be defined for the Web and Worker roles:
<?xml version="1.0"?> <ServiceConfiguration serviceName="MyServiceName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"> <Role name="WebRole1"> <Instances count="2" /> <ConfigurationSettings> <Setting name="SettingName" value="SettingValue" /> </ConfigurationSettings> <Certificates> <Certificate name="CertificateName" thumbprint="CertThumbprint" thumbprintAlgorithm="sha1" /> <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="CertThumbprint" thumbprintAlgorithm="sha1" /> </Certificates> </Role> </ServiceConfiguration>
You can refer to the Service Configuration Schema for understanding the format of an element, and you can use the following information for a better understanding of how to use these elements:
Instances – configures the number of running instances for the role. To prevent your cloud service from potentially becoming unavailable during upgrades, it is recommend that you deploy more than one instance of your web-facing roles. By doing this, you are adhering to the guidelines in the Azure Compute Service Level Agreement (SLA), which guarantees 99.95% external connectivity for Internet-facing roles when two or more role instances are deployed for a service. For more information about the Azure Service Level Agreement, see Service Level Agreements.
ConfigurationSettings – configures the settings for the running instances for a role. The name of the Setting elements must match the setting definitions in the service definition file.
Certificates – configures the certificates that are used by the service. The previous code example shows how to define the certificate for the RemoteAccess module. The value of the thumbprint attribute must be set to the thumbprint of the certificate to use.
The thumbprint for the certificate can be added to the configuration file by using a text editor, or the value can be added on the Certificates tab of the Properties page of the role in Visual Studio.
The multi-web application service model in Azure allows only one entry point to the web role. This means that all traffic occurs through one IP address. You can configure your websites to share a port by configuring the host header to direct the request to the correct location. You can also configure your websites and web applications to listen to well-known ports on the IP address.
The following sample shows the configuration for a web role with a website and web application. The website is configured as the default entry location on port 80, and the web applications are configured to receive requests from an alternate host header that is called “mail.mysite.cloudapp.net”.
<WebRole> <ConfigurationSettings> <Setting name="DiagnosticsConnectionString" /> </ConfigurationSettings> <Endpoints> <InputEndpoint name="HttpIn" protocol="http" port="80" /> <InputEndpoint name="Https" protocol="https" port="443" certificate="SSL"/> <InputEndpoint name="NetTcp" protocol="tcp" port="808" certificate="SSL"/> </Endpoints> <LocalResources> <LocalStorage name="Sites" cleanOnRoleRecycle="true" sizeInMB="100" /> </LocalResources> <Site name="Mysite" packageDir="Sites\Mysite"> <Bindings> <Binding name="http" endpointName="HttpIn" /> <Binding name="https" endpointName="Https" /> <Binding name="tcp" endpointName="NetTcp" /> </Bindings> </Site> <Site name="MailSite" packageDir="MailSite"> <Bindings> <Binding name="mail" endpointName="HttpIn" hostheader="mail.mysite.cloudapp.net" /> </Bindings> <VirtualDirectory name="artifacts" /> <VirtualApplication name="storageproxy" /> <VirtualDirectory name="packages" packageDir="Sites\storageProxy\packages"/> </VirtualApplication> </Site> </WebRole>
You can update the configuration of your cloud service while it is running in Azure, without taking the service offline. To change configuration information, you can either upload a new configuration file, or edit the configuration file in place and apply it to your running service. The following changes can be made to the configuration of a service:
Changing the values of configuration settings. When a configuration setting changes, a role instance can choose to apply the change while the instance is online, or to recycle the instance gracefully and apply the change while the instance is offline.
Changing the service topology of role instances. Topology changes do not affect running instances, except where an instance is being removed. All remaining instances generally do not need to be recycled; however, you can choose to recycle role instances in response to a topology change.
Changing the certificate thumbprint. You can only update a certificate when a role instance is offline. If a certificate is added, deleted, or changed while a role instance is online, Azure gracefully takes the instance offline to update the certificate and bring it back online after the change is complete.
The Azure Managed Library includes the Microsoft.WindowsAzure.ServiceRuntime namespace, which provides classes for interacting with the Azure environment from code running in an instance of a role. The RoleEnvironment class defines the following events that are raised before and after a configuration change:
The Changing event occurs before the configuration change is applied to a specified instance of a role. This event may be cancelled, which causes Azure to recycle the role. When the role is recycled, the configuration change is applied before the role is brought back online again. For more information about using the Changing event, see Use the RoleEnvironment.Changing Event.
The Changed event occurs after the configuration change is applied to a specified instance of a role. For more information about using the Changed event, see Use the RoleEnvironment.Changed Event.
|Because certificate changes always take the instances of a role offline, they do not raise the RoleEnvironment.Changing or RoleEnvironment.Changed events.|