How to put artifacts in template spec without being referenced in the template directly?

[slavizh]

How to put artifacts in template spec without being referenced in the template?

For example may be you have some artifacts that are not directly referenced in the template but you want them to be uploaded in the template spec so they can be referenced:

• license file for your solution (template spec)
• Windows server bitlocker dlls - Windows server core does not come with certain bitclocker DLLs so when you want to deploy server core on Azure and enable encryption you usually have some script that uploads certain DLLs on the VM so bitlocker can be enabled.

[alex-frankel]

This is related to #16 , but not exactly the same. We don't yet have a way to stage non-template artifacts (whether they are referenced directly or not). Are there scenarios where you need to package a template artifact that is not explicitly referenced?

[slavizh]

May be only the license file is artifact that will not be referenced but needs to be uploaded. With the bitlocker scenario the dlls will be referenced in the custom script extensions as files that needs to be uploaded to the Virtual Machine. Of course that is probably related to #16 you are mentioning. Of course we do not want to upload large files but small things like scripts, runbooks, DSC configuraitons, small DLLs, Azure Policy custom guest configurations, etc. These all should be possible. Overall these are critical for template spec usage for me/us as otherwise we have to divide certain solutions as template spectable and non-template spectable. My recommendation is to have some function or variable where you can reference these files and they be uploaded and of course a function to be able to reference those as URL in the corresponding resource. Certain limits of maximum number of files and maximum size can be set to avoid abuse of it.

[ChristopherGLewis]

I keep thinking that MS should start pushing Azure Instance Metadata (https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service) as the means to pass information into running deployment VMs.

We've been exploring this in a couple of our deployments where we set a "BuildInfo" tag with a hash table of parameters, then access that within the VM with a REST api call to 169.254.169.254

$meta = Invoke-WebRequest -UseBasicParsing -Headers @{"Metadata" = "true"} `
                         -Uri "http://169.254.169.254/metadata/instance?api-version=2019-11-01" 
$TagsList = ($meta.Content |ConvertFrom-Json).Compute.TagsList

If ($tagsList.name.Contains("BuildInfo")) {
    #Get build info into a PSCustomObject
    $BuildInfo = $tagsList.Where({$_.name -eq "BuildInfo" } ).value | ConvertFrom-Json

    #Get our build type
    $BuildType = GetBuildInfoParam  -BuildInfo $buildInfo -Parameter "BuildType"
    #Get a list of files to dowload 
    $DownloadList= GetBuildInfoParam  -BuildInfo $buildInfo -Parameter "DownloadList"
    $StorageURL= GetBuildInfoParam  -BuildInfo $buildInfo -Parameter "StorageURL"
    $StorageSAS= GetBuildInfoParam  -BuildInfo $buildInfo -Parameter "StorageSAS"
}

This is comparable to Cloud-init on the unix side and has such a huge benefit.

[slavizh]

@ChristopherGLewis Not sure what the above has something to do with this issue.

[slavizh]

One example is runbooks API: https://docs.microsoft.com/en-us/rest/api/automation/runbook/createorupdate. The runbooks needs to be uploaded to a web location as you can deploy them only via URI. Unfortunately it is a bummer that different resource implement this differently. For example deploymentScripts https://docs.microsoft.com/en-us/azure/templates/microsoft.resources/deploymentscripts?tabs=json has option to directly embed the script into the template but I doubt that runbooks will get such feature.