{
  "$type": "site.standard.document",
  "canonicalUrl": "https://johnnyreilly.com/posts/azure-standard-tests-with-bicep",
  "description": "Learn how to deploy Azure standard tests using Bicep! This post goes through the process and includes a complete code snippet.",
  "path": "/posts/azure-standard-tests-with-bicep",
  "publishedAt": "2021-11-18T00:00:00.000Z",
  "site": "at://did:plc:yy3apqjlms24kso7ahn7lbmb/site.standard.publication/3mova7c4nho2b",
  "tags": [
    "azure",
    "bicep"
  ],
  "textContent": "Azure standard tests are a tremendous way to monitor the uptime of your services in Azure. Sometimes also called availability tests, web tests and ping tests, this post goes through how to deploy one using Bicep. It also looks at some of the gotchas that you may encounter as you're setting it up.\n\n\n\nWhat are standard tests?\n\nTo quote the docs:\n\n> Standard tests are a single request test that is similar to the URL ping test but more advanced. In addition to validating whether an endpoint is responding and measuring the performance, Standard tests also includes SSL certificate validity, proactive lifetime check, HTTP request verb (for example GET,HEAD,POST, etc.), custom headers, and custom data associated with your HTTP request.\n\nSo we can use these to:\n\n- send requests to a URL\n- from a variety of geographic locations\n- and determine if it is responding with a 200 status code\n\nThe URL may be one of our own service URLs, but it could be checking any kind of URL. It's web specific, not Azure specific.\n\nStandard test Bicep\n\nNow we're going to write a Bicep module that provisions a standard test named standard-test.bicep:\n\nLocations / populations\n\nYou'll note that a parameter to the Bicep module is testPopulations. These are the geographical places where requests will be sent from. You'll note we have a default value of five populations, but these could be any of the (presently) sixteen valid values. If you were wondering where those are sourced from, here is the link to the Azure docs.\n\nThe hidden-link tag\n\nAnother significant call out should go to the hidden-link tag. The hidden-link tag is a mandatory tag that connects the test (known in Azure as a \"webtest\") to an app insights instance.\n\nIf you do not provide a hidden-link tag, or if you try to specify a resource group other than the app insights resource group, Azure will fail to deploy your test and you may find yourself presented with an error like this in the deployments section of the Azure Portal.\n\n> Resource should exist in the same resource group as the linked component\n\nIn our module we set both the hidden-link tag as well as the tags that have been supplied via the tags parameter.\n\nApp insights and standard tests share a resource group\n\nAnother thing that can cause issues is the deployment of your app insights resource. It's not unusual to spin up Azure resources on demand, for a given branch of your source code. Those resources will be named in relation to the branch and will depend upon one another. I've never managed to successfully create an app insights resource, and reference it from a standard test within the same Bicep file. It appears to be necessary to separate the two actions, such that Azure recognises the existence of the app insights resource when the standard test is deployed.\n\nIf you are working with long-lived app insights it won't be an issue for you, but if you aren't it's worth being aware of.\n\nUsing standard-test.bicep\n\nOur Bicep module can be invoked from another Bicep module named ping-them.bicep like so:\n\nAs you can see, this module itself takes a number of parameters, and will typically be invoked from some kind of continuous integration mechanism such as Azure Pipelines or GitHub Actions.\n\nThis module is written in the expectation that multiple URLs will need to be pinged, and so it has a parameter named standardTests which is effectively a dictionary of key-value pairs, where the key is the name of the standard test, and the value is the URL to test.\n\nThe module makes use of the items array helper in Bicep to convert the object into an array that can be iterated over.\n\nAzure Pipelines test\n\nWe're going to use Azure Pipelines to test this out. Here's an azure-pipelines.yml file:\n\nWhen run, it invokes our ping-them.bicep module, passing two URLs to test.\n\nWhen executed, you end up with a delightful \"availability test\" (which is your standard test) in Azure:",
  "title": "Azure standard availability tests with Bicep"
}