Constructing Azure Bicep Reusable Elements with Personal Registry

On this article, we’re going to learn to reuse the Bicep Infrastructure as Code together with your workforce and different groups throughout the Group.

Introduction

Azure Bicep is a Area Particular Language (DSL) for deploying Azure sources declaratively. It offers concise syntax and a high-level abstraction over Azure Useful resource Supervisor (ARM) templates. Reusability within the Bicep could be achieved by modules.

Instance of a Module utilized in one Enterprise Unit

A Module in Bicep is a reusable element that may take inputs as Bicep Parameters; it does the job and at last can return Output values

Let’s say, you’re a part of a Enterprise Unit and you’re liable for creating Re-usable Bicep Elements that might be used inside your Enterprise Unit (say BU1).

As proven above, you create the beneath three Bicep Modules (they’re simply .bicep recordsdata).

AppService.Bicep (App Service Module)

useful resource azbicepasp1 'Microsoft.Internet/serverfarms@2022-03-01' = {
  title: 'azbicep-dev-eus-asp1'
  location: resourceGroup().location
  sku: {
    title: 'S1'
    capability: 1
  }
}

useful resource azbicepas 'Microsoft.Internet/websites@2022-03-01' = {
  title: 'azbicep-dev-eus-wapp1'
  location: resourceGroup().location
  properties: {
    serverFarmId: resourceId('Microsoft.Internet/serverfarms', 'azbicep-dev-eus-asp1')
  }
  dependsOn: [
    azbicepasp1
  ]
}

(Storage.Bicep) Storage Account Module

param pStorageAccountName string

param pLocation string

useful resource storageaccount 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  title: pStorageAccountName
  location: pLocation
  form: 'StorageV2'
  sku: {
    title: 'Standard_LRS'
  }
}

output StorageAccountId string = storageaccount.id

(Database.Bicep) Database Module

param pSQLServer string

param pAdministratorLogin string

@safe()

param pAdministratorLoginPassword string

param pLocation string = resourceGroup().location

useful resource sqlServer 'Microsoft.Sql/servers@2014-04-01' = {
  title: pSQLServer
  location: pLocation
  properties: {
    administratorLogin: pAdministratorLogin
    administratorLoginPassword: pAdministratorLoginPassword
  }
}

useful resource sqlServerDatabase 'Microsoft.Sql/servers/databases@2014-04-01' = {
  mum or dad: sqlServer
  title: 'database1'
  location: pLocation
  properties: {
    collation: 'SQL_Latin1_General_CP1_CI_AS'
    version: 'Primary'
    maxSizeBytes: '2147483648'
    requestedServiceObjectiveName: 'Primary'
  }
}

As soon as the bicep modules are prepared, they are often invoked by one other Bicep file by passing the suitable enter Parameters as proven beneath.

Foremost.Bicep

param Env string = 'dev'
param pAppServicePlan string
param pAppService string
param pSQLServer string = 'azbicep-dev-eus-sqlserver'
param pAdministratorLogin string
param pLocation string = resourceGroup().location
param pSKUName string = (Env == 'dev')? 'F1' : 'S2'
param pSKUCapacity int = (Env == 'dev')? 1 : 2

useful resource KeyVault 'Microsoft.KeyVault/vaults@2022-07-01' current = {
  title: 'azbicep-dev-eus-kv1'
}

module AppServicePlan '2.AppServicePlan.bicep' = {
  title: 'AppServicePlan'
  params: {
    pAppService: pAppService
    pAppServicePlan: pAppServicePlan
    pInstrumentationKey: AppInsights.outputs.oInstrumentationKey
    pLocation: pLocation
    pSKUName: pSKUName
    pSKUCapacity: pSKUCapacity
    pEnv: Env
  }
}

module SqlDatabase '3.SQLDatabase.bicep' = {
  title: 'SQLDatabase'
  params: {
    pSQLServer: pSQLServer
    pAdministratorLogin: pAdministratorLogin
    pAdministratorLoginPassword: KeyVault.getSecret('sqladminpassword')
    pLocation: pLocation
  }
}

Instance of Bicep Modules utilized in one other Enterprise Unit

As proven beneath, one other workforce working for Enterprise Unit 2 may also implement the same design the place additionally they create these modules which is nothing by duplicate work. Beneath is how it could look.

Let’s now perceive easy methods to refactor the code in such a means that you’ve one set of reusable parts which can be accessible by all of the Enterprise Models throughout the group.

Beneath is the best design for refactoring the reusable parts.

Bicep helps the above design by letting the Bicep Builders publish the Modules to a Personal Registry in Azure as of this writing. Microsoft Azure workforce has plans to assist the publishing of Modules to Docker Hub sooner or later.

Beneath are some great benefits of publishing the modules to a Container Registry.

1. Centralized Repository: A container registry offers a centralized location to retailer and handle your modules. This makes it simpler for groups to entry, share, and collaborate on reusable infrastructure parts.
2. Versioning: Container registries usually assist versioning of modules. This allows you to handle totally different variations of your modules, facilitating backward compatibility and making certain that deployments are predictable and dependable. In our instance, BU1 and BU2 can have their very own variations of modules if required.
3. Safety: Container registries supply safety features akin to entry management and encryption to guard your modules from unauthorized entry and tampering. You’ll be able to management who has entry to the modules saved within the registry, making certain that solely licensed customers can deploy them.
4. Integration with CI/CD Pipelines: Container registries combine seamlessly with steady integration and steady deployment (CI/CD) pipelines, enabling automated testing, constructing, and deployment of modules. You’ll be able to configure your CI/CD pipeline to mechanically publish up to date variations of modules to the registry, streamlining the event and deployment course of.

General, publishing modules to a container registry presents a strong and safe method to handle, share, and deploy reusable infrastructure parts, enhancing collaboration, scalability, and reliability in your cloud deployments.

Working with Personal Registries in Azure for publishing the Bicep modules wants infrastructure. Beneath is how the Personal Registries are organized and used.

Subsequent Steps

1. Creating an Azure Container Registry (ACR) & Enabling Authentication for ACR.
2. Growing Bicep modules &publishing every module.
3. Invoking every module by referring to the ACR Repository.

Abstract

On this article, we explored creating Bicep modules for widespread infrastructure parts like App Service, Storage Account, and Database. These modules can then be invoked in a principal Bicep file by passing acceptable parameters.

Nonetheless, duplicating module creation throughout enterprise models results in redundancy. To deal with this, within the subsequent set of articles, we’ll talk about leveraging personal registries in Azure for sharing modules organization-wide. Publishing modules to a container registry presents a number of benefits, together with centralized repository administration, versioning, safety features, and seamless group of the Infrastructure as code.

In abstract, leveraging personal registries in Azure enhances collaboration, scalability, and reliability in managing and sharing reusable infrastructure parts throughout a company.

Thanks for studying, and good luck in organizing your code.