azureaccelerators Wiki Rss Feed

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Windows Azure deployments of Umbraco using pre-configured virtual hard drive (cloud-drive) images. Enables the migration from on-premise to the cloud of application images, accelerator solution engine and associated service configurations. Provides for the migration of local Microsoft SQL Server or SQL Express database schema and content to SQL Azure; including the creation of accounts and logins necessary to enable, set or reset connetivty between the hosted service and SQL azure database.

A full working reference example of Umbraco as an image, with a corresponding exported SQL schema is included. To get started, unzip the package, update the ServiceConfiguration.cscfg with settings for your Azure services, and then run the SetupUmbraco.bat file.

For more information about where to source the settings, and an overall view of what actions are automated, please see the rapid deployment diagram and checklist files. (Also included in the package download.)

Zero-Code Cloud Migrations

The Azure Accelerator engine provides for the graceful migration of Windows Platform services to the Windows Azure cloud. Offloading legacy and non-core applications and services, from in-house servers and datacenters, in a zero-touch, application-agnostic set of solutions applied using application and service specific XML definitions. Once a solution is implemented for a given scenario (eg. mounting drives, changing app pipleine, add PHP to IIS, etc) it can thereafter be leveraged by any service or application which may require it.

Applications and services are not limited to web sites, or single self-contained services. The accelerator provides for the deployment complexities and application inter-dependencies which are common, and are often requirements, for the platform migration to be successful. The engine provides for the defintion of applications, provisioning of platform services, and the further specification of those applications and their inter-dependencies on other services or plaform resources being started by the Accelerator. The XML definitions for any application may be refined and split to accomodate differences amongst application versions. (The Umbraco solution leverages two separate application definitions--one for each major legacy version--with the only notable, yet critical, difference being their HWC application pipeline requirements).

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is deterministic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 22:16:19 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

Slalom's Azure Accelerator provides for the graceful migration of Windows Platform services to the Windows Azure cloud. Offloading legacy and non-core applications and services, from in-house servers and datacenters, in a zero-touch, application-agnostic set of solutions applied using application and service specific XML definitions. Once a solution is implemented for a given scenario (eg. mounting drives, changing app pipleine, add PHP to IIS, etc) it can thereafter be leveraged by any service or application which may require it.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 21:58:42 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is determininstic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 21:51:22 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

Applications and services are not limited to web sites, or single self-contained services. The accelerator provides for the complexities and deployment of interdependant arraies of services which all must be present for the platform migration to be successful. The engine provides for the defintion of applications, provisionion of platform services, with an application itself being a dependency or depending on other services being resourced and started by the Accelerator. The XML definitions for any application may be refined and split to accomodate differences amongst application versions, or specific application version interdepencies. (Umbraco, for example, has 2 application definitions, one for each major legacy version, with the only notable, yet critical, difference being their HWC application pipeline requirements).

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is determininstic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 21:35:34 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

Applications and services are not limited to web sites, or single self-contained services. The acclerator provides for the complexities and deployment of interdependant arraies of services which all must be present for the platform migration to be successful. The engine provides for the defintion of applications, provisionion of platform services, with an application itself being a dependency or depending on other services being resourced and started by the Accelerator. The XML definitions for any application may be refined and split to accomodate differences amongst application versions, or specific application version interdepencies. (Umbraco, for example, has 2 application definitions, one for each major legacy version, with the only notable, yet critical, difference being their HWC application pipeline requirements).

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is determininstic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 21:28:57 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

Slalom's Azure Accelerator provides for the graceful migration of Windows Platform services to the Windows Azure cloud. Offloading legacy and non-core applications and services, from in-house servers and datacenters, in a zero-touch, application-agnostic set of solutions applied using application and service specific XML definitions. Once we have implemented a solution for a given scenario (eg. mounting drives, changing app pipleine, add PHP to IIS, etc) it can thereafter be leveraged by any service or application which may require it. This becomes a zero-touch, application agnostic solution to a general class of migration possibilities, thereafter applied though application and service specific XML definitions.

The acclerator targets may also require orchestration between an array of services which all must be present for the platform migration to be successful. The engine provides for the defintion of applications, provisionion of platform services, with an application itself being a dependency or depending on other services being resourced and started by the Accelerator. The XML definitions for any application may be refined and split to accomodate differences amongst application versions, or specific application version interdepencies. (Umbraco, for example, has 2 application definitions, one for each major legacy version, with the only notable, yet critical, difference being their HWC application pipeline requirements).

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is determininstic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010-2011 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 21:28:20 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Zero-Code Cloud Migrations

