Post-Image

A First Look at Azure Image Builder

From a devops perspective, the utopia is to have a fully automated deployment that covers all the required infrastructure and the application itself. There is a class of software (to use the term broadly) that falls in the middle of those two concerns that I like to term application infrastructure. A basic example here would be web servers and it’s associated configuration. It’s neither infrastructure (in the traditional sense, from an IaaS perspective anyways) or application code.

Different solutions have emerged to solve the application infrastructure problem. In certain programming languages, such as ruby or node, you actually include/download your web server as part of your application deployment. The puma gem, for example, is installed prior to run. Applications built in .NET typically need a webserver (such as IIS) to already be installed, although that has drastically changed with core.

In my day-to-day right now, I deal a lot with Azure Data Factory and self-hosted integration runtimes. On my runtimes I need various components installed/configured such as JDKs and ODBC connections. The Azure Data Factory platform doesn’t provide a way to lazy load these dependencies at run time, so I need to make these available at build time of the server. Ideally I want to control what software is running on these machines, their configuration, and follow some type of devops/automation process for creation. Further, in the event of rapid scaling requirements, I want to be able to deploy fully configured machines at scale.

This is a problem area that Azure Image Builder, currently in preview, is trying to solve.

How It Works

As per the docs, Azure Image Builder is a fully managed Azure service that takes in an ARM template configuration and translates that into a consumable image for building VMs. A couple of core points:

  1. Images sources can be outputs of previous Azure Image Builder steps, allowing you to layer your configurations in interesting ways. For example, your infrastructure team could create a gold image for the operating system, which your application teams could then use and further customize
  2. The service integrates with shared image gallery, allowing you to centralize your VM image creation processes but still make them available to your entire organization
  3. There is a preview devops task for integrating this process into your build/release pipelines

Customizers

Customizers are where all the action occurs. Effectively, they are steps that are run in the order specified in the template that should result in a configured VM. There isn’t a ton of fancy features here, effectively you have a customizer to download files, run scripts (bash or powershell), execute restarts, and configure windows updates. A couple of notes:

  1. You can run scripts either inline or via downloading from an Azure storage Account (or github). There is a pattern where you can use a user-assigned Managed Service Identity (MSI) to access your storage accounts, thus not having to make your storage accounts public. See this link.
  2. You will want to specify SHA hash-sums for all downloaded content to verify it’s integrity.

Getting Started

As this is a preview feature, not all the functionality is available directly in the portal. You can examine various getting started resources in this github repository.

Conclusion

My initial thoughts are that the Azure Image Builder service offers a good solution to the problem of application infrastructure on VMs. I like the idea of this occurring at build time rather than deployment time like other solutions such as the ScriptExtention or Desired State Configuration. The integration with Shared Image Gallery is also interesting for both corporate IT teams and for cloud service providers (CSPs) managing multiple customers.

 

Share This Article

Comments