In a recent post about implementing Azure’s Application Insights in a webjob, I mentioned in passing the need to have a storage account in order to actually run the webjob. I didn’t cover then how to go about creating that because THAT post was already taking close to a minute and a half just to scroll…so here we are.
In addition to being a really convenient and relatively cheap way to store files “on the cloud,” Azure will require storage accounts to be associated with many resources (like webjobs, machine learning workspaces, and virtual machines) so those resources have a place to store their logs, temp files, another other such critical things.
What, you thought Microsoft would just foot the bill for that kinda thing, or build it into the resource price? Come on now.
While docs.microsoft has a really good explanation on the details behind storage accounts, their varieties, how pricing is determined, etc, they don’t actually walk you through it–probably because doing it through the portal is a really easy process. But if you’re anything like me, you appreciate a little handholding the first time you create something you’re paying money for.
Adding the Storage Account
From anywhere in the Azure portal, you click on the big green “Add Resource” button on the side bar, and then search for Storage Account. You’re going to want that second one, “Storage account — blob, file, table, queue.”
One of the things I really like about Azure is how easy it is to do things from the portal–look at this one-step wizard.
Most of these options are going to be dependent on your use case and/or resource organization plan. If you’re just experimenting, learning, or doing a rough draft 9.5/10 times the Azure’s suggested default is going to do you fine. If you’re here because of another walkthru on my blog, you’re 100% okay to accept the defaults without a care.
- Name: A common convention is the have at least one storage account for each resource group, and to have the names align using a naming convention. For instance, a resource group named “Development” may have a storage account named “DevStorage”
- Deployment Model: In general, if you have to ask to use “Option A” or “Classic” in Azure, you probably want “Option A” because Microsoft is working on shifting everything that direction. In this case, docs.microsoft has an article all about this choice
- Location: Again, touches on your use case and largely dependent on the physical location of customers (you wouldn’t store files in West US if they’re being accessed by a client on the East coast). A common thing is to group everything in a resource group in the same region, but you can read more into Azure’s region breakdown and decide for yourself
- Replication: Tired of me saying “it depends on your use case” yet? Fortunately, docs.microsoft has an article all about these options
- Performance: My feeling is you will know if you need a premium performance storage account or not, but just in case you’re in doubt docs.microsoft has a nice article on this too
- Secure transfer required: Again, I feel you know if your data needs to be passed to and from the storage account by HTTPS or not
- Subscription: The subscription this resource will be associated with/billed to–you’ll have to choose from the dropdown
- Resource Group: The resource group the storage account will be associated with–you can create a new one, or add it to an existing one as you see fit
Unless you’re doing something intense or in preview (in which case you’re likely no longer reading this post) this will cover all your bases. You can hit that create button.
As you can tell, there are some big-picture considerations to ponder if you’re trying to set one of these up as part of your production infrastructure. However, Azure is fairly forgiving in the sense you can always blow up a resource and make a new one if you choose poorly–don’t let a fear of getting it right stop you from getting started.
Access Keys/Connection Strings
Programmatic access to your storage account is absolutely the entire point of the storage account–and you cannot access the storage account programmatically without either an access key, or a connection string (which is really just the access key in a different format).
Two of them are generated at any given time, and you can manually regenerate them as needed (think any given security nightmare, from a major data breach to the intern making a repository public while a connection string is still in the App.config file).
You find these bad boys through the side bar, under the *gasp* Access Keys blade. Copy whichever you need using the candy buttons on the right (indicated by a yellow arrow) and paste them as needed into your program.
Storage Account Explorer
One of the hands-down, best things ever to happen along is the Azure Storage Explorer, and the last thing I have to say about storage accounts in this post.
In the dark, horrific early days of Azure storage accounts (say, 2015 or so, by all reports) you had no way of looking at the files, queue messages, and blobs stored in the account without querying the thing programmatically with the SDK or through PowerShell.
Then, the team brought the fire down from Olympus in the form of the Azure Storage Explorer. It essentially allows one to access all their storage accounts and contents, and perform CRUD actions very similarly to how you’d open the Windows File Explorer to clean out and organize your documents.
If you plan to do anything with Azure Storage Accounts, go download this handy free app. It’d be like trying to run a cloud-hosted SQL Server instance without SQL Server Management Studio–you probably could do it, but why on earth would you?
That’s all Folks
This post covered
- how to create a Storage Account resource in the Azure portal
- provided several links and suggestions on what options to select when doing so
- demonstrated how to get the Access Keys/connection strings to the account
- pointed the reader at the Storage Storage Explorer
Not a complicated or advanced topic, but hopefully one that saved someone new to the Azure scene a headache or two (because there will be plenty of other things more worthy of head-desking yourself over).
Zen, Code, and Reveries 
Leave a Reply