Slalom's Azure Accelerator provides for the graceful migration of Windows Platform services to the Windows Azure cloud. Offloading legacy and non-core applications and services, from in-house servers and datacenters, in a zero-touch, application-agnostic set of solutions applied using application and service specific XML definitions. Once we have implemented a solution for a given scenario (eg. mounting drives, changing app pipleine, add PHP to IIS, etc) it can thereafter be leveraged by any service or application which may require it. This becomes a zero-touch, application agnostic solution to a general class of migration possibilities, thereafter applied though application and service specific XML definitions.

The Accelerator application XML definitions are composable and inheritable. Most of the .NET definitions are currently IIS-based and inherit from either my base IIS 7.5 definition and/or the WPI definition (when rolling out multiple different services under the same instance). Each application may override their dependant and descendant applications, or, more commonly, enhance and extend those applications with their own Azure requirements—adding specific virtual directories, applications, php-requirements, application pools, etc, etc., Another example from my JAMP definitons, is that many inherit a Java runtime version, which mounts a cloud drive, verifies binaries, establishes environement variables and passess all of that information to its parent application for use in their own dependency and startup orchestration. These applications commonly also inheirt either the Apache and PHP child definitions, or the Tomcat service defintion (eg. Django and Gallery-via-Apache, inherit Java, Apache and PHP definitions.). The accelerator engine processes these dependency trees, and provisions all of their required Azure and platform resources, configuration file and system changes, prior to starting the runtime orchestration and startup of the processes and web servers. The runtime is determininstic with blocking, nonblocking, and timed spin up of components.

Its definable and composable in XML. Code once, use and reuse everywhere.

Ryan D. Marshall

Copyright @ 2010 Slalom Consulting

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 19:47:54 GMT

THE WINDOWS AZURE ACCELERATORS PROJECT

The Azure Accelerators Project abstracts the common resource provisioning and configuration requirements of applications as independent XML definitions. It is an engine which orchestrates the startup, runtime and tear-down of applications hosted on the Windows Azure platform.

Accelerators Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment

Windows Azure deployments of Umbraco using a pre-configured image of Umbraco, service config and engine binaries.

Ryan D. Marshall

Updated Wiki: Documentation

ryanmar — Tue, 18 Jan 2011 19:41:15 GMT

The Accelerators Project Documentation

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment Scripts

Windows Azure deployments of Umbraco using a pre-configured image of Umbraco, service config and engine binaries.

Application Definition Schema

XML Schema notes for the application definition elements. The functionality enables the zero-touch, definition-only, deployment of non-Azure aware Windows Server services to Windows Azure. (.NET / IIS / Java / Native / NT Services / etc. )

