Introduction

Azure Event Grid is a first-class and hyperscale eventing platform with intelligent filtering that has recently been released in preview and is a real game changer to build event-driven serverless apps on Azure. There have been many other posts, including this one from my colleague Dan Toomey, which highlights all the magic, features and benefits of this new offering on Azure. Thus, I don’t pretend to reiterate over these on this post. My goal is, however, to try to show how to solve a requirement that I have heard more than a couple of times.

As mentioned here, there are three typical scenarios where Azure Event Grid comes quite handy:

  1. Serverless Applications
  2. Application Integration, and
  3. Ops Automation

In this post, I will show how to build an Azure Ops Automation workflow to monitor configuration drifts on Azure resources using Event Grid and Logic Apps.

User Story

  • As an Op, I want to be notified whenever there is a configuration drift on my Azure Resources.

Many organisations and teams have implemented Continuous Integration / Continuous Delivery (CI/CD), and they want to keep all their infrastructure and solution configuration as code, e.g. in a VSTS Git Repo. This has become a quite common practice, and the source of truth for all infrastructure and configuration as code must be in source control. The Role-Based Access Control (RBAC) on Azure allows us to restrict changes to Azure resources to certain roles or users. Furthermore, Azure provides a way to lock resources at different levels (subscription, resources group or resource) to prevent users from deleting or modifying critical resources, thus avoiding configuration drifts.

However, in some exceptional cases, Ops or Admins might need to update their configuration without having the time to go through the process of updating the repo first and then triggering the CI/CD pipeline. These configuration drifts, will make the Git repo to be out-of-sync, which results in a very high risk of subsequent releases overwriting changes in the environment with unintended side effects. Thus, there is a need to monitor the Azure resources for configuration drifts, so the source of truth can be always kept in-sync.

Scenario

As you probably may have thought, the user story above is quite broad, so let’s reduce its scope for demonstration purposes to:

  • As an Op, I want to be notified whenever there is a configuration drift on my Azure Web App app settings.

For this scenario, we want to receive a notification whenever the app settings of an Azure App Service (Web App) are updated and are no longer aligned to the “desired state”.

To show how this can be achieved with Azure Event Grid (and the Resource Groups Publisher) and Logic Apps, I will build a Logic App workflow that is triggered whenever the app settings of an Azure Web App are modified, and validate if these settings are different to a desired state.

Solution Prerequisites

This solution requires the following:

  1. An Azure App Service (Web App) with some app settings configured, in my case, I configured the app settings as follows:
  2. A JSON definition of the "Desired State" of the app settings stored in an Azure Storage Blob Container, in my scenario this is as below:
    {
  "Setting-01": "expected-value-01",
  "Setting-02": "expected-value-02",
  "Setting-03": "expected-value-03"
}

Solution: A Logic App Workflow with an Event Grid Trigger

My solution implemented as a Logic App workflow with an Event Grid Trigger will follow the algorithm described below:

  1. Trigger the workflow when the app settings of the Web App are updated, using the Resource Groups Event Grid Event Publisher.
  2. Check the status of the Event, if it was not "Succeeded", then Terminate the Workflow. If it was "Succeeded", continue the workflow.
  3. Get the Updated State of the app settings of the Web App using the Azure Resource Connector of Logic Apps.
  4. Get the Desired State from a Blob container.
  5. Compare the New State with the Desired State. If the New State is different to the Desired State, then send a notification with the details of the event.

Below I described the two main steps of the workflow in more details

1. Configuring the Logic Apps Event Grid Trigger

To configure the trigger, we need to specify:

  1. Azure Subscription
  2. Select the Resource Type, in this case Microsoft.Resources.resourceGroups, as we are monitoring Azure Resource Group changes.
  3. In the Resource Name, we enter the Resource Group name.
  4. In the Prefix Filter, we specify the ResourceId, in my case we are monitoring the App Settings of an Azure App Service.
  5. In this case, we don't need to set a Suffix Filter.
  6. And finally, we give a name to the topic subscription we are creating.

Once we execute a Logic App with this trigger, we should get a payload similar to the one shown below

2. Configuring the Logic App Azure Resource Manager Connector

Logic Apps provide an Azure Resource Manager connector, which allows us to do CRUD operations on Azure via Azure Resource Manager. In our scenario, we are going to use the Invoke Resource Operation to List the App Settings of a Web App. This will return the current (new) state of the Azure Resource, so we can compare it to the Desired State later on the workflow. In your own scenario, you can make use of other operations, like List Resources by Resource Group, Read a Resource, or Read a Resource Group to get the state of your Azure resources. The configuration applied for our scenario is as follows.

The Logic App Workflow

The implemented solution as a Logic App workflow is shown below. I hope it is self-explanatory. I included comments on each action to make it easier to follow.

Quite straightforward, isn’t?

And in case you are wondering about the code behind, below is the same workflow showing the code view of the relevant actions.

If you want to have a look at the ARM template, including the full code behind of this Logic App, you can check it out here.

Wrapping Up

In this post, I’ve shown how to monitor configuration drifts on Azure resources using Event Grid and Logic Apps. We’ve seen the Resource Groups Event Publisher of Event Grid in action and how it comes in very handy for Ops Automation scenarios. Now, you can start monitoring changes on your Azure resources by just creating subscriptions with the corresponding prefix and suffix filters on Logic Apps. What other useful Ops Automation scenarios can you think of using Event Grids and Logic Apps?

Please feel free to add your comments and questions below,

Happy eventing!

Follow me on @pacodelacruz

Cross-posted on Deloitte Engineering Blog