So, my previous post was about using PowerShell from a compute host (physical/virtual computer) to connect to an Azure subscription and copy containers between storage accounts. I call that “part 1”. This will be “part 2”, as it takes that smelly pile of compost and shovels into Azure Automation.
In short, the basic changes from the previous example:
- Not nearly as much fuss with credentials within the PowerShell code
- Configuration settings are stored in Azure as Variables, rather than a .json file
- Less code!
The previous article refers to the diagram on the left. This one refers to the one not on the left.
- You have access to an Azure subscription
- In Azure, you have at least one (1) Resource Group, having two (2) Storage Accounts (one for “source” and the other for “destination”. The “backup” this performs is copying from “source” to “destination”)
- You somehow believe I know what I’m talking about
- You stopped laughing and thought “Shit. Maybe this idiot doesn’t know what he’s talking about?“
- After a few more minutes you thought “Why am I reading what I’m actually thinking right now? How does he know what I’m thinking? It’s like he’s an idiot savant! Maybe he counts toothpicks on the floor while brushing his teeth…“
- You consider that this was written in November 2018, and Azure could have changed by the time you’re reading this.
The basic goals of this ridiculous exercise in futility are (still):
- Copy all (or selected) containers from Storage Account 1 to Storage Account 2 using an Azure Automation “runbook”, once per day.
- The copy process will append “yyMMdd” datestamps to each container copied to Storage Account 2
- The copy process will place the destination containers under a container named “backups”. For example, “SA1/container1” will be copied to “SA2/backups/container1-181117”
- Both storage accounts should be within the same Azure Resource Group, and in the same Region
- New Goal: Eliminate a dedicated host machine for running the script in lieu of an Azure Automation Runbook.
This is a demo exercise only. DO NOT perform this on a production Azure tenant without testing that absolute living shit out of it until your fingers are sore, your eyes are bloodshot and you’ve emptied every liquor bottle and tube of model glue in your house/apartment.
The author assumes NO responsibility or liability for any incidental, accidental, intentional or alleged bad shit that happens resulting from the direct or indirect use of this example. Batteries and model glue not included.
First, we need to set up the automation account and some associated goodies. Some of the steps below can be performed using Azure Storage Explorer, or PowerShell, but I’m using the Azure portal (web interface) for this exercise. Then we’ll create the Runbook and configure it, and run a test.
- From the Azure portal, click “All Services” and type “Automation” in the search box.
- Click the little star icon next to it. This adds it to your sidebar menu (along the left)
- Click on “Automation Accounts“
- Click “Add” near the top-left, fill in the Name, select the Resource Group, Location and click Create
- From the Automation Accounts blade (I hate the term “blade”, in fact I hate the Azure UI in general, but that’s for another paint-fume-sniffing article), click on the new Automation Account.
Credentials and Variables
- Scroll down the center menu panel under “Shared Resources” and click on “Credentials“, and then click “Add a credential” at the top. Fill in the information and click Create. This needs to be an account which has access to both of the storage accounts, so you can enter your credentials here if you like, since this is only a demo exercise.
- Go back to “Automation Accounts” (bread crumb menu along top is quickest)
- Go back to the Automation Account again, and scroll down to “Variables“
- Add the variables as shown in the example below. All of the variables for this exercise are “String” type and Encrypted = “No”. This part is a bit tedious, so you should consume all of your elicit substances before doing this step.
- Go back to the Automation Account again and click on “Runbooks“
- Click “Add a runbook” from the menu at top, then click “Quick Create / Create a new runbook” from the middle menu pane.
- Enter a name and select “PowerShell” from the Runbook type list. Enter a Description if you like, and click Create.
When the new Runbook is created, it will (should) open the Runbook editor view. This will have “> Edit PowerShell Runbook” in the heading, with CMDLETS, RUNBOOKS, and ASSETS along the left, and line 1 of the editor form in the top-middle.
- Copy/Paste the code from here into the empty space next to line 1 in the code editor.
- Make sure the variable names at lines 10-16 match up with those you entered at step 9 above. If not: for each variable that needs to be corrected: delete the code to the right of the equals sign (“= Get-AutomationVariable -Name …”), place the cursor after the “=” and click Assets > Variables > then click the “…” next to the variable you want, and select “Add “Get Variable” to canvas“. (see example below)
- After entering the code and confirming the variable assignments, click Save. Don’t forget to click Save!
- Click “Test pane” to open the test pane (I’m shocked they didn’t call it the “test blade”) – Tip: If you don’t see “Test pane” go back to the Runbook editor, it’s at the top (select the Runbook, click Edit).
- Click “Start” and wait for the execution to finish. (Note: Unlike running PowerShell on a hosted computer, Azure Automation doesn’t show the output until the entire script is finished running)
Code Note: You may notice that line 97 ($copyJob = Start-AzureStorageBlobCopy…) is commented out. This is intentional so as to mitigate the chances of you accidentally copying an insane amount of garbage and running your Azure bill into the millions of dollars.
Testing Note: Since line 97 is commented out, the test should simply show what was found, but no copies are actually processed. In the last image example (below) you will still see “copy completed” for each container set, but that’s just more glue-sniffing imaginary hallucination stuff for now. Once you remove the comment, that becomes very real. As real as Kentucky Fried Movie 3D punching scenes.
When you’ve tested this to your satisfaction, simply uncomment that line (or better yet, add $WhatIfPreference = $True at the top of the script, just below the $VerbosePreference line)
(there was a sale on red arrows and I couldn’t say no)