Introduction

If you are curious like me and eager to get to use the new window package manager, you certainly needed to use winget command line tool

The winget client is the main utility to manage packages on a windows 10 / 11 machines.
It is mainly installed as part of the windows app installer which can be directly installed from the windows app store check the following article for details https://devblogs.microsoft.com/commandline/windows-package-manager-1-0/ .

However, in case you are running a device where installing apps from the windows app store is disabled for certain reasons and you still wish to use the winget command line tool, here are the steps that should be followed for you in order to get the winget command line tool installed.

1. Download the windows app installer

Download the latest release of windows app installer msixbundle available at the following github repo https://github.com/microsoft/winget-cli/releases

2. Download the latest c++ runtime desktop bridge (optional but recommended)

Download the latest c++ runtime desktop bridge package from the following location https://docs.microsoft.com/en-us/troubleshoot/cpp/c-runtime-packages-desktop-bridge

3. Open powershell 7 and run the following

Import-module appx -UseWindowsPowerShell 
Add-appxpackage '<pathtodowloadedc++packageName>' 
Add-appxpackage '<pathtodownloadedmsixbundleName>'

4. verify successful installation

Once you have successfully ran the above mentioned commands you can run the winget command from powershell or cmd to check if it was successfully installed

Conclusion

in this post we saw how to install and use the winget client to install windows applications. By using the windows package manager approach you will be able to manage installations much faster and easier!

Hope you enjoy it :)

Part 1 - Azure Bicep - Introduction
Part 2 - Azure Bicep - Deploy your Fist code

Introduction

In this part of the Bicep series we will discuss how to perform advanced deployments using Bicep as an Infrastructure As Code DSL language, while shedding the light on Bicep modules.

Prerequisites

