Skip to content

Latest commit

 

History

History
61 lines (36 loc) · 3.49 KB

creating-new-modules.adoc

File metadata and controls

61 lines (36 loc) · 3.49 KB

Creating new modules

The toolkit is fundamentally based on standard Azure Resource Manager templates. For details on creating these templates, consult the guide for creating Azure Resource Manager templates.

However, the toolkit provides two features that are not available in Resource Manager templates:

  • The ability to capture values generated by the output of previous deployments and pass them to new deployments.

  • The ability to pull values from an archetype configuration file, for a shared services or workspace and use those values in a number of individual resource deployment tasks.

Integrating new resource deployments into the toolkit

New types of resources can be integrated into the toolkits by creating new modules. These modules can then be used in new archetypes.

File and folder structure

Modules are defined in the modules folder. Each module is a subfolder underneath modules containing Resource Manager deployment templates, parameters files, and (optionally) policy definitions.

The name of the subfolder for a module is used as its ID elsewhere in the toolkit. The files in the module always have the same name:

  • azureDeploy.json for deployment templates.

  • azureDeploy.parameters.json for parameters.

  • arm.policies.json for policies.

In addition, there are subfolders within each module folder for specifying the version of the of module.

For example, if you were creating a new module to create a Hadoop server, you could use the following file paths:

  • modules/hadoop/v1/azureDeploy.json

  • modules/hadoop/v1/azureDeploy.parameters.json

In this example, hadoop is the module ID and v1 is the version of the module.

Using the output of dependent resource deployments

If a module’s templates have outputs defined (using standard Resource Manager template format), the orchestration engine saves these outputs to a shared storage location (storage account). Other modules can integrate these outputs if they’ve defined a dependency.

These outputs need to be defined as parameters in the dependent module’s Resource Manager template. For instance, the la module generates the following output values:

  • oms-id

  • oms-workspace-resourceGroup

  • oms-workspace-name

In addition, dependencies must also be defined in the archetype configuration file where the modules are reference. This includes any items it uses in the parameter definitions of a module’s template.

When a module is processed by the orchestration engine, the output variables from previous deployments are pulled from the shared storage location and integrated with the parameters file for the new deployment. In turn this new deployment creates its own output in shared storage that can be used by later deployments.

Referencing global parameters

In a module’s parameters file, the toolkit allows you to make use of values defined in the archetype configuration file. This is done by referencing the global value using the following format: ${parameter JSON variable}

For example, in a module’s parameters file you can pull the organization name and shared services deployment name from an archetype configuration file into a deployment-prefix parameter value like this:

"deployment-prefix": {
       "value": "${general.organizationName}-${shared-services.deployment-name}"
   },

Next steps