Dynamic Values in Linux Scripting

I do a LOT of scripting. Given the choice to click in a GUI vs. typing at the command line, I’ll choose the command line. Given the choice to type commands in repeatedly vs. scripting out a task I perform more than twice, I’ll script. Scripting effectively is an art as much as it’s a science.

Where a GUI can change, both in content, as well as layout, a script is less impacted by this when it is designed to dynamically work with the catalog. You have the choice to either work with the values in an array or to just pull it into a temporary file to work with as part of the script. For the example, I’ll stick with the latter to make our example easier to reproduce.

Let’s start with a use case of deploying a Azure database. When a customer is making the decision to build it out, there are specific information needed to deploy and this will continue to change as the Azure catalog is updated with new offerings. For our example, we’ll stick to a very small snippet of code, as the values we dynamically create will be reused throughout the script. This example will skip past the actual server creation, etc. and just focus on the user database creation. The Server, zone and subscription are all set in the default steps earlier on so as not to have to repeat it throughout each resource deployment step.

The first thing an author of a CLI BASH script will need to know is how to build a SQL Database from the command line per the documentation:

az sql db create \
         --resource-group <group name> \
         --name <database name> \
         --service-objective <sku> \
         --capacity <capacity>
         --zone-redundant <true/false>

We will then assess what parts of the deployment will need to be dynamically updated upon each deployment and change those to variables:

 az sql db create \
         --resource-group $groupname \
         --name $holname"_"$use \
         --service-objective $sku \
         --capacity $cap \
         --zone-redundant false

For the snippet above, it was easy to decide that I wouldn’t be creating zone redundant databases very often, so decided to hard-code this to a value of false, but the rest of the values, I want to generate dynamically.

My script will ask as part of the script execution for the name for the following and then reuse it throughout the script deployment:

Resource Group Name = $groupname

There is a deployment tag acronym that is used to generate the server name, database names and other resources. Each of the resources, depending on type, will then build out from there:

(holname = utw) + (use=DW) so the dbname= utw_DW

The intriguing ones, working is the values for sku and capacity. These can change regularly with Azure and they will need to be pulled dynamically from the Azure catalog. To do this, my BASH script in the CLI does a great job.

I first capture the information, asking Azure for all database versions, by the zone value passed that are available, (True) for that zone. I output the information in a table format to a file titled wh.lst:

az sql db list-editions -l $zone -o table | grep True > wh.lst
Example of file contents:
 P1     Premium        Premium                     125         DTU     True
 P2     Premium        Premium                     250         DTU     True
 P4     Premium        Premium                     500         DTU     True
 P6     Premium        Premium                     1000        DTU     True
 P11    Premium        Premium                     1750        DTU     True
 P15    Premium        Premium                     4000        DTU     True

I now have this file to be used to pull information I need as I proceed through my script. The next step is to “cat” the data from the file and then use an AWK command to pull the first and fourth word from the table to create a list of Skus and DTU sizing for the person executing the script to choose from:

cat wh.lst | awk '{print "SKU:"$1,"DTU:"$4}' | tr -d \"\,
Output example:
 SKU:P1 DTU:125
 SKU:P2 DTU:250
 SKU:P4 DTU:500
 SKU:P6 DTU:1000
 SKU:P11 DTU:1750
 SKU:P15 DTU:4000
...
 SKU:DW400 DTU:3000
 SKU:DW400c DTU:3600
 SKU:DW500 DTU:3750
....

I ask the user to choose a sku from the list and enter it into the prompt. The sku chosen will become the $brcksize value and the DTU value for that sku, will become the $cap, or capacity in my deployment step.

export cap=$(cat wh.lst | grep $brcksize" " | awk '{print $4}' | tr -d \"\,)

If we choose one of the skus from above for the SQL Warehouse, like DW400, you’ll notice it doesn’t confuse DW400c and return both because I’ve instructed my command to add a space after , (grep $brcksize” “). These are the details that have to be thought through and tested as you automate processes.

For our example database, we’ll create a premium Azure DB, choosing the P6 sku:

cat wh.lst | grep P6" " | awk '{print $4}' | tr -d \"\,
Output from the above: 3000

We now can see that with this process, the script will replace the following values in our database creation with a fully qualified Azure CLI command to create a P6 database:

 az sql db create \
         --resource-group UTW_Group \
         --name utw_DW \
         --service-objective P6  \
         --capacity 1000 \
         --zone-redundant false 

I hope this short example demonstrates the value of dynamic linux scripting to not only automate, but to create dynamic automation that can be reused over and over with infinite deployments, scaled to the needs of the project.