Azure blueprint - how to handle with ARM parameter file?

Problem statement

When you deploy an ARM template, it's normal to provide a parameter file, in which you can put custom values for parameters used during the ARM template deployment. When you add an artifact of ARM deployment into a blueprint, unluckily you can't use a parameter file on Azure Portal - there is just no field on UI for you to specify a parameter file as shown on the below screenshot.


But alternatively you can use a command line to add an artifact of ARM template deployment to a blueprint, which allows you to specify a parameter file! E.g. using the below PowerShell command to insert an ARM template deployment of a Log Analytics workspace. 
$bpDefinition = Get-AzBlueprint -SubscriptionId '<sub Id>' -Name '<blueprint name>' -Version '<blueprint version number>'

New-AzBlueprintArtifact -Blueprint $bpDefinition -Type TemplateArtifact -Name 'la-workspace' -TemplateFile .\la-workspace-deploy.json -TemplateParameterFile .\la-workspace-deploy.parameters.json -ResourceGroupName <resource group name>

Once the artifact is imported, you can go back to Azure portal, open that blueprint, and edit that artifact. Assuming in the original ARM template you don't provide default values to those parameters, but provide all values using the parameter file. Once it's imported, you can see that all values in the parameter file show up on the 'Edit artifact' page. 

Behind the scene, the importing does two things for you,

  • Copy those parameter declarations from the ARM template file into the Blueprint.json, by adding the artifact name as the prefix. So all those parameters are now declared on the blueprint level, and visible to other artifacts.
  • Copy values in the parameter file into the parameter section of the artifact file, la-workspace.json.

************Blueprint.json************
 
{
  "properties": {
    "targetScope": "subscription",
    "parameters": {
      "la-workspace_name": {
        "type": "string",
        "metadata": {
          "displayName": "name (la-workspace)",
        },
        "allowedValues": []
      },
      "la-workspace_location": {
        "type": "string",
        "metadata": {
          "displayName": "location (la-workspace)",
        },
        "allowedValues": []
      },
      "la-workspace_sku": {
        "type": "string",
        "metadata": {
          "displayName": "sku (la-workspace)",
        },
        "allowedValues": []
      },
      "la-workspace_tags": {
        "type": "array",
        "metadata": {
          "displayName": "tags (la-workspace)",
        },
        "allowedValues": []
      }
     },

************Artifacts/la-workspace.json************
{
  "kind": "template",
  "properties": {
    "displayName": "la-workspace",
    "description": "",
    "dependsOn": [],
    "template": {
        ……
    },
    "resourceGroup": "ResourceGroup",
    "parameters": {
        "name": {
            "value": "la-workspace-test-01"
        },
        "location": {
            "value": "westus"
        },
        "sku": {
            "value": "pergb2018"
        },
        "tags": {
            "value": {}
        }
     }
  }
}

Note on the above screenshot every parameter is followed by an option of "This value should be specified when the blueprint is assigned". If you check this option for all of them, the artifact file will be updated to,

***************Artifacts/la-workspace.json*************
{
  "kind": "template",
  "properties": {
    "displayName": "la-workspace",
    "description": "",
    "dependsOn": [],
    "template": {
        ……
    },
    "resourceGroup": "ResourceGroup",
    "parameters": {
        "name": {
            "value": "[parameters('la-workspace_name')]"
        },
        "location": {
            "value": "[parameters('la-workspace_location')]"
        },
        "sku": {
            "value": "[parameters('la-workspace_sku')]"
        },
        "tags": {
            "value": "[parameters('la-workspace_tags')]"
        }
     }
  }
}

You may already notice, once you save the changes on this blueprint, the values imported from the original parameter file are gone. When you assign this blueprint, since there is no default values for those parameters, you have to fill in values for all those parameters one by one, which is troublesome.

Good practice

Assuming you already have a parameter file for your ARM template deployment, and now import this ARM template into a blueprint. In order to use those values in the original parameter file when assigning a blueprint, instead of filling them in manually, you'd better set default values in the ARM template file as more as possible, instead of leaving them in the parameter file. The default value of a parameter will be automatically copied to the blueprint.json file when you import the ARM template into a blueprint, and then used as the default during the blueprint assignment.


Comments

Post a Comment

Popular posts from this blog

Deep-archive an aws S3 bucket with versioning enabled once

Image
It's not a surprise if you want to deep-achieve a S3 bucket, or some objects in it to decrease storage cost. But if versioning has once been enabled on the bucket, how to do the deep archiving needs more consideration.  Problem Statement If you have a S3 bucket, which versioning has never been enabled, then to move objects into Glacier Deep Archive can be achieved by iterating over every object, and  making a copy of an object using the  PUT Object - Copy  API.  You copy an object in the same bucket using the same key name and specify request headers, e.g. here you set  the   x-amz-storage-class   to the storage class,  ' DEEP_ARCHIVE',   that you want to use  [1]. Then the final effect is just like that the storage class of an object is being changed.  But if a bucket has once been versioning enabled, the above method is not straight forward. - If versioning is still enabled, even  you can copy an object with a specific version ID, Amazon S3 gives it a new version ID. The
Read more

Good practices of using Python logging

Problem Statement During the maintenance work of a legacy Python project, it's noticed some issues of logging code events. Outputs not in sequence The legacy code in some places still uses print() function, and traceback.print_exc() like below, try : #my logic goes here print ( "my output" ) except Exception : traceback . print_exc() By default in Python those functions are buffered. print() will send outputs to stdout, and traceback_print_exc() will send output to stderr. If those buffers are not flushed timely or disabled, the output may not in sequence which causes the outputs out of order.  Logging configuration not centralized and externalized It's noticed the logging configuration is added in every file using the Python logging. It means the logging configuration is not centralized and externalized for easy usage. Also when a message is logged, the 'logging' object is used directly instead of using a 'logger' object. The '
Read more

Auto-installing NVIDIA device plug-in on GPU nodes only

Problem Statement On a Kubernetes cluster before the GPUs in the nodes can be used, you need to deploy a DaemonSet for the NVIDIA device plugin. This DaemonSet runs a pod on each node to provide the required drivers for the GPUs. E.g. on Azure AKS cluster, here is the Azure official document regarding how to install NVIDIA device plug-in .  The YMAL manifest is in the nvidia-device-plugin-ds.yaml file. Once this file is applied, it does automatically run a pod to provide the required driver once a GPU node is added, no matter it's manually scaled or auto-scaled. But it may also run the pod on a node which has no GPUs at all, since that yaml manifest doesn't constraint the pods to run only on GPU nodes. This is a waste of resources on non-GPU nodes. Solution This is where " nodeSelector " and " affinity " can help. "nodeSelector" provides a very simple way to constrain pods to nodes with particular labels. The "affinity/anti-affinity" feat
Read more