Using Azure Container Instances to complete automation


blur-close-up-engineering-633850We looked at Azure Container Instances.

It allows us to launch a container without a cluster and without a VM.

It is ideal for bursting scenarios.

In this article we’ll look at another scenario for container instances:  automation.

The limits of ARM Templates

A great tool for automation in Azure is ARM Template.

ARM Templates allow us to describe an Azure deployment.  They describe a target environment.  Azure Resource Manager (ARM) computes a delta between the current and the target and issue changes.

For example, let’s start with nothing deployed and a template describing an Azure App Service.  ARM will create the App Service.  If we then submit a template with an App Service and an Azure SQL database, ARM will create the SQL database.

ARM templates allow us to avoid configuration drift since we only define the target, never the steps to get there.

ARM Templates have limits though.  Not all ARM Template providers are created equal.  Azure Storage just recently supported creating storage containers in ARM template.  Before that, only the storage account could be created.  Cosmos DB supports only the creation of accounts.  We can’t create a Cosmos DB collection, left alone stored procedure or triggers, using a template.

For those other tasks, we must rely on scripting:  either PowerShell scripting or Azure Command Line Interface (CLI) scripting.

There is no common way to bootstrap a script within an ARM template.

Adding Azure Container Instance at the end

Recently, we provided an ARM template deploying a full environment to test Azure Stream Analytics in action.

Part of the deployment was a SQL Database.  A table in the DB gets updates via a Logic App in the deployment.

The ARM Template deploys the SQL Database.  But it can’t run a SQL script to create a table and a stored procedure.

We did run that script using Azure Container Instance.  We called that container image SQL Script Runner.  The code for container is on GitHub.  We simply leverage SQL CMD.

The container is reusable.  We simply need to point it to a database and script.

The beauty of this approach is the flexibility.  We can run any environment.  We aren’t tied to only run PowerShell script.  We can run Azure CLI, SQL script, we could even access Azure Management REST API directly if we had to.

In the ARM template, we simply describe a container instance, put a dependency on the Azure SQL DB and pass parameters.


{
  "type": "Microsoft.ContainerInstance/containerGroups",
  "apiVersion": "2018-04-01",
  "name": "container-group",
  "location": "East US",
  "dependsOn": [
    "[resourceId('Microsoft.Sql/servers/databases', variables('SQL Server Name'), variables('SQL DB Name'))]"
  ],
  "properties": {
    "restartPolicy": "Never",
    "containers": [
      {
        "name": "sql-script-runner",
        "properties": {
          "image": "vplauzon/sql-script-runner",
          "environmentVariables": [
            {
              "name": "SCRIPT_URL",
              "value": "[variables('SQL Script URL')]"
            },
            {
              "name": "SQL_SERVER",
              "value": "[variables('SQL Server FQDN')]"
            },
            {
              "name": "SQL_DB",
              "value": "[variables('SQL DB Name')]"
            },
            {
              "name": "SQL_USER_NAME",
              "value": "[variables('SQL Admin Name')]"
            },
            {
              "name": "SQL_PASSWORD",
              "value": "[parameters('SQL Admin Password')]"
            }
          ],
          "resources": {
            "requests": {
              "cpu": 1,
              "memoryInGb": 0.2
            }
          }
        }
      }
    ],
    "osType": "Linux"
  }
}


Updates

As we mentioned above, the strength of ARM templates is their descriptive nature.  They only contain the target description, not the steps to get there.

Scripts are different.  A version 1 script does something.  A version 2 builds on what version 1 did and continue.  If we run version 2 without running version 1, we won’t get expected results.

How do we manage that if we start introducing container instances in our deployment?

Well, unless we know in which context the container will run, we need to add testing logic.  Just like scripts.  Does this resource already exist?  If not create it.  Etc.

Summary

We introduced an alternative scenario for Azure Container Instance.

Containers are often described as “lightweight VMs”.  We prefer to frame them as “heavyweight process”.  They are isolated process that carry their own environment.

That makes them a perfect “Cloud Executable”.

Here we used them as automation tool, but they could be used to launch any process in the cloud.

Advertisements

2 thoughts on “Using Azure Container Instances to complete automation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s