• We assume that your development environment is setup for bicep, (if you still did not setup your development environment please follow the instructions mentioned in Part-one
• We assume that you have minimum knowledge on how to deploy azure resources using bicep, you can follow the instructions in Part-two

The Regaton App

Let's consider a scenario where want to programmatically deploy and maintain the below illustrated application in your azure environment using bicep

Detailing the application components

As shown in the above diagram our application "Regaton" consists in the following main components:

• A Web Application
• An SQL Database
• A storage Account
  Yes only three Azure services but why consider it as complex ?
  Actually if we take a deep look we notice the following:
• The resources are distributed between different resource groups, this actually means that our deployment include different targets.
• Azure services like the Azure SQL Database and the Azure Web app, depends on other type of services such as "SQL Server", and "App service plan" to be available therefore should also be deployed.

Authoring concept

Let's see how we can achieve our required deployment while meeting all the requirements.

If we were using ARM templates we would use either nested templates which are child templates that are written in the same template file or linked templates which are ARM templates stored in a remote location ( mainly a storage account) and referenced by their Template Uri in the parent template.

When the above options represent a valid solution, however they do also represent many challenges which are not simple to overcome. Fortunately these challenges were eliminated with Bicep modules.

Modularization

Bicep allows splitting your deployment code into multiple local bicep files to be consumed as modules in your deployment. We refer to this concept by modularization.
Modularization offers many advantages among the below:

• The ability of using existing written modules in different deployments while applying minor or i many cases zero changes to the existing code.
• Allows Masking the complex details from the parent bicep files as only parameters and outputs are required to be exposed.
• Most importantly allows targeted deployments to specific scopes (subscription, resource groups)

Deployment code structure

Inspite of the above mentioned facts our Regaton application deployment code will consists of the following:

• A main bicep file that will contain the main code which is responsible of calling multiple modules each module with aim to deploy a set of resources in a target location.
• While multiple parameters files can be used, deployment parameters will be stored in a single file and passed through the main bicep file to all modules.

Bicep modules in action

While the complete deployment code of the Regaton application is available for you in the following github repository CharbelHanna/Azure/Bicep. let's start exploring the main bicep file "regaton.bicep" to discuss in details how the different modules are consumed.

Taking a closer look on the selected code, we will notice the following:

• To consume a module the following syntax is used

module <modulesymoblikname> 'Modulepath' = {
name: <ModuleName> // the deployment name that will be logged in Azure activity logs
scope: <Deploymentscope> // specifying the scope where the deployment should take place
params: {
  your parameters goes here
  } 
}

• The deployment scope is defined by referencing the symbolic name of the resource group that was created earlier, for example stgrg for the storage account resource group "regaRG3"

• Outputs from different modules are passed as parameters to other modules

In order to configure the web app to use and connect to the storage account and SQL database that are being deployed, it is essential to get the outputs from the respective modules. This is done as following:

• Defining the output variables in the source module as below

Notice the cross reference that we are using to supply the value of the output variable storageEndpoint

• Passing the output as parameters to the destination module as below

notice the parameters value reference <Modulesymname>.outputs.<variablename>

Conclusion

In this series I tried to shed the light on Azure Bicep as a new DSL language and how it can be used for Azure deployments and the main Bicep features.
More details on how to move from ARM templates can be found here .
Tt is important to note that Azure Bicep is 100% supported by Microsoft and it provides Day 0 resource provider support. Any Azure resource - whether in private or public preview or GA - can be provisioned using Bicep.

Part 1 - Azure Bicep - Introduction
Part 3 - Azure Bicep - Advanced Deployments with Bicep modules

Introduction

In [part-one](/azure/2021/04/02/Bicep-Introduction.html) of this series we have introduced Bicep and explained how it works.
so now it is time to get our hands dirty by starting deploying our first bicep code.

In this part I will walk you through how to deploy your Azure resources by using Bicep with emphasis on the syntax requirements and differences between Bicep and standard ARM Templates.

Prerequisites

We assume that your development environment is setup for bicep, (if you still did not setup your development environment please follow the instructions mentioned in part-one

Create your Bicep file

Open vscode and create your bicep file, you can give the file any name that you want as long as you save it under the “.bicep” extension. For the purpose of this tutorial I will create a bicep file and call it main.bicep. I like to create and save the file as an empty file first so vscode recognize it as a .bicep file and load the bicep tools extension directly as soon as I start authoring.

Bicep file structure

Unlike standard JSON ARM templates, bicep does not require a predefined schema to exist in the beginning of the file so the file be properly treated as a deployment template. Which means in a bicep file you start authoring directly without adding any specific elements related to the file itself to make it readable.

The picture below shows an empty ARM template.

If we take a look on a bicep file, we will directly notice the difference and how simple it is

For example the above code permit the deployment of a public IP address resource just by specifying the resource type and related properties. cool isn’t ?

Defining Azure Resources in Bicep

Azure resources are the building bloc of a bicep file, since at the end the target is to deploy or update an azure resource, therefore, the minimum required block in a bicep file is a resource bloc. The resource bloc define the type of the resource that you want to interact with. Each resource bloc includes the following:

resource <resouceSymbolicName> 'ResourceType@<Apiversion>' = {
property1:<somevalue>
property2:<somevalue>
.... }

There are couple of things to note here

1) Each resource is represented by a symbolic name to be used as a reference for the resource throughout the file. 2) The API version is appended directly to the ‘ResourceType’ which allows you to directly choose the API version to be used during the deployment.

Ok so now we know that we need to specify the resource type but the first question that pops up is from where we can get the resource type ? Actually the answer is very simple, thanks for the Bicep vscode extension that will automatically display the resource Type along its API version just as soon as you start typing the name of the and for finding the allowed properties, you can use the “Ctrl+Space” key combination to open the properties selector as shown below.

Author the first code

let’s assume we want to create a storage account with the following information:

• Storage account name: komobicepstg01
• Storage account type: general purpose V2
• Replication policy: local redundant
• performance tier: standard

based on what we have seen so far our bicep file should should contains the following code.

resource stg 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: 'komobicepstg01'
  location: 'westeurope'
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
}