Element					Attribute	Variable	Required	DataType	Description
application					name	yes	yes	string	Name of the application.
					version	no	yes	string	Version of the application. (Combined with name attribute must be globally unique.)
					description	no	no	string	Optional description for this application configuration section.
	params								Key value pairs with explicit values or cscfg setting names; inherits existing params/variable values.
		param			key	no	yes	string	Global key by which to refer to this variable's value in engine configuration elements.
		param			value	yes	no	string	Variable value; may contain other variable keys; ignored (inherited) if already defined.
	variables								Key value pairs with explicit values or cscfg setting names; overrides inherited params/variables.
		variable			key	no	yes	string	Global key by which to refer to this variables value in engine configuration elements.
		variable			value	yes	no	string	Explicit values; may contain other variable keys; overrides ancestor params/variables.
	dependencies								Defines all application and environment resources required by this application.
		applications							Specifies any other application dependencies for this application. (IIS, Java, etc)
			application		name	no	yes	string	Name of the dependant application (definition) to load.
			application		version	no	yes	string	Version of the dependant application (definition) to load.
		localResources							Defines the Azure resources required by this application.
			localStorage		configurationResourceName	yes	yes	string	Name of the local storage resource in the Azure csdef file.
					pathKey	yes	yes	string	Variable to store and reference this local storage resource's runtime path.
					maximumSizeKey	yes	yes	string	Variable to store and reference the maximum storage size (as provisioned at runtime).
			endPoint		configurationEndPointName	yes	yes	string	Name of the end-point resource in the Azure csdef file.
					portKey	yes	no	string	Variable to store and reference this end-point's runtime port number.
					addressKey	yes	no	string	Variable to store and reference this end-point's runtime IP address.
			cloudDrive		connectionString	yes	yes	string	Name of the connection string in the Azure cscfg file for connecting to Azure Storage Services.
					pageBlobUri	yes	yes	string	Virtual path to the cloud drive's pageblob. (Container name and resource path to mount).
					pathKey	yes	yes	string	Variable to store and reference this cloud drive's runtime path (mounted drive letter).
					cacheSize	yes	yes	integer	Local storage cache size for this cloud drive.
					createIfNotExists	yes	no	boolean	If true, create a new cloud drive at the storage location (and mount) if one does not already exist.
					copyBlob	yes	no	boolean	If true, create a snapshot of blob and mount that new instance.
					readOnly	yes	no	boolean	If true, mount the cloud drive as read-only.
			containerSync		blobContainer	yes	yes	string	Virtual path to container location.
					connectionString	yes	yes	string	Name of the connection string in the Azure cscfg file for connecting to Azure Storage Services.
					localPath	yes	yes	string	Local folder's root path (in Azure) corresponding to the blob container's root path.
					ignoreAdditionalFiles	yes	no	boolean	True to ignore any files in the target which to not exist in the source; false to delete files.
					direction	yes	no	Enum	Direction of file and folder to blob storage synchronization. Valid values are 'Download', 'Upload'.
					intervalInSeconds	yes	no	integer	Synchronization interval. If ommited, or 0 (zero), a one-time folder sync will occur at application start.
			localCache		source	yes	no	string	Source cache, cloud-drive or local storage path (or file) in Azure from which to copy file(s)/folder(s).
			localCache		destination	yes	no	string	Target cloud-drive or local storage path (or file) for the copied file(s)/folder(s).
		validation							Specifies provisioned resource validation and constraints on application startup.
			fileValidation		path	yes	yes	string	A local cache, cloud-drive or storage location path for validation.
					checkAccess	yes	no	boolean	True to log all file/folder attributes and validate user access perssions.
					required	yes	no	boolean	True to require file existence before allowing startup to continue; false to log and continue.
	configuration								Defines required environment and application runtime configuration changes.
		files							Specifies the files and actions required to update with Azure runtime settings.
			file		path	yes	yes	string	Location of the configuration file to update with runtime configuration.
			file		logging	yes	no	boolean	If true, logs the entire contents of the modified file; if false logs only success status (not entire file).
				regex	pattern	*	yes	string	The regex pattern to match.
					replacement	*	yes	string	The replacement pattern to use for each regex match.
					evalVariablesInPattern	yes	no	boolean	If true, resolves accelerator variables in pattern string prior to use; if false, uses pattern as is.
					evalVariablesInReplacement	yes	no	boolean	If true, resolves accelerator variables in replacement; if false, applies replacement string as is.
					evalVariablesInMatch	yes	no	boolean	If true, resolves accelerator variables in matched patterns.
					replacePathChar	yes	no	char	True to replace all instances of \ with the specified char.
				replace	pattern	*	yes	string	The string pattern to match.
					replacement	*	yes	string	The string to use in place of any pattern match.
					evalVariablesInPattern	yes	no	boolean	If true, resolves accelerator variables in pattern string prior to use; if false, uses pattern as is.
					evalVariablesInReplacement	yes	no	boolean	If true, resolves accelerator variables in replacement; if false, applies replacement string as is.
					replacePathChar	yes	no	char	True to replace all instances of \ with the specified char.
				append	pattern	*	yes	string	The string to append to the file.
				append	evalVariablesInPattern	yes	no	boolean	If true, resolves accelerator variables in pattern string prior to use; if false, uses pattern as is.
		environmentVariables							Provides for the creation or modification of system environment variable settings.
			environmentVariable		name	yes	yes	string	The name of the system environment variable.
					value	yes	yes	string	The value to assign to the environment variable.
					replacePathChar	yes	no	char	True to replace all instances of \ with the supplied char.
					evalInReplacement	yes	no	boolean	True to evaluate any environment variables in value string; false to assign without eval.
	runtime								Provides for the graceful startup, maintanance and shutdown of component processes.
		onStart							Provides for the applications startup process sequence.
			process		processKey	yes	yes	string	The name for tracking the process (tracing, termination, monitoring, etc).
					workingDir	yes	no	string	Working directory for process startup.
					command	yes	yes	string	Command portion of the process (full path to exe, cmd, bat, com or any registered filetype).
					args	yes	no	string	Argument portion of the application command line.
					waitOnExit	yes	no	boolean	Will wait for process termination before continuing to process additional onStart elements.
					waitTimeoutInSeconds	yes	no	integer	Maximum time to wait in seconds.
					delayContinueInSeconds	yes	no	integer	Delay after process start; prior to continuing to process additional onStart elements.
			webServer		isPhpEnabled	yes	no	string	If true, IIS will be configured to support PHP; otherwise it will not be available.
					enableClassicPipelineMode	yes	no	string	If true, IIS will run in using Classic ASP.NET pipeline mode; otherwise it will run in Integreated.
					runtimeConfigDirectory	yes	no	string	The directory in which to place the runtime web.config and appHost.config
					aspNetTempDirectory	yes	no	string	Directory for storing asp.net temporary files.
					iisCacheDirectory	yes	no	string	Directory for storing IIS cache files.
					logsDirectory	yes	no	string	Directory for storing log files generated by hosted IIS.
					failedReqLogsDirectory	yes	no	string	Directory for storing failed request logs.
					sourceAppHostPath	yes	no	string	Path to the applicationHost.config template file.
					sourceWebConfigPath	yes	no	string	Path to the web.config template file.
					machineKey	yes	no	element	Fully encoded ASP.NET 2.0 machine key.
				application	applicationPath	yes	yes	string	Directory of an application root within the hosted web site.
					virtualDirectory	yes	yes	string	Virtual directory of the application within the hsoted web site.
					physicalPath	yes	yes	string	Local physical storage path of the application (may be cloud drive or local storage based).
				binding	protocal	yes	yes	string	Protocol to which the IIS server should bind.
					port	yes	yes	integer	Port to which the IIS server should bind.
					address	yes	no	string	IP Address to which the IIS server should bind.
					host	yes	no	string	Hostname to which IIS should bind.
		onRunning							Provides for interval processing while Azure instance it running (moving logs, clearing files, etc)
			timer		name	yes	no	string	Name by which the timer will be referred in log entries.
			timer		intervalInSeconds	yes	no	string	Interval on which all definted timer processes will be executed.
				process	processKey	yes	yes	string	The name for tracking the process (tracing, termination, monitoring, etc).
					workingDir	yes	no	string	Working directory for process startup.
					command	yes	yes	string	Command portion of the process (full path to exe, cmd, bat, com or any registered filetype).
					args	yes	no	string	Argument portion of the application command line.
					waitOnExit	yes	no	boolean	Will wait for process termination before continuing to process additional onStart elements.
					waitTimeoutInSeconds	yes	no	integer	Maximum time to wait in seconds.
					delayContinueInSeconds	yes	no	integer	Delay after process start; prior to continuing to process additional onStart elements.
		onStop							Provides application and service graceful tear-down.
			process		processKey	yes	yes	string	The name for tracking the process (tracing, termination, monitoring, etc).
					workingDir	yes	no	string	Working directory for process startup.
					command	yes	yes	string	Command portion of the process (full path to exe, cmd, bat, com or any registered filetype).
					args	yes	no	string	Argument portion of the application command line.
					waitOnExit	yes	no	boolean	Will wait for process termination before continuing to process additional onStart elements.
					waitTimeoutInSeconds	yes	no	integer	Maximum time to wait in seconds.
					delayContinueInSeconds	yes	no	integer	Delay after process start; prior to continuing to process additional onStart elements.

Updated Wiki: Home

ryanmar — Tue, 18 Jan 2011 19:26:59 GMT

THE AZURE ACCELERATORS PROJECT

DOCUMENTATION

Umbraco Configuration & Application Definitions Guide

Umbrao Rapid Deployment Scripts

Windows Azure deployments of Umbraco using a pre-configured image of Umbraco, service config and engine binaries.

Umbraco Rapid Deployment Diagram

Umbraco Rapid Deployment Checklist

Updated Wiki: Documentation

ryanmar — Tue, 18 Jan 2011 19:26:13 GMT

The Accelerators Project Documentation