Many Azure resources use Azure Storage. When you create an Azure VM, for example, you store the VHD file in Azure Storage. Azure Storage accounts can hold a variety of data, with different mechanisms for managing each data type.
Additionally, the storage account provides both scalability and data durability and resiliency. Azure Storage manages five distinct types of data:
- Binary large object (blob)
- Table
- Queue
- File
- Disk
A blob is unstructured data that you store in Azure. Blob storage can hold any type of data in any form. This could include MP4 movies, ISO images, VHD drives, JPG files, and so on. Individual blobs reside within blob containers, which are equivalent to file store folders, but with very limited nesting capability.
Blobs come in three types: block blobs, append blobs, and page blobs. Block blobs are physically optimized for storing documents to the cloud and for streaming applications. Append blobs are optimized for append operations and are useful for logging. Page blobs are optimized for read/write operations—Azure VHDs, for example, are always of the page blob type. For more information about blob types, take a look at https://docs.microsoft.com/azure/storage/blobs/storage-blobs-introduction.
An Azure table is a non-relational storage system that utilizes key-value pairs. You can use Azure tables for storing unstructured or semi-structured data. This contrasts with an SQL table, which holds highly normalized data. A table consists of a grouping of entities. See https://azure.microsoft.com/services/storage/tables/ for more information about Azure table storage.
An Azure queue is a durable message queuing feature that's used to implement scalableapplications. With message queues, one part of an application can write a transaction to the queue for another part to process. A queue enables you to decouple applicationcomponents for independent scaling and to provide greater resiliency. For more details on Azure queues, see https://azure.microsoft.com/services/storage/queues/.
The Azure file feature provides simple cross-platform file storage that you can access using SMB. This enables you to create and use SMB file shares in the cloud and access them, just like you would access on-premises SMB shares. Azure files support SMB 2.1 and 3.0, which makes it simple and easy for you to migrate legacy applications that rely on file shares. For more information on Azure files, see https://azure.microsoft.com/services/storage/files/.
Azure's disk storage provides persistent, highly secure disk options, particularly for Azure VMs. Azure disks are designed for low latency and high throughput. You can provision both traditional spinning disks as well as SSD disks that provide better I/O performance for I/O intensive applications. For more details on Azure disk storage, see https://azure.microsoft.com/services/storage/disks/.
Storage features continue to evolve with more options available as time goes by. For more details on Azure storage as a whole, see https://docs.microsoft.com/azure/storage/common/storage-introduction.
As we noted earlier, you name your storage account based on a global naming scheme which is based on HTTPS URLs. The Azure REST API relies on URLs to manage the Azure resources in your resource groups. All storage accounts are named by specifying the storage account, data type, container name, and filename. The format for a blob is as follows:
https://<storageaccountname>.<datatype>.core.windows.net/...
Run this recipe on CL1, which you previously configured via the Using PowerShell with Azure recipe.
- Define key variables:
$Locname = 'uksouth' # location name $RgName = 'packt_rg' # resource group we are using $SAName = 'packt42sa' # Storage account name $CName = 'packtcontainer' $CName2 = 'packtcontainer2'
- Log in to your Azure account:
$CredAz = Get-Credential Login-AzAccount -Credential $CredAz
- Ensure that the Resource Group and the Storage Account have been created:
$RGHT = @{ Name = $RgName ErrorAction = 'SilentlyContinue' } $RG = Get-AzResourceGroup @RGHT if (-not $RG) { $RGTag = [Ordered] @{Publisher='Packt'} $RGTag += @{Author='Thomas Lee'} $RGHT2 = @{ Name = $RgName Location = $Locname Tag = $RGTag } $RG = New-AzureRmResourceGroup @RGHT2 "RG $RgName created" } $SAHT = @{ Name = $SAName ResourceGroupName = $RgName ErrorAction = 'SilentlyContinue' } $SA = Get-AzStorageAccount @SAHT if (-not $SA) { $SATag = [Ordered] @{Publisher = 'Packt'} $SATag += @{Author = 'Thomas Lee'} $SAHT = @{ Name = $SAName ResourceGroupName = $RgName Location = $Locname Tag = $SATag SkuName = 'Standard_LRS' } $SA = New-AzStorageAccount @SAHT "SA $SAName created" } - Get and display the Storage Account key:
$SAKHT = @{ Name = $SAName ResourceGroupName = $RgName } $Sak = Get-AzStorageAccountKey @SAKHT $Sak - Extract the first key's password:
$Key = ($Sak | Select-Object -First 1).Value
- Get and view the Storage Account Context, which encapsulates credentials for the storage account:
$SCHT = @{ StorageAccountName = $SAName StorageAccountKey = $Key } $SACon = New-AzStorageContext @SCHT $SACon - Create two blob containers:
$CHT = @{ Context = $SACon Permission = 'Blob' } New-AzStorageContainer -Name $CName @CHT New-AzStorageContainer -Name $CName2 @CHT - View the blob container:
Get-AzStorageContainer -Context $SACon | Select-Object -ExpandProperty CloudBlobContainer
- Create a very small blob in Azure:
'This is a small Azure blob!!' | Out-File .azurefile.txt $BHT = @{ Context = $SACon File = '.azurefile.txt' Container = $CName } $Blob = Set-AzStorageBlobContent @BHT $Blob - Construct and display the blob name:
$BlobUrl = "$($Blob.Context.BlobEndPoint)$CName/$($Blob.name)" $BlobUrl
- View the URL via IE:
$IE = New-Object -ComObject InterNetExplorer.Application $IE.Navigate2($BlobUrl) $IE.Visible = $true
In step 1, you defined the key variables that are used in the recipe and, in step 2, you logged in to your Azure account. These two steps produce no output.
In step 3, you ensured that the Resource Group and Storage Account were created and created them if not. Assuming you completed the previous recipe, Creating core Azure resources, this step produces no output. A message indicating that the resource group and/or storage account were not found and were created is issued if the resources were not found.
In step 4, you gathered and displayed the storage account key, which looks like this:
In step 5, you extracted the password from the first storage account key, which produces no output. Using that password, in step 6, you created and displayed the Storage Account context, which looks like this:
In step 7, you used the Storage Account Context (which encapsulates the credentials) to create two Azure blob containers, as follows:
In step 8, you viewed the two new blob containers, as follows:
In step 9, you created a new Azure blob by using the Set-AzStorageBlobContent cmdlet. The output looks like this:
In step 10, you generated a URL for this blob, as follows:
In step 11, you viewed the blob's content using Internet Explorer, as follows:
In step 4, you retrieved the Storage Account keys for your Storage Account. Each key's value property is, in effect, a password for your Azure storage account. Having two keys enables you to regularly regenerate and rotate your key values. In step 5, you got this value for the first key.
In step 6, you got the storage account's storage context. This object encapsulates the details of the storage account, including the storage account key you created in the prior step.
In step 7 and step 8, you created two blob containers and displayed their URLs. Containers are a single-level, folder-like object that contains your blobs. In step 9, you created a simple blob and, as you can see from the output, this is a block blob, with the content just comprising an octet stream.