Staged Deployment on Microsoft Azure Websites When you deploy your application to Azure Websites, you can deploy to a separate deployment slot instead of the default production slot, which are actually live sites with their own hostnames . This option is available in the Standard web hosting plan. Benefits You can validate website changes in a staging deployment slot before swapping it with the production slot. After a swap, the slot with previously staged site now has the previous production site. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your "last known good site" back. Deploying a site to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your site. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. Deployment Slots Support Details Four deployment slots in addition to the production slot are supported for each website in the Standard web hosting plan. Multiple deployment slots are only available for sites in the Standard web hosting plan. When your website has multiple slots, you cannot change the web hosting plan. Scaling is not available and Linked resource management is not supported for non-production slots. By default, your deployment slots (sites) share the same resources as your production slots (sites) and run on the same VMs. If you run stress testing on a stage slot, your production environment will experience a comparable stress load.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Staged Deployment on Microsoft Azure Websites
When you deploy your application to Azure Websites, you can deploy to a separate deployment slot instead of the default production slot, which are actually live sites with their own hostnames.
This option is available in the Standard web hosting plan.
Benefits
You can validate website changes in a staging deployment slot before swapping it
with the production slot.
After a swap, the slot with previously staged site now has the previous production site.
If the changes swapped into the production slot are not as you expected, you can
perform the same swap immediately to get your "last known good site" back.
Deploying a site to a slot first and swapping it into production ensures that all
instances of the slot are warmed up before being swapped into production. This
eliminates downtime when you deploy your site. The traffic redirection is seamless,
and no requests are dropped as a result of swap operations.
Deployment Slots Support DetailsFour deployment slots in addition to the production slot are supported for each website
in the Standard web hosting plan.
Multiple deployment slots are only available for sites in the Standard web hosting plan.
When your website has multiple slots, you cannot change the web hosting plan.
Scaling is not available and Linked resource management is not supported for non-
production slots.
By default, your deployment slots (sites) share the same resources as your production
slots (sites) and run on the same VMs. If you run stress testing on a stage slot, your
production environment will experience a comparable stress load.
Configuration for Deployment SlotsSettings that are swapped:
General settings - such as framework version, 32/64-bit, Web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Monitoring and diagnostic settings
Settings that are not swapped:
Publishing endpoints
Custom Domain Names
SSL certificates and bindings
Scale settings
Azure PowerShell cmdlets for Site SlotsGet-AzureWebsite
The following items are not supported during an update:
Changing the name of a role. Remove and then add the role with the new name.
Changing of the Upgrade Domain count.
Decreasing the size of the local resources.
Rollback of an update
To test whether a rollback is allowed, check the value of the RollbackAllowed flag, returned
by Get Deployment and Get Cloud Service Properties operations, is set totrue.
Rollback of an in-progress update has the following effects on the deployment:
Any role instances which had not yet been updated or upgraded to the new version are not updated or upgraded, because those instances are already running the target version of the service.
Any role instances which had already been updated or upgraded to the new version of the service package (*.cspkg) file or the service configuration (*.cscfg) file (or both files) are reverted to the pre-upgrade version of these files.
This functionally is provided by the following features:
The Rollback Update Or Upgrade operation, which can be called on a configuration update (triggered by calling Change Deployment Configuration) or an upgrade (triggered by calling Upgrade Deployment) as long as there is at least one instance in the service which has not yet been updated to the new version.
The Locked element and the RollbackAllowed element, which are returned as part of the response body of the Get Deployment and Get Cloud Service Properties operations:
1. The Locked element allows you to detect when a mutating operation can be invoked on a given deployment.
2. The RollbackAllowed element allows you to detect when the Rollback Update Or Upgrade operation can be called on a given deployment.
In order to perform a rollback, you do not have to check both the Locked and the RollbackAllowed elements. It suffices to confirm that RollbackAllowed is set to true. These elements are only returned if these methods are invoked by using the request header set to “x-ms-version: 2011-10-01” or a later version. For more information about versioning headers, see Service Management Versioning.
There are some situations where a rollback of an update or upgrade is not supported, these are as follows:
Reduction in local resources - If the update increases the local resources for a role the Azure platform does not allow rolling back. For more information about how to configure local resources for a role, see Configure Local Storage Resources.
Quota limitations - If the update was a scale down operation you may no longer have sufficient compute quota to complete the rollback operation. Each Windows Azure subscription has a quota associated with it that specifies the maximum number of cores which can be consumed by all hosted services that belong to that subscription. If performing a rollback of a given update would put your subscription over quota then that a rollback will not be enabled.
Race condition - If the initial update has completed, a rollback is not possible.
create hosting plans
Azure Websites Web Hosting Plans In-Depth Overview Represent a set of features and capacity that you can share across your websites.
Support the 4 Azure Websites pricing tiers (Free, Shared, Basic, and Standard)
Sites in the same subscription, resource group, and geographic location can share a
web hosting plan.
All websites associated with a given web hosting plan run on the resources defined by
the web hosting plan
Websites, Web Hosting Plans, and Resource GroupsA website can be associated with only one web hosting plan at any given time. A web
hosting plan is associated with a resource group. A Resource group is a new concept in
Azure that serves as the lifecycle boundary for every resource contained within it.
Resource groups enable you to manage all the pieces of an application together.
You can have multiple web hosting plans in a resource group and each hosting plan will
have its own set of features and capabilities that are utilized by its associated sites.
The ability to have multiple web hosting plans in a single resource group allows you to
allocate different sites to different resources, primarily virtual machines running your
websites.
Having multiple web hosting plans in a single resource group also allows you to define
an application that spans across regions.
Since you can move websites between web hosting plans, assuming the web hosting
plans are in the same regions
you cannot move web hosting plans or websites between resource groups. Also, you
cannot move a website between two web hosting plans that are in two separate
regions.
On top of managing websites resources and respective sites for a given application, you
can associate any related Azure resource such as SQL-Azure databases, and Team
Projects.
When should I create a new resource group and when should I create a new web hosting plan?When creating a new website, you should consider creating a new resource group when
the website you are about to create represents a new web application.
Creating a new hosting plan allows you to allocate a new set of resource for your
websites, and provides you with greater control over resource allocation, as each web
hosting plan gets its own set of virtual machines. Since you can move websites between
web hosting plans, assuming the web hosting plans are in the same regions, the
decision of whether to create a new web hosting plan or not is of less important. If a
given website starts consuming too many resources or you just need to separate a few
websites, you can create a new web hosting plan and move your websites to it.
If you want to create a new website in a different region, and that region doesn't have
an existing web hosting plan, you will have to create a new web hosting plan in that
region to be able to have a website associated with it.
An important thing to keep in mind is that you cannot move web hosting plans or
websites between resource groups. Also, you cannot move a website between two web
hosting plans that are in two separate regions.
Existing resources group in the Azure Preview portalIf you already have existing websites on Azure Websites, you will notice that all your
websites show up in the Azure preview portal.
You will also notice that you have an auto-generated default resource group in each
region you already have websites. The auto generated resource group name for
websites is Default-Web-*where location name represents an Azure region (for example
*Default-Web-WestUS). In each resource group you will find all your existing sites for
the group's region. Each site you created in the past and will create in the future in
either the Full Azure portal or the Azure Preview Portal will be available on both portals.
Since every website has to be associated with a web hosting plan, we have created
default web hosting plans for your existing sites according to the following convention,
in each region:
* All your Free websites are associated with a Default web hosting plan and its pricing
tier set to Free.
* All your Shared websites are associated with a Default web hosting plan and its
pricing tier set to Shared
* All your Standard websites are associated with a default web hosting plan and its
pricing tier set to Standard.
The name of this web hosting plan is DefaultServerFarm. This name was chosen to
support a legacy API. The name ServerFarm can be somewhat misleading as it refers
to a Web Hosting Plan, but it's important to notice that it is a name of a web hosting
plan and it is not an entity of its own.
Web Hosting Plan F.A.Q.
Question: How do I create a Web Hosting Plan?
Answer: A Web Hosting Plan is a container and as such, you can't create an empty Web
Hosting Plan. However, a new Web Hosting Plan is explicitly created during site
creation.
To do this using the UI in the new Azure Portal Preview click NEW and
select Website, which will open the Website creation blade. In the first image below
you can see the NEW icon on the bottom left, and in the second image you can see
the Website creation blade, the Web Hosting Plan blade and thePricing Tier blade:
t should also be noted that a Web Hosting Plan can also be created in the existing Azure
Portal. This is done as part of the quick create wizard by selectingCreate new web
hosting plan from the WEB HOSTING PLAN drop down:
Question: How do I assign a site to a Web Hosting Plan?
Answer: Sites are assigned to a Web Hosting Plan as part of the site creation process.
To do this using the UI in the new Azure Portal Preview, click NEWand
select Website
Question: How can I move a site to a different web hosting plan?
Answer: You can move a site to a different web hosting plan using the Azure Preview
Portal. Websites can be moved between web hosting plans in the same geographical
region that belong to the same resource group.
To move a site to another plan, navigate to the website blade of the site you want to
move. Then click Web Hosting Plan:
Note that each web hosting plan has its own pricing tier. When you move a site from
a Free tier web hosting plan to a Standard web hosting plan, your website will be able
to leverage all the features and resources of the Standard tier.
Question: How can I Scale a Web Hosting Plan?
Answer: There are two ways to scale a Web Hosting Plan. One way is to scale up your
web hosting plan and all sites associated with that web hosting plan. By changing the
pricing tier of a web hosting plan, all sites in that web hosting plan will be subject to the
features and resources defined by that pricing tier.
The second way to scale a plan is to scale it out by increasing the number of instances
in your Web Hosting Plan.
Question: How Can I Delete a Web Hosting Plan?
Answer: To delete a Web Hosting Plan you must first delete all websites associated
with it. Once all the Websites in a Web Hosting Plan have been deleted a Web Hosting
Plan can be deleted from the Web Hosting Plan blade:
In the Full Azure Portal deleting the last website in a web hosting plan will automatically
delete the associated web hosting plan.
Question: How Can I monitor a web hosting plan?
Answer: Web Hosting Plans can be monitored using the Monitoring parts in the Web
Hosting Plan Blade:
migrate websites between hosting plans
Azure Website Hosting Plans (WHP)
Configure websitesdefine and use app settings, connection strings, handlers, and virtual directories
Importance of app settings in azure website portalHowever you also don't want to edit the web.config every time you publish from Visual Studio.
Nobody other than the user with portal credentials will have access to your azure portal.
This also benefits you in the way that no more you need to store your data as clear text in web.config
This way you secure your web.config data from azure portal.
Windows Azure Web Sites: How Application Strings and Connection Strings WorkWindows Azure Web Sites has a handy capability whereby developers can store key-value string pairs in Azure as part of the configuration information associated with a website. At runtime, Windows Azure Web Sites automatically retrieves these values for you and makes them available to code running in your website.
since sensitive information such as Sql connection strings with passwords never show up as cleartext in a web.config or php.ini file.
Difference between appsetting and connectionstring includes a little extra metadata telling Windows Azure Web Sites that the string value is a database connection string.
Retrieving Key-Value Pairs as Environment Variables
Key-value can be retrieved at runtime by code running inside of a website through environment variables.
Here is what the example page output looks from the previous code snippet:
Developers can easily retrieve these values from any of the web application frameworks supported in Windows Azure Web Sites.
From the previous examples you will have noticed a naming pattern for referencing the individual keys. For “app settings” the name of the corresponding environment variable is prepended with “APPSETTING_”.
For “connection strings”, there is a naming convention used to prepend the environment variable depending on the type of database you selected in the databases dropdown. The sample code is using “SQLAZURECONNSTR_” since the connection string that was configured had “Sql Databases” selected in the dropdown.
The full list of database connection string types and the prepended string used for naming environment variables is shown below:
If you select “Sql Databases”, the prepended string is “SQLAZURECONNSTR_”
If you select “SQL Server” the prepended string is “SQLCONNSTR_”
If you select “MySQL” the prepended string is “MYSQLCONNSTR_”
If you select “Custom” the prepended string is “CUSTOMCONNSTR_”
Retrieving Key-Value Pairs in ASP.NET
“App settings” neatly map to the .NET Framework’s appSettings configuration. Similarly “connection strings” correspond to the .NET Framework’s connectionStrings collection.
If the application setting(s) happen to already exist in your web.config file, Windows Azure Web Sites will automatically override them at runtime using the values associated with your website.
code runs on a developer’s local machine, the value returned will be the one from the web.config file. However when this code runs in Windows Azure Web Sites, the value returned will instead be overridden with the value entered in the portal
Configuring Key-Value Pairs from the Command-lineApp setting
Connection string
Note that for the property $cs.Type, you can use any of the following strings to define the type: “Custom”, “SQLAzure”, “SQLServer”, and “MySql”.
HTTP Handlers and Windows Azure Web Roles
There are two types of storage account containers in Windows Azure – private and public. A resource in a private container can only be viewed by specifying an access key along with the request. A public container on the other hand is viewable by anyone. When creating a new storage account in Windows Azure, new containers are private by default. Therefore when you attempt to access a resource’s URL in the browser, you will get an HTTP 404
6. new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccess
Type.Off }
7. );
use an HTTP handler to intercept jpeg requests so that I can call one of the aforementioned methods and write the jpeg to the response stream which will display the image.
1. public class JpegHandler1 : IHttpHandler
2. {
3. public void ProcessRequest(HttpContext context)
The certificate must be created for key exchange, exportable to a Personal
Information Exchange (.pfx) file.
The certificate's subject name must match the domain used to access the
website. If you need to serve multiple domains with this certificate, you will need to
use a wildcard value or specify subjectAltName values as discussed previously.
The certificate should use a minimum of 2048-bit encryption.
Certificates issued from private CA servers are not supported by Azure Websites.
Get a certificate using Certreq.exe (Windows only)
Get a certificate using OpenSSL
Get a certificate using the IIS Manager
Configure Standard modeAzure Websites do not enforce HTTPS. Enabling HTTPS for a custom domain is only available for the Standard web hosting plan mode of Azure websites.
To enforce HTTPS for your website, you can use the URL Rewrite module. The URL
Rewrite module is included with Azure Websites, and enables you to define rules that
are applied to incoming requests before the requests are handed to your application. It
can be used for applications written in any programming language supported
by Azure Websites. URL Rewrite rules are defined in a web.config file stored in the
If your application is written in Node.js, PHP, Python Django, or Java, it probably
doesn't include a web.config file. However Node.js,Python Django, and Java all
actually do use a web.config when hosted on Azure Websites - Azure creates the file
automatically during deployment, so you never see it. If you include one as part of your
application, it will override the one that Azure automatically generates.
NOTE:
.NET MVC applications should use the RequireHttps filter instead of URL Rewrite.
Elliptic Curve Cryptography (ECC) certificates are supported with Azure Websites
Microsoft Azure Portal Logon to Azure portal.
Go to the CONFIGURE page for the site and scroll to the virtual applications and directories
section at the bottom of the page.
Add an entry
Click on SAVE.
Now go to the LINKED RESOURCES page and link a MySQL database to your site.
NOTE: Choose an existing MySQL DB or create a new one. Let's say you already have a free MySQL DB associated with your subscription but you want a separate MySQL database for the application. You will have to purchase a plan from CLEARDB for this
Under quick glance section a hyperlink called View connection strings will be created.
NOTE: You could retrieve the connection string parameters from the LINKED RESOURCES page too. Click on MANAGE in the bottom pane for the site. This will redirect you to ClearDB site which will provide you with the following
Database Data Source User Id Password
Download & save the publishsettings file for the website by clicking the hyperlink "Download
the publish profile" under quick glance section of theDASHBOARD page.
Local Machine Launch Microsoft WebMatrix
Click on New -> App Gallery
Select WordPress from the App Gallery and click on Next.
This will take you to through the WordPress setup.
Accept the EULA by clicking on "I ACCEPT"
Once done it will start downloading the contents to your local machine (C:\Users\<username>\
Documents\My Web Sites\WordPress)
During these process it allows you to configure certain application parameters as shown below:
Once you specify the parameters and click on Next it proceeds with the installation.
Once installed, click on "Copy user names and passwords". This will copy the details to
clipboard which you could save in a text file.
Click on OK.
Now click on Publish
This will prompt you with another window.
Click on Import publish profile and point it to the location where we saved the
publishsettings file we downloaded earlier.
Once selected, it will auto-populate the parameters from the publishsettings file.
We need to modify the following sections as shown below:o Site name: kaushal\wordpress (physical path location relative to the root site)
o Destination URL: http://kaushal.azurewebsites.net/blog (virtual directory name)
NOTE: Don't chose FTP as the protocol as it doesn't allow you to publish databases.
Click on Validate Connection. Once validated, you will see the confirmation.
Click on Save.
This will take you to the Publish Compatibility page. Click on Continue.
Once compatibility check has been performed. Click on Continue again.
It will display the list of files that will deployed to the server.
Click on Continue to start the deployment.
Once publishing is completed you could open the log file and analyze.
Click on the hyperlink as shown below to browse to the site:
Configuring a custom domain name for an Azure WebsiteWhen you create a website, Azure assigns it to a subdomain of azurewebsites.net.
Custom domain names cannot be used with Free websites. You must configure your websites for Shared, Basic, or Standard mode,
Here are the general steps to configure a custom domain name
1. Reserve your domain name.
2. Create DNS records that map the domain to your Azure website.
3. Add the domain name inside the Azure Management Portal.
DNS record typesThe Domain Name System (DNS) uses data records to map domain names into IP
addresses. There are several types of DNS records. For websites, you’ll create either
an A record or a CNAME record.
An A (Address) record maps a domain name to an IP address.
A CNAME (Canonical Name) record maps a domain name to another domain
name. DNS uses the second name to look up the address. Users still see the first
domain name in their browser. For example, you could map contoso.com
to <yoursite>.azurewebsites.net.
If the IP address changes, a CNAME entry is still valid, whereas an A record must be
updated. However, some domain registrars do not allow CNAME records for the root
domain or for wildcard domains. In that case, you must use an A record.
NOTE:
The IP address may change if you delete and recreate your website, or change
the website mode back to free.
Create the DNS records
Create an “awverify” record (A records only)If you create an A record, Azure websites also requires a special CNAME record, which is
used to verify that you own the domain you are attempting to use. This CNAME record
must have the following form.
If the A record maps the root domain or a wildcard domain: Create a CNAME record that
maps
from awverify.<yourdomain> to awverify.<yourwebsitename>.azurewebsites.n
et. For example, if the A record is for contoso.com, create a CNAME record
for awverify.contoso.com.
If the A record maps a specific subdomain: Create a CNAME record that maps
from awverify.<subdomain> to awverify.<yourwebsitename>.azurewebsites.n
et. For example, if the A record is for blogs.contoso.com, create a CNAME record
for awverify.blogs.contoso.com.
Visitors to your site will not see the awverify subdomain; it’s only for Azure to verify
your domain.
Enable the domain name on your websiteAfter the records for your domain name have propagated, you must associate them with
your website.
NOTE:
It can take some time for CNAME records created in the previous steps to propagate
through the DNS system. You cannot add the domain name of to your Azure Website
until the CNAME has propagated. If you are using an A record, you cannot add the A
record domain name to your Azure Website until the awverify CNAME record created in
the previous step has propagated.
Associating a custom domain and securing communication with Microsoft Azure
How to: Receive alerts from website metricsIn Standard website mode, you can receive alerts based on your website monitoring metrics. The alert feature requires that you first configure a web endpoint for monitoring, which you can do in the Monitoring section of the Configure page. On the Management Services page of the Azure Management Portal, you can then create a rule to trigger an alert when the metric you choose reaches a value that you specify. You can also choose to have email sent when the alert is triggered.
How to: View usage quotas for a websiteWebsites can be configured to run in either Shared or Standard website mode from the website's Scale management page. Each Azure subscription has access to a pool of resources provided for the purpose of running up to 100 websites per region in Shared website mode. The pool of resources available to each Website subscription for this purpose is shared by other websites in the same geo-region that are configured to run in Shared mode. Because these resources are shared for use by other websites, all subscriptions are limited in their use of these resources. Limits applied to a subscription's use of these resources are expressed as usage quotas listed under the usage overview section of each website's Dashboard management page.
he number of Standard mode websites that can be created per region is 500.
How to: Avoid exceeding your quotasQuotas are not a matter of performance or cost, but it's the way Azure governs resource
usage in a multitenant environment by preventing tenants from overusing shared
resources. Since exceeding your quotas means downtime or reduced functionality for
your website, consider the following if you want to keep your site running when quotas
are about to be reached:
Move your website(s) to a higher-tier Web hosting plan to take advantage of a larger
quota. For example, the only quota for Basic and Standard plans is File System
Storage.
As the number of instances of a website is increased, so is the likelihood of exceeding
shared resource quotas. If appropriate, consider scaling back additional instances of a
website when shared resource quotas are being exceeded.
How to: Configure diagnostics and download logs for a websiteDiagnostics are enabled on the Configure management page for the website. There
are two types of diagnostics: application diagnostics and site diagnostics.
Application Diagnostics
The application diagnostics section of the Configure management page controls the
logging of information produced by the application, which is useful when logging events
that occur within an application. For example, when an error occurs in your application,
you may wish to present the user with a friendly error while writing more detailed error
information to the log for later analysis.
You can enable or disable the following application diagnostics:
Application Logging (File System) - Turns on logging of information produced by the
application. The Logging Level field determines whether Error, Warning, or Information
level information is logged. You may also select Verbose, which will log all information
produced by the application.
Logs produced by this setting are stored on the file system of your website, and can be
downloaded using the steps in the Downloading log files for a website section
below.
Application Logging (Table Storage) - Turns on the logging of information produced
by the application, similar to the Application Logging (File System) option. However, the
log information is stored in an Azure Storage Account in a table.
To specify the Azure Storage Account and table, choose On, select the Logging Level,
and then choose Manage Table Storage. Specify the storage account and table to
use, or create a new table.
The log information stored in the table can be accessed using an Azure Storage client.
Application Logging (Blob storage) - Turns on the logging of information produced
by the application, similar to the Application Logging (Table Storage) option. However,
the log information is stored in a blob in an Azure Storage Account.
To specify the Azure Storage Account and blob, choose On, select the Logging Level,
and then choose Manage Blob Storage. Specify the storage account, blob container,
and blob name to use, or create a new container and blob.
Application logging to table or blob storage is only supported for .NET applications.
Diagnostics can also be enabled from Azure PowerShell using the Set-
AzureWebsite cmdlet.
Site Diagnostics
The site diagnostics section of the Configure management page controls the logging
performed by the web server, such as the logging of web requests, failure to serve
pages, or how long it took to serve a page. You can enable or disable the following
options:
Web Server Logging - Turn on Web Server logging to save website logs using the
W3C extended log file format. Web server logging produces a record of all incoming
requests to your website, which contains information such as the client IP address,
requested URI, HTTP status code of the response, and the user agent string of the client.
You can save the logs to an Azure Storage Account or to the File System.
To save web server logs to an Azure Storage Account, choose Storage, and then
choose manage storage to specify a storage account and an Azure Blob Container
where the logs will be kept. For more information about Azure Storage Accounts,
see How to Manage Storage Accounts.
To save web server logs to the file system, choose File System. This enables the Quota box where you can set the maximum amount of disk space for the log files. The minimum size is 25MB and the maximum is 100MB. The default size is
Advanced configuration
Diagnostics can be further modified by adding key/value pairs to the app
settings section of the Configure management page. The following settings can be
configured from app settings:
DIAGNOSTICS_TEXTTRACELOGDIRECTORY
The location in which application logs will be saved, relative to the web root.
Default value: ..\..\LogFiles\Application
DIAGNOSTICS_TEXTTRACEMAXBUFFERSIZEBYTES
The maximum buffer size to use when capturing application logs. Information is initially
written to the buffer before being flushed to file or storage. If new information is written
to the buffer before it can be flushed, you may lose previously logged information. If
your application produces large bursts of log information, consider increasing the size of
the buffer.
Default value: 10MB
DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES
The maximum size of the Application folder in which application diagnostics written to
Windows Azure Web Sites: SSL Support and configuration
Windows Azure Web Sites provide native support for SSL, which includes both SNI SSL and IP based SSL for custom web site domain names. . Before this the only way of doing SSL was via Cloud Service & Rewriting the URL.
This feature is not available to sites which are running in either Free or Shared mode.
ssl bindings section is enabled when the user has a valid custom domain name added for that site.
NOTE: If there are multiple bindings for the site then the domain names must be unique. Irrespective of whether they are IP based SSL bindings or SNI SSL bindings. In simple words, the rules that are applicable while configuring a SSL binding on IIS are still applicable here. Also Non-SNI compliant browsers will not be able to browse to the website if it is configured to use SNI SSL bindings.
The users have to shell out more money when they configure the website to use IP Based SSL. This is very obvious, as this requires a dedicated IP (a resource) to be allocated for the website. This is also an expensive resource.
SNI SSL is comparatively cheaper as it doesn’t need a dedicated IP Address. However, it has own limitations as the non-SNI compliant browsers will not be able to access the site.
How to configure PHP in Azure Websites
What is Azure Websites?Azure Websites allows you to build highly scalable websites on Azure. You can
quickly and easily deploy sites to a highly scalable cloud environment that allows you to
start small and scale as traffic grows. Azure Websites uses the languages and open
source apps of your choice and supports deployment with Git, FTP, and TFS. You can
easily integrate other services like MySQL, SQL Database, Caching, CDN, and Storage.
manage websites by using the API, Windows PowerShell, and Xplat-CLI
Service Management REST API Reference
Using Azure Traffic Manager with Azure Web Sites
Azure Traffic Manager (ATM) is a DNS-based service for managing traffic to Azure services, and it’s
recently been made available to Web Sites users. You can use ATM to:
Route visitors to your site to a region that will provide the best performance.
Automatically route traffic to a secondary region if there is a problem in the primary region
where your site is hosted.
Spread load evenly across multiple copies of your website hosted in multiple regions.
In order to use ATM with Web Sites, you will need to have two or more sites and each of them must be running in a different region. You can only add one website per region to ATM, so this requirement is important.
You must run your sites in Standard mode or Basic mode in order to use ATM with Web Sites.
ATM will route traffic based on a profile that you create.
Once you’ve created your ATM profile, you’ll want to add your endpoints.
ATM will use the path in the Monitoring Settings section to check the endpoints you configured. It performs that check once every 30 seconds, and only an HTTP 200 status is considered healthy. Therefore, if your application is designed in a way that causes a non-200 response to the root of the site (e.g. an ASP.NET forms authentication site that might return a 302 redirect to the login page), you’ll want to configure a path and file name for your ATM profile that points to an unprotected file so that a 200 response is returned.
Web Sites knows how to route the ATM URL to your site because it adds your ATM URL to the custom domains for your site automatically ie when you add endpoint in your ATM profile.
To use custom domain name first need to create a www CNAME entry at your domain registrar that points to your ATM URL
Note: Your subdomain may not be “www”. In that case, create a CNAME record for the subdomain you want to use.
Note: ATM is CNAME based and doesn’t support A records. Therefore, you can’t use a naked domain (mydomain.com) with ATM. It requires that you set up a CNAME record.
Load Balancing Methods
Performance – When this method is used, ATM will send users to the region where he or she
will get the best performance. This prevents situations where, for example, a user who is in the
Central US region is directed to a site running in West Europe.
Failover – This method will redirect traffic to a secondary region if there is a problem in the
primary region. For example, you may have a site in a “backup” region that doesn’t handle
any traffic unless your primary site is offline for some reason.
Round Robin – This method will evenly distribute traffic across the endpoints configured in
your ATM profile using a round robin load balancing methodology. You can use this method, for
example, to “ramp up” traffic to a particular endpoint without allowing it to receive all of your
traffic immediately. (In the future, ATM will include enhanced functionality to make this kind of
scenario even easier to configure.)
Install and Configure the Azure Cross-Platform Command-Line InterfaceThe Azure Cross-Platform Command-Line Interface (xplat-cli) provides a set of open source, cross-platform commands for working with the Azure Platform.
The xplat-cli is written in JavaScript, and requires Node.js. It is implemented using the Azure SDK for Node.js, and released under an Apache 2.0 license.