How to address IaC shortcomings – Part 4?

A previous article discussed a resolution to IaC shortcomings for declaring resources with configuration not yet supported by an IaC repository. This article continues that discussion with native support for extensibility with Terraform.

As a recap, IaC providers enable templates and blueprints so that they fit nicely into a CI/CD and provide a declarative framework that can be applied idempotently providing robustness against transient and intermittent failures. Terraform also has features such that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful. With Azure Blueprints, the relationship between what should be deployed and what was deployed is preserved. This connection supports improved tracking and auditing of deployments. It even works across several subscriptions with the same blueprint.

The organization can make use of the best of both worlds with a folder structure that separates the Terraform templates into a folder called ‘module’ and the ARM Templates in another folder at the same level and named something like ‘subscription-deployments’ and includes native blueprints and templates. The GitHub workflow definitions will leverage proper handling of either location or trigger the workflow on any changes to either of these locations.

The native support for extensibility depends on naming and logic.

Naming is facilitated with canned prefixes/suffixes and dynamic random string to make each rollout independent of the previous. Some examples include:

resource "random_string" "unique" {

  count   = var.enable_static_website && var.enable_cdn_profile ? 1 : 0

  length  = 8

  special = false

  upper   = false

}

 

Logic can be written out with PowerShell for Azure public cloud which is the de facto standard for automation language. Then a pseudo resource can be added using this logic as follows:

resource "null_resource" "add_custom_domain" {

  count = var.custom_domain_name != null ? 1 : 0

  triggers = { always_run = timestamp() }

  depends_on = [

    azurerm_app_service.web-app

  ]

 

  provisioner "local-exec" {

    command = "pwsh ${path.module}/Setup-AzCdnCustomDomain.ps1"

    environment = {

      CUSTOM_DOMAIN      = var.custom_domain_name

      RG_NAME            = var.resource_group_name

      FRIENDLY_NAME      = var.friendly_name

      STATIC_CDN_PROFILE = var.cdn_profile_name

    }

  }

}

 

PowerShell scripts can help with both the deployment as well as the pipeline automations. There are a few caveats with scripts because the general preference is for declarative and idempotent IaC rather than script so extensibility must be given the same due consideration as customization.

All scripts can be stored in folders with names ending with ‘scripts’.
 These are sufficient to address the above-mentioned shortcomings in the Infrastructure-as-Code.