Windows Azure SQL Database Marketplace
Editor's Note: This post comes from Daria Grigoriu, Program Manager on the Windows Azure Web Sites team, and Windows Azure Web Sites Developer Experience partners.
The Windows Azure Web Sites (WAWS) team passionately invests in a support model for development stacks that allows your web apps to start running quickly and gives your web apps room to grow. This blog article captures a few basic principles we use for versioning and extensibility of development stacks and how these principles apply to your web apps.
We currently support .NET, PHP, Node.js, and Python stacks. The Windows Azure development center at http://www.windowsazure.com/en-us/develop provides a great knowledge base for each of these. Once you create a website you can just upload your content and we will get it running with minimal information input from you.
Some development stacks we support such as PHP are designed to enable side by side versions. For these development stacks we provide a set of current versions that have been validated for our platform. We also establish a default so no input is required unless you prefer a specific version for compatibility reasons.
Other development stacks such as .NET are designed to provide in-place upgradeof some versions (e.g. .NET 4.5). We do our best to keep up with the rapid changes in the world of development stacks and update our support for newer versions as soon as we can.
.A summary of versions available with WAWS for each supported development stack and the respective version defaults is available at this link: https://github.com/projectkudu/kudu/wiki/Azure-Web-Sites-Development-Stacks.
We support extensibility points provided by each development stack in case you may need to customize.
The .NET framework is deeply integrated with the WAWS platform.
Configuration can be specified using the web.config file. The apphost.config file some developers may be accustomed to using is not directly editable with WAWS, but it can be modified by using XML Document Transformation (XDT) declarations. Some settings in apphost.config such as default documents are also available to edit in the web site’s CONFIGURE tab via Azure portal.
Bin-deployable components like MVC or Web Pages can be added to your web application folder.
The following are the main configuration files relevant for a Node.js application deployed on WAWS:
This is a Node.js specific configuration file that is relevant cross-platform. Example usages include specifying Node.js module dependencies (such as Express.js), and the runtime version number.
This is a configuration file used by the iisnode custom IIS modules specific. Example usages include specifying the command for starting node.exe, the number of node.exe processes that iisnode will create, and logging configuration.
This is an IIS configuration file used by the WAWS platform. This file captures the required handler registration, and allows the use of URL rewriting for performance optimization of static files use.
You can select any of the Node.js versions included with the WAWS platform, or you can upload and configure a custom Node.js runtime. Instructions are available via Windows Azure Developer Center at http://www.windowsazure.com/en-us/develop/nodejs/common-tasks/specifying-a-node-version.
The main configuration file relevant for a PHP application deployed on WAWS is the standard PHP .user.ini file. This file can be used to set changeable PHP directives such as display_errors for diagnostic.
WAWS supports a set of core PECL extensions by default. We also welcome custom extensions. To enable a custom extension bring the DLL under the FTP root and add a PHP_EXTENSIONS app setting under the CONFIGURE tab with the value set to the location (relative to your application root) of your PHP extensions.
Runtime Version and Customization
Version selection is available on access to the website’s CONFIGURE tab via the Azure portal.
Custom FastCGI-based PHP development stacks are also supported with WAWS. Upload a development stack under the website root. Access the CONFIGURE tab of the website and associate the new script processor (usually php-cgi.exe) with the *.php extension. An absolute path is needed for the script processor: e.g. D:\home\site\wwwroot\php5.5\php-cgi.exe where D:\home\site\wwwroot is used to refer to the site root.
The main configuration file relevant for a Python application deployed on WAWS is web.config. This file captures the required handler registration, and allows the use of URL rewriting for performance optimization of static files use. The use of a web.config file is optional, handler mappings can also be specified via the CONFIGURE tab in the Azure portal. More information is available via Windows Azure Developer Center at http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-configuration.
Some configuration options can be updated via App Settings under the same CONFIGURE tab in the Azure portal:
The value specified here needs to be a module/package name, followed by the attribute in the module to be used - e.g. mypackage.mymodule.handler (add parenthesis to indicate that the attribute should be called).
By default this refers to all *.py and *.config files: .*((\\.py)|(\\.config))$
You can add packages to your deployment by including under application root and configuring the PYTHONPATH via web.config or App Settings. Virtualenv is not currently supported with WAWS.
To support deployment of arbitrary packages first create a directory for storing the packages under website root. This is similar to having a site-packages directory in your Python lib folder, but it is located within your web application and is deployed to Windows Azure Websites. Copy packages to this new directory, and add the absolute path to this directory to PYTHONPATH in web.config (e.g. D:\home\site\wwwroot\my-packages). Now the packages will be available for importing from within the web application.
One example of this would be including Django within your application. You would first download or install Django into an existing Python installation. Next you would copy the Django package (typically a folder called django with an __init__.py file in it) into a directory in your application. By default your application root is included in the list of directories searched for packages. If you’d like to include it in a subdirectory (for example mypackages\django) you can add the parent directory to PYTHONPATH in web.config – in this case it would be D:\home\site\wwwroot\mypackages.
More information is available via Windows Azure Developer Center at http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-with-django.
We welcome custom FastCGI-based Python development stacks. You can upload your custom development stack under the website root and configure the website handler mapping to include the absolute path to your FastCGI based script processor.
We always appreciate feedback, let us know how to better support your development stacks needs via Forums Feedback.