Deploying the bicep code

Now we have our code complete, we are ready to deploy it to Azure in an existing resource group, to achieve this I have I can either use powershell or Az cli, I will deploy it using powershell by running the following command.

New-AzResourceGroupDeployment -templateFile "C:\Coding\Repos\Komo\bicep-tuto\App01\main.bicep" `
-ResourceGroupName bicep-tuto-rg -Verbose

Working With Parameters

Despite that the bicep file we have created earlier works properly to deploy the intended resource, however it is would be difficult to use it for multiple deployments since all properties values are included directly within the resource bloc of the file itself.

To overcome this problem we should use parameters to dynamically inject values for specific properties without the need of each time through the code.

Fortunately defining and using parameters in a bicep file is easy and straight forward.
In this section we will see how parameters can be defined and used with bicep.

To note that same as in ARM templates bicep supports defining parameters and setting parameters values either within the bicep file itself or in a separate file.

Defining parameters, variables and setting values

A parameter or a variable can be defined using the following form of code

param StorageAccountName string
var location = resroucegroup().location

A parameter value can be set using the following form of code

param StorageAccountName string = 'komobicepstg01'

In this example we defined the storageAccountName as a string type parameter with a value of “komobicepstg01”, and a variable name location to the value of the resource group location where the deployment will be performed.

Calling Parameters And Variables

A parameter or a variable can be called by simply typing the parameter name like below

name:StorageAccountName
location:location

Notice that the parameter and variable names are used directly without quotes or brackets or even mentioning if we are calling a variable or a parameter unlike the way it is required in a JSON ARM template which dramatically simplify the authoring experience.

Putting it all together

Our bicep file should be like this

//---parameters-----------
param StorageAccountName string = 'komobicepstg01'
param StorageAccountType string = 'StorageV2'
param StorageAccountSku object = {
  name: 'Standard_LRS'
  tier: 'Standard'
}

//---variables-----------
var location = resourceGroup().location

//---resources-----------
resource stg 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name:StorageAccountName
  location:location
  kind:StorageAccountType
  sku: {
    name:StorageAccountSku.name
    tier:StorageAccountSku.tier
  }
}

Using a separate template file with bicep

As mentioned earlier we can use separate parameter file with bicep, this will give us more flexibility in editing and supplying parameters values without touching the bicep code. At the time of writing this article “.json” parameters files are the only supported. That means yes the same parameters file used with ARM template can be used with a bicep file. so our parameters file for the storage account creation should look like this

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "StorageAccountName": {
            "value": "komobicepstg01"
        },
        "StorageAccountType": {
            "value": "StorageV2"
        },
        "StorageAccountSku": {
            "value": {
                "name": "Standard_LRS",
                "tier": "Standard"
            }
        }
    }
}

Note that the values set in the main.bicep file itself earlier represents the parameters default values, therefore, these values are overwritten by the values are set in the parameters file that we have just created.
If you prefer to not use default values like myself you can remove the parameters values from the main.bicep file.

//---parameters-----------
param StorageAccountName string
param StorageAccountType string
param StorageAccountSku object

//---variables-----------
var location = resourceGroup().location

//---resources-----------
resource stg 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name:StorageAccountName
  location:location
  kind:StorageAccountType
  sku: {
    name:StorageAccountSku.name
    tier:StorageAccountSku.tier
  }
}

The previous deployment can be performed using a separate file as follows

New-AzResourceGroupDeployment -templateFile "C:\Coding\Repos\Komo\bicep-tuto\App01\main.bicep" `
-TemplateparameterFile "C:\Coding\Repos\Komo\bicep-tuto\App01\parameters.json" `
-ResourceGroupName bicep-tuto-rg -Verbose

Conclusion

We can clearly conclude that using bicep simplifies the deployment of azure resources while preserving the same deployment experience by using the same deployment commands used with ARM template deployment. Also bicep capabilities provide a much simpler experience against the standard JSON ARM templates.

hope you find this article in this series useful and helps you get starting using bicep. your feedback is appreciated.

As a cloud architect working on cloud environments on daily basis trying to reply to various technical and organizational demands while coping with technology changes and updates , Infrastructure as Code has become vital to perform almost all kind of operations.

Despite the fact that there are many languages / utilities offered by third party vendors that already exists in the market (which are by the way very good and powerful), you might be in a position like I am where you have to use only native languages provided by your public cloud provider "Microsoft Azure" in this context.
JSON ARM templates where the only available native solution from Microsoft to be used for Azure which I was using until recently a new promising language "Bicep" has been released, which for my opinion represents the future of ARM templates.

That being said, I felt that it worth shedding light on Bicep and share my experience on using this new language for IaC deployments through a series of articles which I hope that you find interesting and useful.

Part 1 - Azure Bicep - Introduction

Part 2 - Azure Bicep - Deploy your Fist code
Part 3 - Azure Bicep - Advanced Deployments with Bicep modules

First things first, what is Azure Bicep

As per the official documentation, “Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively . It aims to drastically simplify the authoring experience with a cleaner syntax, improved type safety, and better support for modularity and code re-use. Bicep is a transparent abstraction over ARM and ARM templates, which means anything that can be done in an ARM Template can be done in Bicep (outside of temporary known limitations). All resource types, apiVersions, and properties that are valid in an ARM template are equally valid in Bicep on day one”.

So in other terms Azure Bicep is a new authoring language that if once used it eliminates the need of developing standard ARM JSON templates, which I personally think is a turning point since this will drastically simplify template development hence considerably reduce authoring and deployment time.

So how Bicep actually works?

What Bicep does under the hood actually is compiling the bicep code to ARM templates which they are in turn deployed on Azure by Azure Resource Manager, cool isn’t ?

Wait a minute, so is this means that at the end we are always be using Azure ARM!
Actually Yes! This means we can still benefit from all existing and NEW features and capabilities of ARM templates. Which also means that Azure Bicep is NOT a replacement of Azure ARM

So why bothering using a new language?
The main reason is to simplify the authoring experience. Whether you are used to or new to ARM templates we all agree on the complexity of the syntax that they hold, which makes it hard to manage and maintain as they written in JSON format which is not considered as a user friendly language. Bicep does not only provide a simpler syntax but it also provide additional enhancements like automatic dependencies generation and much more.
at the time of writing this post Bicep is in version 0.13 which supports all existing ARM template features.

Bicep deployment process

The deployment process using bicep is easy and straight forward all you have to do is : 1) create your bicep code and save it as .bicep files 2) Deploy bicep code to azure using either Az CLI or Az powershell

it is to note that the deployment of bicep files can still be done using existing commands such as
in Az powershell

New-AzResourceGroupDeployment 

or Az cli

Az deployment group

So now we have an idea about what is Azure Bicep and how it works, let’s jump over and start deploying our first bicep code.

First let’s setup together the development environment

Bicep requires the Bicep cli to be able to compile bicep code to ARM templates which can be provided by the following:

• Azure cli (required version v2.20.0 or later) can automatically install Bicep cli when deploying the bicep code, there's no need for any manual installation, however you can still manually install the bicep cli by running the below command

az bicep install

• Azure Powershell module (required version v5.6 or later) does not have the ability to install the Bicep cli directly therefore, it expect that the bicep cli is already installed. You can manually install the bicep cli by following on the installation methods mentioned in the reference link

You can check the version of the installed bicep cli by running

bicep --version

For the best authoring experience, Bicep language service can be used which is part of the Bicep visual studio extension, this is a great extension that supports validation, intellisense code completion and many more important features that can be used to give an easy and simple authoring experience

Conclusion

That was the first part of the Bicep series in which we introduced Bicep, how it works and what is required to start using it in your Azure deployments. Stay tuned for Part two where we are going to get your hands dirty deploying Bicep