All about Blueprints
Just as a blueprint allows an engineer or an architect to sketch a project’s design parameters, Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand up new environments with trust they’re building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery.
Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:
- Role Assignments
- Policy Assignments
- Azure Resource Manager templates (ARM templates)
- Resource Groups
A blueprint is made up of artifacts
Azure Blueprints currently supports the following resources as artifacts:
|Resource Groups||Subscription||Create a new resource group for use by other artifacts within the blueprint. These placeholder resource groups enable you to organize resources exactly the way you want them structured and provides a scope limiter for included policy and role assignment artifacts and ARM templates.|
|ARM templates||Subscription, Resource Group||Templates, including nested and linked templates, are used to compose complex environments. Example environments: a SharePoint farm, Azure Automation State Configuration, or a Log Analytics workspace.|
|Policy Assignment||Subscription, Resource Group||Allows assignment of a policy or initiative to the subscription the blueprint is assigned to. The policy or initiative must be within the scope of the blueprint definition location. If the policy or initiative has parameters, these parameters are assigned at creation of the blueprint or during blueprint assignment.|
|Role Assignment||Subscription, Resource Group||Add an existing user or group to a built-in role to make sure the right people always have the right access to your resources. Role assignments can be defined for the entire subscription or nested to a specific resource group included in the blueprint.|
When creating a blueprint definition, you’ll define where the blueprint is saved. Blueprints can be saved to a management group or subscription that you have Contributor access to. If the location is a management group, the blueprint is available to assign to any child subscription of that management group.
Blueprint Usage Workflow
When a blueprint is first created, it’s considered to be in Draft mode. When it’s ready to be assigned, it needs to be Published. Publishing requires defining a Version string (letters, numbers, and hyphens with a max length of 20 characters) along with optional Change notes. The Version differentiates it from future changes to the same blueprint and allows each version to be assigned. This versioning also means different Versions of the same blueprint can be assigned to the same subscription. When additional changes are made to the blueprint, the Published Version still exists, as do the Unpublished changes. Once the changes are complete, the updated blueprint is Published with a new and unique Version and can now also be assigned.
Each Published Version of a blueprint can be assigned (with a max name length of 90 characters) to an existing subscription. In the portal, the blueprint defaults the Version to the one Published most recently. If there are artifact parameters (or blueprint parameters), then the parameters are defined during the assignment process.
Creating and managing your blueprint
The structure of a Blueprint
Importing your blueprint into Azure :
Import-AzBlueprintWithArtifact -Name '[your blueprint name]' \ -SubscriptionId '[your subscription id]' \ -InputPath '[path to your blueprint code]' \ -IncludeSubFolders
Exporting your blueprint:
$bpDefinition = Get-AzBlueprint -SubscriptionId [your subscription id] \ -Name '[your blueprint name]' Export-AzBlueprintWithArtifact -Blueprint $bpDefinition \ -OutputPath '[path to save the blueprint to]'