Reputation: 10075
tl;dr
How do I programmatically drill down from an instance of an Azure Image Builder template build to find the customization.log
file for the build?
Long version
I've recently started working with Azure Image Builder, and after a fashion I've got a CI pipeline working to deploy and build image templates from files in a source repo into a Shared Image Gallery.
At the end of my build process I'd like to retrieve the packerlogs\<guid>\customization.log
file generated by Azure Image Builder - I can find it fine by clicking around in the portal (see screenshot below), but I'm struggling to follow any sort of breadbrumb trail to locate the blob programmatically.
Maybe there's a really simple way to do this, and I'm making a massive pigs ear of it, but here's what I've got so far:
During the build process, Azure Image Builder creates a temporary resource group called IT_<gallery-resource-group-name>_<image-template-name>_<guid>
where it stores the customization logs. This also has the following tags that can be used to find the right resource group:
"createdBy" = "AzureVMImageBuilder"
"imageTemplateResourceGroupName" = "<shared image gallery resource group name>"
"imageTemplateName" = "<image template name>"
In the temporary resource group there's a single Storage Account with a 24-character random name - e.g. abc123def456ghi789j01234
In the storage account there's a container called packerlogs
And in the storage account container, some blobs live, in the format <guid>\customization.log
.
Having got that far, I don't know which <guid>
to use to filter the results for a specific build instance. I can use the timestamp to read the latest one, but how do I know that's the right one for any given build of my image template. For example which <guid>
belongs to the build process for image version 1.0.55 of my image template?
This is the code I've got so far:
# this is my starting point - I've got an image template that I've built using Start-AzImageBuilderTemplate
# and it's successfully created a new image version in a shared image gallery
$myImageGallery = ...
$myImageDefinition = ...
$myImageTemplate = ...
$myImageVersion = ...
# find the temporary resource group with the appropriate tags for the image template
$temporaryResourceGroup = Get-AzResourceGroup -Tag @{ "createdBy" = "AzureVMImageBuilder" } `
| where-object {
($_.Tags.imageTemplateResourceGroupName -eq $myImageGallery.ResourceGroupName) -and
($_.Tags.imageTemplateName -eq $myImageTemplate.Name)
};
# get a reference to the single storage account in the resource group
$storageAccount = Get-AzResource -ResourceGroupName $temporaryResourceGroup.ResourceGroupName `
-ResourceType "Microsoft.Storage/storageAccounts";
# find the "packerlogs" container
$storageKey = ($storageAccount | Get-AzStorageAccountKey)[0].Value
$context = New-AzStorageContext -StorageAccountName $storageAccount.Name -StorageAccountKey $storageKey
$packerlogs = Get-AzStorageContainer -Context $context -Name "packerlogs";
# get the list of blobs that represent the customization logs from each of the individual template builds
$blobs = Get-AzStorageBlob -Context $context -Container $packerlogs.Name -Blob "*/customization.log";
# but which blob do I want for $myImageVersion?
Upvotes: 1
Views: 1023
Reputation: 1
In the published version of the image in the compute gallery, there is an Azure tag called the 'correlationid'. The tag value can be used to reference back to the blob in the storage account under the packerlogs container: packerlogs\$correlationid\customization.log.
Upvotes: 0
Reputation: 10075
In the end, I now delete and recreate the image template every time I use it to build a new image version.
This causes the temporary resource group to get deleted and recreated as well, so there’s only ever one folder under the packerlogs container at the end of the build process.
The result is that Get-AzStorageBlob -Context $context -Container $packerlogs.Name -Blob "*/customization.log"
only returns one blob, and I can safely(?) assume that’s the one for my build.
It seems like a bit of a leap of faith, but I can’t see any other reliable way to correlate a build instance to the relevant folder under the packer logs container, so it’ll have to do for now...
Upvotes: 3